Pentrova’s verifier is the component that decides whether a chain produces a finding. It is deliberately small. The smaller the verifier, the easier it is to reason about the trust boundary between an agent’s evidence and the platform’s output.
This post is the design rationale: why a minimal verifier is the right call for a trust boundary, what its one-function contract is, and how it stays stable as the chain catalog grows. 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. Putting that decision inside the speculative machinery would mean the trust boundary moves every time the agents change.
So Pentrova draws a hard line: agents propose, the verifier disposes. Everything the customer trusts flows through the smallest possible gate.
The one-function contract#
The verifier’s contract is a single function: given a candidate chain bundle and a target, it either reproduces the result or declines.
- A reproduction is sufficient evidence to mark the chain deterministic.
- A decline produces no finding.
- There is no “probably” branch.
That binary contract is what makes the output trustworthy. It is the architectural expression of deterministic proof over probabilistic CVSS: the verifier never emits a confidence score, because a score would reintroduce the ambiguity the whole design exists to remove.
Sandbox profiles keep the verifier context-free#
The verifier runs inside an ephemeral sandbox derived from the chain’s declared sandbox profile. Every command is constrained to a known allowlist, every network egress is logged, and every artifact is hashed before it leaves the sandbox.
Crucially, the sandbox profile is part of the chain definition, not the verifier. The chain author already decided what is sensitive in context, so the verifier never has to reason about whether a given command is dangerous — it just enforces the profile it was handed. That keeps the trusted component free of per-chain special-casing, which is exactly what keeps it small.
Stability as the catalog grows#
Because the verifier is so small and its contract is fixed, two good properties follow:
- Customers can read its behaviour in the documentation, and that behaviour is stable across chain updates.
- New chains land by extending the inputs, not the verifier. Adding a new escalation chain means authoring a chain definition and sandbox profile — the trust boundary does not move.
A verifier that had to change for every new chain class would be a verifier nobody could trust, because its behaviour would be a moving target. Minimal surface area is what makes it auditable.
Key takeaways#
- Agents propose findings; the verifier disposes — the trust boundary is the smallest possible gate.
- The contract is one function: reproduce the result or decline, with no probability branch.
- Sandbox profiles live in the chain definition, so the verifier needs no per-chain special-casing.
- New chains extend the inputs, never the verifier, so the trust boundary stays stable and auditable.
FAQ#
Why make the verifier small instead of feature-rich? Because it is a trust boundary. The fewer lines of code decide “is this real”, the easier it is to audit and the harder it is to introduce a bug that ships a false finding. Features belong in the agents, not the gate.
Where does chain-specific logic live, if not in the verifier? In the chain definition and its sandbox profile. The chain author encodes what is sensitive and what commands are allowed; the verifier just enforces the profile, which keeps it generic.
Does adding new attack chains change the verifier? No. New chains are new inputs — a definition plus a sandbox profile. The verifier’s contract is unchanged, which is what lets its behaviour stay stable and documented across releases.
Read the runtime mechanics in verifier internals, or see the sandbox in the pipeline.