A finding can arrive from a lot of places. An agent that just crawled your application. A SAST scan that flagged a taint flow. An SCA tool that matched a package version. A secret scanner that hit on a string in a repository. A cloud posture check that noticed an overly broad role. Attack surface monitoring that found a subdomain nobody remembered.
Not one of them arrives proven. Every one of them arrives as a candidate.
Proof is a separate operation, and the shape of that operation depends on two things: where the candidate came from, and what class of weakness it is. A SAST hit and a blind SSRF hypothesis do not get validated the same way, because they are not the same kind of claim. One says a code path exists. The other says a network side effect will occur. Different claims need different evidence.
So instead of one validation step, there are several distinct pathways from candidate to confirmed exploit. Here are the ones that carry the most weight in a real engagement, and what each one actually produces.
This is the pathway people picture when they hear autonomous pentesting. Agents interacting with a running target, forming hypotheses, executing. The part that gets under-described is that "execute it and see" means something structurally different for each vulnerability class. A system that applies one confirmation standard across the board will be simultaneously too strict on some classes and far too loose on others, usually loose exactly where the expensive bugs live.
Blind classes need out-of-band confirmation. Blind SSRF, out-of-band SQL injection, XXE with external entity resolution, deserialization gadgets that only produce a network callback. The defining property is that the response tells you nothing. Timing deltas are the trap here, because network jitter and an unrelated slow query produce the same signal an agent will read as success.
The primitive is a collaborator service. The agent embeds an identifier unique to each attempt, and confirmation means an inbound DNS or HTTP interaction arrived carrying that identifier. Per-attempt uniqueness is not a detail. Without it you can't attribute the callback to a specific request, and on any target with background traffic you will eventually credit somebody else's interaction to your payload.
XSS needs an execution event, not a reflection. A payload appearing intact in the response body proves nothing. It can land in a context the parser treats as text, or in a script block that never runs, or get stopped by a CSP directive. Response matching is where scanner XSS false positives come from, and an agent reasoning over raw HTTP makes the same mistake with better prose.
The primitive is a headless browser that renders the page the way a user's browser would and reports whether a controlled callback actually fired. That is an observed event. It also handles stored XSS correctly, because injection happens under one session and the fire is observed under another. For DOM-based cases there is no server response to inspect at all, so without browser instrumentation you are testing the transport rather than the bug.
Access control needs two identities. An enumerable object identifier is not an IDOR. Proof is a resource belonging to identity A returned under a session authenticated as identity B.
The primitive is an identity model in the harness: at minimum two accounts at the same privilege level for horizontal tests, plus a low-privilege and a high-privilege account for vertical, with a record of which objects belong to whom. Without object ownership tracked, an agent retrieves something its own session already owns and reports an IDOR, having proven that authorization works.
SQL injection needs extraction or an inverting differential. A database error means input reached a parser. It does not mean the parser can be steered. Proof is either a value the agent can independently verify is database state, or a boolean condition that returns true when asked for true and false when asked for false, repeatedly. The second half of that sentence is the part that gets skipped.
Code execution needs the smallest sufficient side effect. A repeatable delay that scales with the value requested. A DNS lookup to controlled infrastructure. Reading a single marker file. Any of those settles the question completely. An interactive shell on a production host is a demonstration, not additional evidence, and the destructive-action policy that says so is enforced at the harness rather than left to the agent's judgment. The agent's judgment is exactly what you cannot rely on when the model has decided a bigger result would be more convincing.
Every one of these runs through a proxy that records the request and response at the wire. That is deliberate. If evidence is reconstructed from the agent's account of what it did, the evidence inherits every failure mode of the agent's memory, including fabrication. Captured, the agent's memory becomes irrelevant to the record. The agent can be wrong about what happened. The wire log isn't.
A SAST finding is a claim about a code path. It says untrusted input at line 40 reaches a dangerous sink at line 214 without adequate transformation in between.
That claim is frequently true and frequently irrelevant, which is why SAST backlogs are what they are. The route may not be deployed. It may sit behind an authentication middleware the attacker can't get past. A framework-level sanitizer the analyzer didn't model may neutralize it. A WAF rule may block the only input shape that reaches the sink. The code is vulnerable; the running application may not be.
The pathway from claim to proof requires both halves. Give the platform the repository and the running instance, and the sequence is:
That last step is the one worth dwelling on. A SAST finding that cannot be driven to a runtime result does not get deleted. It gets downgraded with the reason attached: route not exposed, blocked at the edge, sanitizer effective, requires an identity the attacker can't obtain. Now your developers have something better than a ticket. They have a ticket with an argument they're allowed to disagree with.
This runs in both directions, which matters more than it sounds. A runtime finding traces back to the exact handler, the exact file and line, the commit that introduced it, and the team that owns the repository. Code teams and cloud teams have spent years looking at the same problems through different windows without knowing it. Bidirectional traceability is what closes that.
SCA output is the largest and least useful pile in most programs. A package is present at a vulnerable version. That is a true statement about a lockfile. Three gates stand between that and a finding worth anyone's afternoon.
Is the vulnerable function actually called? Most CVEs affect a specific function or code path, not the whole library. A call graph over the indexed code answers this, and it kills a large fraction of the pile immediately. You imported the library for one utility and never touched the vulnerable component.
Is it reachable from attacker-controlled input? The function is called, but with values your own code constructs. Taint tracing from untrusted sources through to that call settles it. If the input never arrives, nobody spends an hour proving it by hand.
Does the deployment meet the exploit's preconditions? Many published exploits require a configuration flag, a specific version of a co-dependency, a particular runtime, or a feature your deployment disables. This is where cloud and asset context does the work: the platform already knows the runtime version, the framework, and what's in front of the service.
Only after all three does the agent go and attempt it against the running instance, producing the same evidence artifacts as any other confirmed finding.
The point of the gates is not efficiency. It's that a dependency finding shipped without reachability is functionally a rumor, and a backlog full of rumors trains your engineering team to ignore the security queue. That damage outlasts the engagement.
A secret scanner finds a high-entropy string that matches a credential pattern. Extremely high false positive rate, extremely high consequence when it's real, and almost no way to tell from the string itself.
The proof obligation here is unusually clean: does it authenticate, and what does it grant.
The agent takes the candidate, identifies the service it belongs to from the token format and surrounding code context, and attempts authentication against that service. Confirmed means a successful auth response. Then, and only within scope, it enumerates what that identity can see, its own permission set, its own accessible resources, and stops there.
That second half is the difference between a finding and a risk statement. "A live AWS key was committed to this repository" is a finding. "A live AWS key was committed to this repository, it belongs to a principal that can read the production secrets bucket, and here is the permission enumeration that shows it" is a risk statement with a severity you can defend.
The non-destructive line is important and easy to get wrong. Authenticate, enumerate own permissions, do not act. Reading the bucket listing settles the question. Downloading the bucket does not settle it any further, and now you have someone else's production data in an evidence store.
Same pathway applies to secrets found outside repositories: keys embedded in JavaScript bundles, tokens in mobile app binaries, credentials in a container image layer, values leaking through a verbose error page. The discovery channel differs. The proof is identical.
A technical bug and the risk it represents are different objects, and the gap between them is almost entirely cloud identity.
Remote code execution on a container running with a tightly scoped read-only role is a contained problem. The same bug on a container whose role can read your entire secrets store, assume three other roles, and write to a bucket shared with four applications is an incident. Identical CVSS vector. Wildly different severity.
Without that context you either inflate everything or flatten everything, and engineering stops trusting your severities either way.
So a confirmed foothold triggers a second validation step. The platform already knows, from cloud integration, the IAM role attached to the workload, the policies attached to that role, the trust relationships, the buckets it touches, and the secrets it can read. The agent validates the consequential ones: exercising a read permission, confirming a role assumption is actually permitted, checking whether a network path to an internal service exists from that position.
Read-only, non-destructive, logged. The output is a blast radius with evidence behind each edge rather than a theoretical one derived from policy documents.
This is also the pathway that makes a finding legible to people who don't read HTTP. "The billing container can reach production secrets" is a sentence a board understands. It happens to be backed by a captured request, which is why it holds up when someone pushes back.
Individually rated findings are where chains go to die.
A missing rate limit on a verification endpoint is a Low. A session token that doesn't rotate after privilege change is a Low. A settings handler missing a role check is a Medium. A webhook destination that isn't validated against an allowlist is a Medium. An instance metadata service accepting unsigned requests is a Medium.
In most programs the first two get closed as accepted risk and the rest sit in a queue. In sequence, they take an unauthenticated attacker to cloud credentials.
Proving a path carries an obligation the individual bugs don't: the state produced at each hop has to be recorded as the precondition for the next one. Not "these five findings exist," but the session hop two produced, used in hop three, producing the write that hop four depended on, producing the callback that hop five confirmed. Without that, you have a plausible story about five findings, which is a hypothesis wearing a chain's clothing.
Two things make this possible and both are architectural rather than clever. The first is shared state across agents, so the agent working authorization can see what the agent working session management just recorded. Eleven agents running in parallel with no visibility into each other produce eleven independent findings; the same eleven with a shared workspace can notice that one output is another's input. The second is the relationship graph underneath, which is what lets a code-layer finding, an application-layer finding, and a cloud-layer finding be recognized as adjacent at all.
This is the structural reason scanning never finds chains, and the reason chained findings are where the value in an engagement sits.
A validated finding is a statement about a system at a moment. The system changes every release.
Which is why the replay script is the more durable artifact, not the report. When the fix ships, the exploit runs again from stored preconditions and the ticket closes because the attack was blocked, rather than because a developer said it was handled. When the next release goes out, it runs again, because reintroduction is common and nobody notices it without a check.
Recording preconditions alongside the exploit matters here specifically. If the replay depends on a session, a token, or a record that no longer exists, it fails for reasons unrelated to the fix, and everyone draws the wrong conclusion.
Over enough cycles this also becomes a calibration signal that's specific to your environment. You learn which classes of finding on your stack turn out real and which reliably get closed as noise. That isn't something available off the shelf.
Different inputs, different primitives, but the same four controls sit underneath all of them.
Around all of them: scope allowlists, rate limits, destructive-action policy, approval gates, an encrypted vault, an isolated sandbox per engagement.
Capture over reconstruction. Every request and response recorded at the proxy, so evidence doesn't depend on the agent remembering correctly.
Grounding. Every reference in a finding has to resolve to something real: an indexed file, a captured exchange, an enumerated cloud resource. Models that have been exploring for forty turns start citing paths that don't exist. If the reference doesn't resolve, the finding doesn't ship regardless of how good the reasoning looked.
Observation separated from conclusion. Agents record what they saw in one place and what they concluded in another. A finding is promoted only when the observation carries the claim with the narrative stripped out. That single structural decision did more for accuracy than any amount of prompt work.
Independent re-execution. Non-determinism is real. A result that reproduces once and not again is not a result, so every candidate re-runs from clean state through a validator that is not the agent that found it.
And around all of it, controls that live in the harness rather than in a prompt: scope allowlists, rate limits, destructive-action policy, approval gates on high-impact steps, an encrypted vault so credentials can be used without ever appearing in a transcript, and an isolated sandbox per engagement. Scope written into a prompt is a suggestion. A system that can be argued out of its constraints doesn't have constraints.
A platform that reports everything with equal confidence is telling you it can't tell the difference.
Ambiguous business logic. Whether a transaction should have been permitted can depend on subscription tier, account state, geography, approval history, and prior actions. A technically valid 200 can represent an invalid business action, and no protocol-level evidence settles a question that isn't at the protocol level.
Accepted risk and compensating controls. An agent will report an unsupported service as critical when you already know, accepted it, and isolated it three years ago. Technically correct, operationally useless. Exploitable-in-isolation is what a run measures. Whether it matters given the controls around it stays your call.
Architectural weakness. Decisions that are correct at every line and wrong in aggregate have no exploit to capture. They have an argument, and arguments need a reviewer.
Novel technique classes. Applying and chaining known families is a different problem from finding a new one.
Environments where the demonstration is itself the risk. In OT and ICS the proof can affect physical processes. That needs specialist controls and specialist operators, not a more careful prompt.
The reason to point agents at your environment was never that they generate more findings. You have enough findings. It's that a system built around evidence can answer the question your backlog can't: not which of these is severe, but which of these an attacker can use, with the request that settles it attached.
