Security testing / portfolio case study

BS2

An AI-assisted security testing engine where the model proposes actions and a separate gate decides what runs. Every action on a target needs an exact, expiring approval.

271regression tests passing in 0.2.1
Exactapprovals bind command, target, and policy
Fail-closedunsupported actions are refused
MITopen source on GitHub
The problem

Agents act outside their scope

A model that can run tools will eventually try something outside the agreed targets or something destructive. Prompts alone do not prevent that.

Agents overstate results

Models report findings with confidence that the evidence does not support. A report needs to come from what actually happened.

What I built
01 / PROPOSE

Planning is separate from execution

The model writes a proposed action. It cannot run anything itself.

02 / APPROVE

Exact, expiring approvals

An approval is tied to the exact command, HTTP plan, destination, and policy, and it expires. Scope is checked again just before the action runs.

03 / VERIFY

Evidence decides

Results are judged from the recorded requests and responses. Unsupported commands, redirects, and proxies are refused rather than run.

Details that mattered

Access-control checks

Checks for broken object-level authorisation compare the owner, another user, and an anonymous request, so one odd response is not reported as a vulnerability.

Memory with sources

Past results are stored with their source, and a proven negative is only reused when the conditions match. A change in session or target reopens it.

Operator panel

A read-only browser panel shows what is known, what is suspected, what was already tried, and the next proposed check.

Release discipline

Each release ships with a validation record of the regression run and a capped live test against disposable local fixtures.