Where AI belongs in a penetration test

A tester starting on a new application does a predictable sequence. Work out what they are looking at, get past the login, point the right tools at it, then read what comes back and decide what is real and how bad it is. Only a fraction of that is a judgment call. Most of it is knowing which thing to run next, which is knowledge rather than thinking.

That distinction became the whole design. Knowledge you can write down, so it goes in a table. Judgment you cannot, and that is the only place a model is worth its cost and its unpredictability.

It is worth being clear about what that buys. A table is auditable, cheap, instant, and gives the same answer on Tuesday that it gave on Monday. A model is none of those things. Every step we could move out of the second category and into the first made the system easier to reason about and cheaper to run, so the design pressure ran in one direction the whole way through: use the model in fewer places, and make those places count.

You give it an address and answer a few questions about what the target is and how to authenticate. It works out which tools apply, runs them, and returns findings with a severity, a score and remediation text. Underneath it is a relay rather than one system: a wizard collecting setup, a queue carrying work, tools running in isolation for that scan, results coming back to be made readable.

The setup reads as a conversation because it genuinely is one. Answers do not come back in the response to the question. The request returns almost immediately with an identifier, the work of checking the target happens in the background, and the next thing to ask arrives later on a message stream the page is listening to. That is also what makes the sequence safe: the server decides what the next step is and hands the client something it has to give back, so a step cannot be skipped, repeated or reordered from the outside.

The handoff between the wizard and the engine that runs the scan is deliberately almost empty. It carries an identifier and an address to report back to. Everything else was written to shared state a moment earlier, and the engine reads its own configuration from there. Passing a payload instead would mean two services agreeing forever on the shape of that payload, and they would stop agreeing the first time either one changed.

Three quite different things start a scan. A person clicking through the wizard in a browser. An external agent driving the same steps headlessly, with no browser and no message stream, getting back an envelope on every reply that says what it should ask for next. And a scheduler that wakes up once a minute, finds the scans that are due, and starts them.

None of those is a separate engine. They are the same handler behind three different front doors, and the difference between them is how the caller proves who it is and how it is told what to do next. A recurring scan is not a second scanner. It is a timer that calls the wizard a human would have called.

That sounds obvious written down, and it is the kind of thing that stops being true the moment somebody is in a hurry. A scheduled scan that drifts from an interactive one is a bug you find months later, in a report, in front of a customer.

The scans worth running are against applications behind a login, and a scripted login breaks the moment somebody moves a button or turns on a second factor. So an agent does it: here are the credentials, here is what success looks like, work it out. It reads the page and decides whether it landed on a dashboard, hit a second factor, or got blocked. It can generate a one-time code and type it into whichever field it judges to be the right one.

The trick is doing that exactly once. Running an agent for every request would be unaffordable, so the moment it gets through, the session it earned is captured and replayed for everything after. The judgment happens once. The thousands of requests that follow are scripted and fast.

This is the shape the rest of the system copies. Find the one decision that genuinely needs judgment, pay for it properly, and turn its answer into something cheap that everything downstream can use without asking again.

The scanners are not a shared fleet sitting there waiting. When a scan starts, the tools it needs are brought up for that scan alone, on one host, talked to over the loopback, and thrown away when it finishes.

That is more machinery than calling a service that is already running, and it buys two things worth the trouble. One scan cannot be affected by another, which matters when the thing you are running is deliberately hostile traffic. And for a target that is only reachable through a private network, the tunnel and the tools end up on the same host, which is the only arrangement that makes that case simple rather than a special path through everything.

A raw scanner result is not something you put in front of an auditor. It needs a title, remediation steps and a severity score. A model is good at the first and untrustworthy at the last: ask for a score directly and you get a confident number that does not survive being checked.

So it never produces the number. It produces the reasoning behind it, and a calculator turns that into the score. A severity vector is written by the model and computed by a standard implementation. A five part risk breakdown is judged by the model one part at a time and averaged by code. The model supplies structured inputs. The code supplies the arithmetic, and the arithmetic is the part anybody will argue with.

The rule underneath is that nothing ships unless it points at evidence a tool actually found and that still exists when the report is assembled. It reports less than it could. A report somebody has to double-check is not a report.

Everything else resolves against a table. Which tools run, whether a test proceeds, what a scan costs, what happens when a schedule fires: none of it asks a model anything.

Even the metering follows the same instinct. A scan is held against an account's balance before it starts and settled when it finishes, and every failure in that path that is not a genuine shortfall lets the scan run. A billing system that cannot reach its own store should not be the reason a customer's security testing does not happen.

I went in expecting the work to be about getting a model to do more. It was about finding the fewest places one was necessary, then building enough around them that their answers could be relied on. None of that is visible when it works, which is the job.