Why AI Security Agents Need a Proof Stage

Google's PageBreak agent uses Gemini models to hunt for cross-site scripting flaws in Google's web applications. Since it entered full operation in January, it has found more than 500 XSS vulnerabilities. The interesting part is not the count. It is the rule that governs what gets reported. PageBreak does not send product teams a message saying "the model thinks this input is unsafe." It reports a vulnerability only after a deterministic validator reproduces the exploit against a running application. For XSS, that means actually executing JavaScript in the target context. Google's engineers describe this as a deliberate choice to prioritize deterministic validation, and they attribute a near-zero false-positive rate to it. Think about what a language model produces. It reads code and forms a plausible story about how untrusted input might reach a sink without escaping. Sometimes the story is right. Sometimes a framework auto-escapes, a middleware strips the payload, or the code path is unreachable. The model cannot reliably tell the difference, because it is reasoning about patterns, not executing them. A validator can. It sends the payload and checks whether the script runs. The two stages do different jobs. The probabilistic stage generates candidates cheaply and broadly, including places a human reviewer might not look. The deterministic stage is the filter that decides which candidates become tickets. Google also keeps unverified findings internally, to seed later scans and to find gaps in its validators, but those never reach product teams. The consequence is economic. Triage time is the scarce resource in appsec, and a report that cannot be reproduced burns it. A reproduction harness converts an unreliable stream of guesses into a smaller stream of demonstrated bugs. This is analysis, not a claim about PageBreak's internals: any agent that skips the proof stage shifts verification work onto the humans downstream.