Security findings need a reachability receipt

On 18 September 2026, Google said it was scanning every code change across hundreds of millions of infrastructure-code lines and preventing hundreds of vulnerabilities each month. Its fast triage stage reported over 92% precision in under one minute.

The useful lesson is not “add another security agent”. Security findings need a reachability receipt before they consume human review: evidence that an attacker-controlled entry point can actually reach the reported path. A second model agreeing with the first is still an opinion, not independent proof.

Google checks reachability before asking for review

Google’s production account describes a lightweight pre-submit scanner followed by a specialised triage agent. That triage stage uses abstract syntax tree parsing, call-graph traversal and pre-indexed domain safety rules to test whether the vulnerable path is structurally reachable.

The reported figures are impressive, but they are internal Google results, not numbers I reproduced:

Google-reported measure	Result
Codebase scanned	hundreds of millions of lines
Vulnerabilities prevented	hundreds per month
Triage precision	over 92%
Triage latency	under one minute
False-positive rate with local threat models	down to 3% in some cases

Google reported these figures on 18 September 2026; no public data in the source establishes how they transfer to another codebase or threat model.

That boundary matters. The public Mantis repository confirms a modular workflow for threat modelling, triage, reproduction, patching and severity calibration. It also says the toolkit is a demonstration, not a supported production product, and warns that successful reproduction does not prove exploitability in every context.

Separate context is more important than separate agents

Google recommends keeping the development, scanning and triage harnesses, rules and context separate. That is the architectural point I would steal.

If the same generated explanation, assumptions and retrieved context flow through every stage, three agents can repeat one mistake with three voices. Independence comes from the evidence path: the triage stage should inspect code structure, the threat model and reachability without trusting the scanner’s narrative.

This is distinct from patch acceptance. I have argued that security agents should be scored on accepted fixes, not exploit trophies. The reachability receipt sits earlier. It decides whether a finding deserves reviewer time at all; the patch ledger decides whether that verified finding reduced risk.

My review rule: make the finding carry its path

This is labelled editorial judgment. I did not run Mantis, and I am not claiming a Trigent or client deployment. For an enterprise code-review queue, I would require four fields before an AI finding can page a human: attacker-controlled entry point, reachable call path, violated safety rule, and the structural or reproduction check that failed.

Keep the receipt compact enough to inspect beside the change. If a field is unknown, route the item to research rather than presenting it as a confirmed vulnerability. If the scanner and triage disagree, preserve both outputs; disagreement is useful evidence about the boundary, not an inconvenience to average away.

This also gives the team a better operational metric. Track findings admitted to review, reviewer-confirmed vulnerabilities and rejected receipts by failure reason. Raw model findings can remain a diagnostic count, but they should not become backlog, risk reduction or vendor value merely because the model used the word “critical”.

What's in it for you

• Stop speculative findings from taxing the most expensive security reviewers.
• Make threat-model drift visible when reachability checks start failing for the same reason.
• Separate discovery quality from patch acceptance and time-to-remediation.

Do not send a security claim to a human with another model’s confidence; send the attacker path and the check that proved it reachable.

Sources

• Google Cloud — Using agentic AI to secure infrastructure code, 18 September 2026
• Google — Mantis open-source security-agent toolkit, accessed 4 October 2026