The Scanner Is Not the Verifier

Sep 29, 2026 6 min read

The impressive part of Google’s PageBreak project is not that an AI agent found vulnerabilities. It is that Google refused to treat a plausible finding as a result.

In a September 24, 2026 post, Google described PageBreak, an internal Product Security agent that tests first party web applications. The system uses deterministic validators to confirm suspected flaws against running environments. Google says the project has uncovered more than 500 XSS vulnerabilities while maintaining a near-zero false positive rate.

Those numbers are Google’s own reported results, not an independently reproduced benchmark. The architectural decision is still clear: the model proposes a path, but a separate mechanism must prove that the path works.

That is the difference between an AI scanner and a security system.

The finding is only a hypothesis

A language model can produce a convincing explanation for a vulnerability without having demonstrated one. It can infer a data flow that does not exist, misunderstand a framework boundary or mistake a dangerous-looking string for an exploitable path.

The output may look like a report. Operationally, it is a hypothesis.

PageBreak’s design makes that distinction explicit. Google says the agent passes a suspected flaw to a validator that executes a real test against a running environment. The validator depends on the vulnerability class:

Suspected flaw	Deterministic check described by Google
Cross-site scripting	Inject a JavaScript payload and observe whether it executes in a rendering harness
SQL injection	Manipulate a query and verify output or timing changes
Path traversal	Create a file in a world-readable location and check whether the application can read it
Remote code execution	Test for an observable effect such as a delay, file creation or outbound request
SSRF	Check whether the application makes a request to an internal service

The important property is not that these checks are sophisticated. It is that they measure a state change outside the model’s explanation.

The verifier closes the loop

A weak security agent has a loop like this:

read code -> propose vulnerability -> write report

That loop ends at language. It rewards a coherent story, even when the system has not changed in the way the story predicts.

A stronger loop looks like this:

read code and runtime signals
  -> propose vulnerability
  -> construct a bounded test
  -> execute against a permitted environment
  -> observe the effect
  -> report only when the effect matches the claim

The verifier is not a formatting step after the agent finishes. It is part of the agent’s control structure.

This is why the PageBreak story matters to agent builders outside security. The same pattern applies whenever an agent can make a claim about the world. A coding agent should not report that a migration succeeded because a command returned zero. A deployment agent should not report healthy because a process started. A research agent should not treat a cited paragraph as evidence until the source and the claim match.

The executor proposes or performs an action. The verifier checks the resulting state.

Google keeps two kinds of findings separate

Google also describes a useful asymmetry. Deterministic validation is the standard for sending a finding to a product team, but non-deterministic findings still have a role.

Unverified candidates can seed later runs, reveal missing validator capabilities and guide the development of new checks. They are not discarded. They are kept out of the high-confidence reporting channel.

That separation is more important than trying to make every model output perfectly reliable. A system can tolerate uncertain internal hypotheses if the boundary around external action is strict.

The mistake is allowing an unverified candidate to cross the same boundary as a proven vulnerability. Once both are called findings, downstream teams cannot tell which work is safe to prioritize.

The uncomfortable cost of proof

Deterministic validation is not free. A validator needs access to a live or representative environment, a safe way to execute the test and an oracle that distinguishes the expected effect from noise.

Google’s examples expose the operational burden. An XSS validator needs a rendering harness. An SSRF validator needs visibility into the outbound request. An RCE check needs a controlled observable effect. Each validator is a piece of security infrastructure, not a clever prompt.

The validator can also produce false negatives. Google explicitly says its deterministic validators do not yet cover every vulnerability type or complex scenario. A finding that cannot be proven is not necessarily harmless. It may mean the proof system is incomplete.

That creates a two-lane design:

High-confidence lane: verified findings can trigger tickets, fixes or automated remediation.
Exploration lane: unverified hypotheses can seed deeper investigation, but cannot silently become production actions.

The model gets room to explore. The operator gets a hard boundary around what the system is allowed to assert or change.

Why model quality is not the main bottleneck

It is tempting to read PageBreak as another demonstration that a larger model can find more complex bugs. Google says PageBreak is flexible across models, although most usage is based on Gemini models such as Gemini 3.1 Pro and Gemini 3.5 Flash.

That is relevant, but it is not the core lesson. A stronger model can generate better hypotheses. It does not remove the need to test those hypotheses against reality.

Google also points to the surrounding substrate: a large monorepo, security signals from live HTTP traffic and existing scanners that can authenticate to many applications. The model’s context and tools determine which paths it can inspect. The validator determines which claims can graduate into trusted output.

The system is therefore a stack, not a model:

model reasoning
  + source and runtime context
  + specialized tools
  + deterministic validators
  + policy for unverified output
  + audit trail

Remove the validator and the stack becomes a fluent source of security noise. Remove the access controls and the validator becomes an agent with permission to probe whatever it can reach. Remove the audit trail and nobody can reconstruct why a finding was accepted.

What operators should build

If you are deploying an agent that investigates vulnerabilities, do not begin with a blocklist of dangerous strings. Begin with the proof boundary.

Define, in advance:

Which environments the agent may test.
Which effects count as proof for each vulnerability class.
Which tools perform the proof independently of the model’s narrative.
Which findings remain exploratory and which may create tickets or changes.
Which human approval is required before a test can affect a shared environment.
Which logs preserve the input, test, observation and decision.

Treat every validator as a security-critical component. It needs least privilege, bounded targets, explicit timeouts and an output that can be audited later. A validator that can test anything is not a verifier. It is another attack surface.

For general agent systems, use the same rule in simpler form. Every important claim needs a state check that does not merely repeat the agent’s own words.

Check the file. Query the deployment. Re-read the record. Compare the requested change with the resulting state. If the agent says it completed an action, verify the external effect.

The scanner finds possibilities. The verifier earns trust.

Sources: