Valid proof in an agentic pentest is a reproducible, in-scope demonstration that an asset is actually exploitable, captured as raw request-and-response evidence that traces back to a specific agent action. An AI agent’s written claim, a scanner alert, or a 200 OK response is not proof.
That line is easy to write and hard to hold. An agent can surface a large volume of candidate findings fast, each wrapped in a confident, fluent explanation, and the writing reads the same whether the exploit landed or not. When your tester is a probabilistic system, the real question stops being what it found and becomes what it can prove. Everything below is about that gap: what proof means across the vulnerability classes an agent will hit, what doesn’t count no matter how convincing it reads, and how to build a pipeline that won’t promote a claim it can’t back.
Proof is a reproducible demonstration that an asset is genuinely exploitable, captured as evidence another person can verify without trusting the tester. It’s the difference between “this endpoint is probably vulnerable to SQL injection” and “here’s the request that returned a database version string it should never expose, and here’s the raw response.”
That distinction has always mattered in pentesting. What changes with an agent is who’s making the claim. When a human tester writes “confirmed SQLi on /login,” you’re trusting years of judgment behind that sentence. When an AI agent writes the same sentence, you’re relying on a probabilistic system that can produce a confident explanation even when the action it describes never succeeded. The claim is only as good as the evidence attached to it, so the evidence has to carry the weight.
Proof in an agentic pentest is therefore an artifact, not an assertion. It’s the actual payload, the actual response, and the concrete thing that response proves, bundled together so a security engineer can look at it cold and reach the same conclusion the agent did.
Agents operate at a volume and speed where unverified claims compound fast. A human tester might confirm a handful of findings in a day, each filtered through experience before it’s written down. An agent can propose far more in a fraction of the time. Human reports can also contain unsupported conclusions, but agent scale raises the operational cost of weak validation, so the verification has to be built into the pipeline rather than applied at the end.
There’s also the output problem. A language model writes fluent, confident prose whether or not the action behind it worked. The writing quality tells you nothing about the truth of the claim. This isn’t hypothetical: bug bounty platforms have been flooded with AI-generated reports that read as technically correct but describe vulnerabilities that don’t exist, a problem practitioners trace to the fact that language models are built to be helpful and will produce a convincing report on request. So the output has to be built for verification from the start, which is why validation is its own discipline and not a step you assume happened. Finding something and proving it are two separate events. Only the second one belongs in a report.
That gap between finding and proving is what the rest of this guide makes concrete, starting with the test every finding has to survive.
A finding is proven when it passes four tests. Miss any one and you have a lead, not a finding.
Someone else can run the same steps and get the same result. The evidence has to include the exact request, the parameters, any required session state, and the conditions under which it worked. “Sent a malicious payload” fails this test. A logged POST /api/v2/export?id=1' OR '1'='1 with the full header set passes it. For non-deterministic findings like timing-based injection, reproducibility means a repeatable result across multiple runs with controls, not a single lucky response.
The evidence has to show a consequence that only a successful exploit could produce. Reflected input in a response proves the input was reflected, nothing more. The impact has to be the thing being claimed, not a precursor to it.
The action has to stay inside the agreed engagement boundary. If an agent steps from an in-scope host onto a third-party API, whatever it captures is unusable, however technically valid. Scope is what makes proof usable, both legally and operationally.
The finding has to trace back to the exact agent step that produced it, with a timestamp and the raw tool call. This is the test agentic pentests add to the traditional list, and it’s the one that makes the other three trustworthy. Without attribution there’s no way to tell whether the agent proved the finding or just narrated it.
Those four tests decide whether a finding is proven. The next question is what kind of proof you’re holding, because not all of it carries the same weight.
Proof isn’t one bar, it’s four, and they’re easy to conflate. A finding can clear one and fail another, so name them separately before applying them to any vulnerability.
Technical proof confirms the vulnerability exists and is exploitable. A reproducible Boolean or time-based signal with controls, a database-specific error, or a verified out-of-band interaction can establish it.
Impact proof confirms the consequence, and it’s a higher bar than technical proof: extracting one out-of-scope record, reaching another user’s data, or retrieving internal content an external attacker shouldn’t see. A vulnerability can be technically proven without impact proof, and the reverse rarely makes sense.
Audit evidence confirms who did what, when, under which scope, and with whose approval. This is about traceability, not exploitability, and it’s what an internal investigation or a third-party reviewer needs to trust the record.
Legal evidence is a separate matter entirely. Admissibility depends on jurisdiction, authentication, chain of custody, and collection method. A finding can be technically airtight and still not meet a legal evidentiary bar, so never assume an action log is automatically admissible anywhere.
Most pentest work lives in the first three. Keeping them apart stops you from claiming legal weight you haven’t earned, or passing off a technical confirmation as proof of business impact. With that lens in place, here’s how the standards play out class by class, where the abstract split becomes a concrete evidence bar.
Proof is class-specific. A SQL injection and an SSRF demand completely different evidence, so a generic “we got a response” standard proves nothing. For every class, separate the two questions the table answers: what signal confirms the vulnerability exists, and what artifact confirms it has impact. The first is technical proof. The second is impact proof. An agent needs both before a finding is real.
| Vulnerability class | Confirming signal (technical proof) | Impact artifact (impact proof) | What is not proof |
|---|---|---|---|
| SQL injection | Controlled, reproducible indicator: matched Boolean true/false pair, time-based delay with controls, database-specific error, or verified out-of-band callback | Data the app shouldn’t expose, e.g. a version string or an out-of-scope row via UNION | A single 500 error or one unexplained delay |
| Broken access control / IDOR | One account requesting another user’s object ID and getting a non-error path | The response containing the other user’s data, or a confirmed state change, with before/after captured | A 200 on the request alone, with no returned data |
| Authentication bypass | A request that should require auth accepted without a valid session or with a manipulated token | The response delivering protected content or a privileged action, shown beside the credential-less request | Reaching the login wall, with no protected content retrieved |
| Cross-site scripting | Code execution in the relevant browser context, shown via rendered DOM or a controlled-listener callback | For stored/privileged XSS, execution in a separate user or privileged session | Reflected input sitting inert in the page source |
| Server-side request forgery | Out-of-band interaction from the target’s infra to a tester-controlled listener, in the DNS/HTTP log | Retrieved internal content unreachable from outside, e.g. cloud metadata | A reflected error that merely names an internal host |
| Remote command execution | Deterministic attacker-controlled result: unique OOB callback, or output reflecting a value only the tester could produce | Minimal host context (current user, hostname, controlled file read) | Output that could be reflected input rather than executed |
| Server-side template injection | A template expression evaluated server-side: controlled arithmetic/string op returning the computed result | Where the engine allows, a scoped code/command-execution demo, with RCE-level restraint | The literal payload echoed back unevaluated |
| File upload | A file accepted past validation that should have been rejected, with upload request and acceptance captured | Retrieval or execution of the file from its served location, proving it’s reachable and active | An accepted upload that is stored but never shown to be reachable |
| Business logic | A sequence of legitimate-looking requests producing a state the workflow forbids (negative quantity, skipped payment, replayed single-use action) | The resulting unauthorized state or value, captured with the full ordered request sequence | A single odd response with no reproducible sequence |
Two classes deserve a word of caution. Remote command execution and server-side template injection both can be pushed toward full system control, but proof never requires that. Demonstrate the minimum that shows the consequence is reachable, then stop. The goal is to prove the door opens, not to walk through it.
The table calls for “the response containing the other user’s data.” In practice that means a logged request and response, not a sentence claiming it happened. Here’s an illustrative IDOR pair, with synthetic values, showing the shape the evidence should take.
# Authenticated as user 1041. Requesting an invoice that belongs to user 2087.
GET /api/v2/invoices/2087 HTTP/1.1
Host: app.example.com
Authorization: Bearer eyJhbGciOi... (user 1041 session)
HTTP/1.1 200 OK
Content-Type: application/json
{
"invoice_id": 2087,
"account_id": 2087,
"billing_name": "Dana Whitfield",
"amount_due": "$4,210.00",
"card_last4": "8841"
}That single pair clears the bar. The request shows user 1041’s session asking for an object it has no claim to. The response returns user 2087’s billing record, including data the requester should never see. It’s reproducible because the exact request is preserved, in scope because the IDs sit inside the tested application, and attributable once it’s logged against the agent step that ran it. A screenshot of that JSON would show the same data and prove far less, because it strips the request that makes the result meaningful.
Five things get mistaken for proof all the time. None of them survive a second look, and each fails for its own reason.
A scanner alert or CVE match. Both are detection signals: a scanner pattern-matched a response, or a version string maps to a known CVE. Neither confirms the issue is present, reachable, and exploitable in this environment. They tell you where to look, not what you found.
A 200 OK response. It tells you the server responded, which it does to almost everything. Successful exploits often return 500s and failed ones often return 200s, so a status code confuses “the request completed” with “the attack worked.”
The agent’s written explanation. This is the claim, not the evidence: a description of what the model believes happened, generated by a system optimized for plausible text. Treating it as proof is circular, since you’d be trusting the agent’s conclusion to validate the agent’s conclusion.
A confidence score. A high score is the model’s self-reported certainty, and a probabilistic system can be confidently wrong. A score can route attention, but it can never stand in for the request-response artifact behind the claim.
Knowing what doesn’t count is half the job. The other half is building a pipeline that can’t promote those non-proofs in the first place. You do that structurally, by never letting the agent’s claim stand on its own. A few practices, working together, carry most of the weight.
Capture evidence at the tool layer, not the reasoning layer. Log the real command, the real HTTP exchange, and the real shell output, all separate from whatever the model wrote about them. The model’s prose drifts. The raw tool I/O can’t, because it’s recorded before the model gets to interpret it.
Apply vulnerability-specific confirmation rules and require control tests. A claimed SQLi with no confirming signal doesn’t get promoted to a finding; a time-based result without a matched control run is held as a candidate. Each class has its own bar from the section above, and the pipeline checks against that bar rather than against the agent’s confidence. This is the idea behind adversarial exposure validation: you don’t trust that an exposure is real, you make the system prove it under conditions you can inspect.
Separate discovery from confirmation, and preserve negative results. Finding a candidate and confirming it are different pipeline stages, and a candidate that fails confirmation shouldn’t vanish. Keeping the negative result, the payload that didn’t work and the response that disproved it, is what lets a reviewer see the agent tested and rejected a hypothesis rather than silently dropping it.
Gate high-impact actions and match human review to risk. Some steps are far more likely to produce a real, impactful finding, like running an exploit or writing to a target. Those are exactly the steps you want a human to witness. Pausing for approval there means a person sees the proof land in real time, not reconstructed after the fact. Low-risk read-only steps don’t need that friction and can run straight through.
Strobes records every agent action as an auditable, attributable step, so each finding traces back to the exact tool call that produced it. The proof isn’t reconstructed from a summary after the fact. It’s the logged reality of what ran. Three capabilities do the work.
Approval controls. Run an agent in User mode, and it pauses before each major step, showing a card with the exact command, the risk level, and the estimated cost before anything executes. On a witnessed pentest, a human sees the proof land in real time and can Approve, Reject, or Modify the command first.
Task-level history. Every action is logged, including each Approve, Reject, and Modify. Each entry carries a timestamp, the operator who acted, the original proposal, the final action taken, and the outcome. It all lives in the workspace Tasks tab under each task’s History.
Raw evidence tied to each finding. The evidence behind a finding is the recorded tool input and output, captured separately from the agent’s description of it, so a reviewer verifies the request-response artifact rather than the prose. Run autonomously in Auto mode and the same logging applies, with safety gates still forcing approval before genuinely destructive actions.
Together that gives security and compliance teams a traceable evidence record they can review on their own, without taking the agent’s word for anything. Whatever tooling you use, the same bar applies, and the checklist below is how you hold a finding to it.
See how Strobes agents generate evidence-backed findings
Watch an agentic pentest confirm exploitability on a live web application, with every finding traced to a logged tool call.
Reproducible, in-scope, attributable evidence.
Before any agent-produced finding goes in a report, it should clear every box:
If a box is empty, the item is a candidate, not a finding.
Yes, when the evidence is independently verifiable and the engagement meets the applicable testing, scoping, independence, and documentation requirements. Auditors may also ask for methodology, tester qualifications, scope documents, retention controls, and approval records, so a verifiable finding is necessary but not always sufficient on its own. Strobes logs each finding against the specific tool call and operator approval that produced it, which is the traceability part of that picture.
No. The summary is the agent’s claim about what happened, generated by a language model optimized for plausible text, not for truth. Proof is the raw tool input and output captured underneath that summary. Verify a finding against the recorded request-response pair, never against the prose alone.
A finding is the claim that an asset is exploitable. Proof is the reproducible evidence that demonstrates it. An agent can generate findings at machine speed, but a finding without proof is a lead to investigate, not a result to report. The pipeline’s job is to promote only findings that clear the proof bar.
No. Auto mode still logs every action, and safety gates force an approval pause before destructive operations even when the agent is otherwise autonomous. The difference between Auto and User mode is how many steps you witness live, not whether they’re recorded. The audit trail is identical.
You demonstrate the minimum action that proves exploitability and stop there. For SQL injection, that’s a controlled signal or a single out-of-scope record, not dumping the database. For RCE, it’s retrieving host context, not operating on the host. Scope rules and the Modify option on approvals let you throttle an action down to exactly that minimum.