Pentrova has one gate that decides whether a candidate becomes a finding in your queue: AI review of the evidence captured from your target. Everything upstream of it — the planner, the agents, the replay check, the sandbox — produces evidence; only the gate decides. Keeping that decision in one place makes the trust boundary between an agent’s evidence and the platform’s output easy to reason about.
This post is the design rationale: why a single gate is the right call for a trust boundary, what its contract is, and where the replay check and the sandbox fit. For the runtime mechanics, see verifier internals.
The trust boundary problem#
An automated pentest has a structural tension. The adaptive planner and agents are large, evolving, and — by design — allowed to be speculative; their job is to propose. But the decision “this is a real finding” must be conservative, stable, and auditable. Spreading that decision across the speculative machinery would mean the trust boundary moves every time the agents change.
So Pentrova draws a hard line: agents propose, the gate disposes. Everything you see in your queue flows through one place.
The binary contract#
The gate’s contract is binary: given a candidate finding and the evidence captured for it, the AI review either confirms it or does not.
- A confirmed finding reaches your queue.
- A finding that is not confirmed never reaches your queue.
- There is no “probably” branch in what you see.
That binary contract is what keeps the queue short. Evidence feeds the decision; it does not replace it. A finding can be confirmed without a re-sent request or a sandbox proof, on the AI review of the evidence captured from your target, and the platform says so plainly instead of calling it a replay.
The replay check and the sandbox are evidence, not verdicts#
The replay check is deliberately narrow. Where a finding can be re-checked with a read-only GET or HEAD request, Pentrova re-sends it once from a fresh HTTP client and compares the response with a clean baseline. The result — reproduced, not reproduced, inconclusive or skipped — is one input to the AI review, never a verdict on its own. State-changing requests are never re-sent, and out-of-band, passive and timing findings skip the check. It runs directly, not inside the sandbox.
The sandbox is a separate component. Exploit checks run from an isolated sandbox that can reach only the hosts you have authorised; private and internal networks are blocked. What it captures is evidence for the same gate.
Stability as the catalog grows#
Because the gate’s contract is fixed, two good properties follow:
- Customers can read its behaviour in the documentation: every finding in your queue was confirmed by AI review of evidence captured from your target.
- New checks land by adding evidence, not by moving the gate. A new agent or attack chain produces evidence; the decision about what reaches your queue stays in one place.
A gate that changed shape for every new attack class would be a gate nobody could trust, because its behaviour would be a moving target. Keeping the decision in one place is what makes it auditable.
Key takeaways#
- Agents propose findings; one gate disposes: AI review of evidence captured from your target.
- The contract is binary: a finding is confirmed, or it never reaches your queue.
- The GET/HEAD replay check and the sandbox produce evidence for that review; neither confirms a finding on its own.
- New checks add evidence, never a second gate, so the trust boundary stays stable and auditable.
FAQ#
Why keep the decision in one gate instead of spreading it across components? Because it is a trust boundary. When one place decides “is this real”, it is easier to reason about and harder to ship a finding that skipped review. Checks and features belong upstream, as evidence.
Where does the replay check fit? It re-sends a read-only GET or HEAD request once from a fresh HTTP client and compares the response with a clean baseline. The result is one piece of evidence the AI review weighs; it never confirms a finding on its own, and it does not run in the sandbox.
Does adding new attack chains change the gate? No. Chains are confirmed the same way as single findings: AI review of the evidence decides. AI analysis of the confirmed findings describes how they combine, and Pentrova never re-sends a state-changing request to prove a chain.
Read the runtime mechanics in verifier internals, or see the sandbox in the pipeline.