How an AI pentest agent works, step by step

Introduction

"AI pentest agent" is becoming a sales argument before it is an understood mechanism. People often ask us what is really behind the word. This article opens the hood: the loop the agent follows, the tools it is given, the limits it is held to, and the detail that separates an agent from a scanner whose results an AI rereads.

We set the general scene in our article on AI penetration testing. Here we stay at the level of the machine.

A language model in a loop, with tools

A pentest agent is not a model you query once. It is a language model placed in a loop, given tools and limits. On each turn, the model receives the current state (what it has observed so far), chooses an action, a tool executes it, and the result comes back into the context of the next turn.

The tools are the often-forgotten point. A model on its own only writes text. What makes it able to test are the functions wired around it: send an HTTP request, read a response, extract routes from a JavaScript bundle, decode a token, compare two responses. The intelligence is in the choice of tool and its parameters, not in the model taken alone.

The loop, in four steps

We show it as such on the home page, because it describes the product better than a paragraph.

1. Observe

The agent reads what the target returns. Response headers, the forms on a page, API routes referenced in a JavaScript file, an error message that leaks a file path or a framework name. It also starts from what the algorithmic layer has already established: open services, versions, mapped assets.

This step looks like what a pentester does in the first hour: they look, they take notes, they touch almost nothing.

2. Hypothesize

From these observations, the agent forms a hypothesis. Not "let us test SQL injection everywhere", but "this page parameter in a function that reads documents looks like file inclusion". The hypothesis is specific to what it saw, and this is the step a scanner does not do: the scanner runs a list written in advance, the agent builds a question from the context.

This is also where the model can be wrong, and that is fine. A hypothesis is made to be verified, not to be believed.

3. Test

The agent sends the request that confirms or rules out the hypothesis. The payload is non-destructive: it seeks to prove a behaviour, not to cause damage. For a command injection, asking for the system user id (id) is enough to prove execution; no need to read /etc/shadow. For an SSRF, reaching an internal test address proves the entry point; no need to go digging through production metadata.

Then it reads the response. A status code, an unusual response time, a fragment of data that should not have appeared: the return is what decides.

4. Prove, or start over

If the hypothesis holds, the agent keeps the proof: the request sent, the response received, the data reached, and enough to replay the test. That triplet is what will go in the report, and it is what distinguishes a finding from an opinion.

If the hypothesis does not hold, it goes back to step 1, but with one more piece of information. This is the big difference with a scanner: the failure of one test steers the next. An agent may spend twenty requests on a single form because the third response intrigued it, exactly like a human in front of odd behaviour.

A concrete chaining example

Take a case that keeps coming back on our perimeters, told step by step.

1. The mapping finds a subdomain staging.example.com, forgotten since a migration.
2. The algorithmic engine detects open API documentation there.
3. The agent observes that doc and spots a route /api/import that takes a url parameter.
4. It hypothesizes an SSRF: will the server go and fetch the URL it is given?
5. It tests with a harmless control address, and reads in the response that the server did contact it.
6. It proves: request, response, and the confirmation that the entry point exists. It stops there, going no further than the proof.

No scanner rule describes this chain, because it only exists at this customer: the forgotten subdomain, the open doc, the import route, in that order. That chaining is what the agent can reconstruct.

Guardrails are part of the product

An agent without limits is an attack tool, not an audit product. The guardrails are not a comfort add-on, they are what makes the tool deployable. They are what to look at first.

• The perimeter is imposed. The agent only tests assets validated by the mapping and attached to the customer's domain. It does not follow an outbound link to a third party, even if the testing logic would push it there.
• Payloads are bounded to the proof. Prove, yes; exploit fully, no. The boundary is written, not left to the model's judgement at the moment it is most tempted to keep going.
• Throughput is capped. A curious agent can quickly send a lot of requests. The cap protects the customer's production, and tests that can degrade a service are excluded by default.
• Everything is logged. Every request sent to the target is traced, timestamped, inspectable. The customer must be able to know what touched their production, and when.

The pitfall specific to language models

It has to be said plainly, because it is the family's weakness: a language model can convince itself of a flaw that does not exist. It reads an ambiguous response, builds a coherent story around it, and reports it with the same confidence as a real finding. It is the most dangerous false positive, because it is well written.

The only serious countermeasure is structural: accept in the report only what comes with reproducible proof. No request, no response, no data reached? Then it is not a finding, it is a lead to explore, and it does not get reported at the same level. It is an architecture rule, not a prompt instruction: you filter the agent's output on the presence of proof, the model does not decide alone what gets published.

Where the agent stops

An agent does not replace a human everywhere. It does not understand your business rules, so it misses business logic (approving your own expense report, a negative price). It sees what an anonymous visitor sees, so it does not cover the authenticated area until you give it an account. And it stops at the Internet boundary: the internal network is another trade. We detail these limits in the general article on AI pentesting.

What it gains, on the other hand, is frequency and breadth. It comes back every day, across the whole perimeter, and sees the flaw the day a deployment introduces it. That is what no consultant can offer over time.

How it is done at Flawfence

The agent never works alone. An algorithmic engine first rebuilds the perimeter, identifies services and checks every asset against known flaws, deterministically. The agent then picks up its findings, explores, hypothesizes, tests and keeps the proof. The engine is exhaustive, the agent is selective; the two complement each other.

The agent reasons primarily with Mistral AI models, and the platform is hosted in Paris. This choice is not just a preference: your production's responses go through the model, and their route is a question in itself, which we address in the article on sovereign AI pentesting.

FAQ

What is an AI pentest agent, technically?

A language model placed in a loop, with tools (sending requests, reading responses, extracting routes) and limits (perimeter, bounded payloads, capped throughput). On each turn it observes, forms a hypothesis, tests it and keeps the proof if it holds.

What is the difference with a scanner?

The scanner runs a list of tests written in advance. The agent chooses its tests from what it observes, and the failure of one test steers the next. The scanner is exhaustive and reproducible, the agent is adaptive and selective.

Can the agent break something in production?

It can, if it has no limits. A serious product bounds payloads to the proof, caps throughput, excludes degrading tests by default and logs every request. These guardrails are not optional.

How do you avoid false positives from an AI agent?

By accepting in the report only what comes with reproducible proof: the request, the response, the data reached. A finding without proof is treated as a lead, not as a confirmed vulnerability.

Conclusion

An AI pentest agent is nothing magical once the hood is open: a model that observes, hypothesizes, tests and proves, in a loop, with tools and guardrails. What makes a good product is not the size of the model, it is the rigour of the loop and the strength of the limits. And the proof at the end, always. Ask to see it: that is where the difference between an agent and a well-turned text is decided.