In Brief: An AI agent for vulnerability discovery is useful as part of a pipeline, but its alert—and even its patch—should not be treated as proof of remediation. Reliable approval requires reproducing the attack with multiple inputs, confirming the vulnerable path is reachable, eliminating the root cause, preserving correct behavior on safe data, and only then allowing a human to approve the merge.
This article is intended for CTOs, CISOs, engineering leaders, and AppSec and DevSecOps teams. It examines source code and auto-patch validation; it does not evaluate a specific product, does not promise to find all vulnerabilities, and does not replace manual analysis of critical components.
Contents
- What Google's setup showed
- Why high precision does not equal full protection
- Where auto-patching passes the test but still leaves risk
- PATCH: Four proofs of remediation
- Minimal experiment: one PoC versus root-cause validation
- How to integrate an AI scanner into CI/CD
- Metrics for deciding whether to scale
- Proof limitations
- Frequently asked questions
- How AgentSunrise helps build a verifiable control loop
- Conclusion
What Google's setup showed
On September 18, 2026, Google described an internal agentic pipeline for protecting infrastructure code. It scans every change before merge into a codebase of hundreds of millions of lines, and at night it re-checks for issues that emerge at the intersection of multiple changes. According to Google, the setup prevents hundreds of vulnerabilities per month from reaching code or production.
The key architectural detail is not one universal agent, but separate roles:
- a fast agent looks for a potential issue in a small diff;
- a specialized triage agent checks program structure through the AST, call graph, and domain rules;
- a deeper nightly check looks for cross-component effects;
- a remediation agent proposes a patch and a demonstration snippet;
- a human reviews the change together with the standard code review.
Google reports more than 92% precision for the triage agent and review time of less than one minute. For some configurations, local threat models reduced the false-positive rate to 3%. These figures matter, but they describe only Google's observed conditions and metrics. They do not disclose recall, the distribution by vulnerability type, the absolute number of checks, or the share of patches that preserved all business logic.
The public Mantis repository confirms the modular design: threat-model building, hypothesis search, deduplication, triage, reproduction, patching, and adversarial verification. At the same time, the README warns that models are nondeterministic, can invent findings and incorrect patches; a specialist must review the results, and the harness should run only in an isolated environment with no access to production or sensitive data.
| Stage | What it confirms | What it does not yet confirm |
|---|---|---|
| agent finding | the code resembles a dangerous pattern | the path is reachable and exploitable |
| structural triage | there is a path through the program structure | the attack works in the real configuration |
| reproducing example | a specific input triggers the effect | the root cause and all variants have been found |
| patch | the original example no longer works | adjacent attacks are closed and the function is preserved |
| tests and human review | the claimed set of properties has been verified | all unknown vulnerabilities have been eliminated |
Practical takeaway: an AI scanner is a generator and verifier of hypotheses, not an automatic security certificate.
Why high precision does not equal full protection
Precision answers the question: what share of raised signals were true. Recall answers a different one: what share of all existing vulnerabilities the system found. You can achieve high precision by reporting only obvious problems and still miss rare but critical classes.
The phrase “false-positive rate 3%” also needs a denominator. It may mean the share of false signals among all alerts, among safe changes, or within one selected class. Without a metric definition, sample, and threshold, the value cannot be transferred to another codebase.
NIST IR 8397 recommends not one technique but a set: threat modeling, automated tests, static analysis, checks for built-in defenses, black-box and structural tests, historical cases, fuzzing, web scanners, and dependency analysis. NIST SSDF 1.1 further links secure development to fixing discovered issues and eliminating the causes of their recurrence.
For a purchase or pilot, it is useful to ask not for general accuracy, but for a matrix:
| Question | Minimum proof |
|---|---|
| What does the system find? | CWE/risk classes, languages, frameworks, versions |
| How much noise does it create? | precision and reviewer load by criticality |
| What does it miss? | recall on a hidden set and a list of blind spots |
| Does the attack work? | reproducible exploit/PoC in isolation |
| Is the root fixed? | multiple independent attacker inputs and data/control flow analysis |
| Is the product still working? | unit, integration, property, and semantic regression tests |
Where auto-patching passes the test but still leaves risk
Recent work PatchBench shows why a single PoC is not enough. The authors assembled 213 tasks for patching from 32 real-world projects and 16 CWE types,"text":"then tested"},{ 11 agents. On average 83.1% of generated patches stopped the original PoC, but only 45.3% of tasks passed both security and semantic validation at the same time. Checking with a single PoC overstated the solve rate by 1.83x.
The study identified two different shortcuts:
- on average 25% of agent patches were substantially similar to historical fixes by developers, so a strong result may have reflected memorization of a public patch;
- the agent often placed a guard at the crash site instead of fixing the root cause earlier in the data flow, turning a crash into a silent error.
In PatchBench, the best agents passed more than 97% of the original PoCs, but after several adversarial inputs and semantic validation they solved about half the tasks. For 67 tasks , none of the 11 agents succeeded. This is a preliminary arXiv preprint on C/C++ and selected projects, not a universal evaluation of any commercial scanner, but it does a good job separating “it stopped crashing” from “it was fixed safely.”
PATCH: four proofs of a fix
We propose the PATCH framework. This is an original synthesis by AgentSunrise based on Google’s outline, PatchBench, and NIST guidance; it is not an official standard from any source.
P — attack path
Document the source, sink, reachability conditions, privileges, and configuration. A static signal without a reachable path remains a hypothesis. But the absence of an automated reproduction also does not prove a false positive: the environment may not have modeled the required state.
A — attack variants
Test not just one published PoC, but a family of inputs: altered encoding, boundaries, alternative protocols, concurrency, and adjacent paths. Fuzzing and property-based tests reduce the chance that the patch simply recognized one specific string.
T — root-cause point
Match the point of manifestation to the point of origin of the defect. A guard near the crash may hide the symptom. The report must include the root cause, the changed invariant, and an explanation of why the fix covers the whole class of inputs.
C — human approval and target function
Check safe inputs, unit/integration tests, output state, and business invariants. A security test proves the absence of one dangerous effect; a semantic test proves the useful function was not removed. Final merge for critical code is approved by a human who sees both sets of evidence.
A patch approval card may look like this:
| Field | Content |
|---|---|
| target | repository, commit, build, dependencies |
| threat | CWE, attacker capability, asset, impact |
| path | source → transforms → sink and reachability conditions |
| attacks | original PoC, variants, fuzz corpus, negative cases |
| root cause | broken invariant and fix location |
| semantics | safe inputs, unit/integration, output comparison |
| review | owner, reviewer, decision, exceptions, expiry |
Minimal experiment: one PoC versus root-cause verification
We ran a deterministic demo on a file-reading function. The vulnerable version allowed escape from the allowed directory. The “superficial” patch blocked the string ../ , while the root-cause patch allowed access only after path canonicalization and verification that the path belonged to a trusted directory.
The set included 5 cases: the original traversal PoC, an absolute path, escape via a symbolic link, and two safe reads. The superficial patch scored 3/5: it stopped the original PoC and preserved two normal scenarios, but missed the absolute path and symlink escape. The root-cause check scored 5/5.
This is not a benchmark of an AI agent, not a production-code analysis, and not proof of superiority for any specific algorithm. The demo shows a narrow point: a positive result on a single PoC is compatible with a vulnerability remaining, and the set must include both attack variants and allowed behavior. The reproducible script is saved in the paper’s research artifacts.
How to integrate an AI scanner into CI/CD
1. Start with a limited risk class
Choose one language, service, and 2–4 vulnerability classes with a clear oracle: for example, path traversal, command injection, or SSRF. Do not start by promising to “scan everything.”
2. Separate generation, triage, and approval
The discovery agent should not single-handedly confirm its own finding. Use separate rules, static analysis, or another agent for triage; leave merge approval to a policy gate and reviewer.
3. Isolate reproduction
Run with minimal privileges, no production credentials, and no internal network. Restrict the file system, network, process tree, time, and budget. Save all commands and tool calls.
4. Require two test sets
The security set should include the original PoC and variants. The semantic set should include safe inputs and business invariants. A patch does not pass the gate if it blocks the attack by disabling the feature.
5. Save evidence, not just a comment
Attach the commit, threat model, reproducing example, root-cause note, logs, tool versions, before/after results, and a human decision to the issue. Then the check can be repeated after a model or harness change.
6. Roll out by autonomy level
The first mode is a comment without code changes. The second is a draft patch without merge. The third is an automatic PR with a required reviewer. Auto-merge is acceptable only for a predefined limited class where independent checks have been consistently confirmed on a hidden set.
Metrics for Deciding Whether to Scale
Do not reduce a pilot to the number of bugs found. A minimum dashboard should distinguish quality, effort, and residual risk.
| Metric | Formula or Unit | Why It Matters |
|---|---|---|
| precision | confirmed / all surfaced signals | reviewer workload |
| recall on the hidden set | found / all known vulnerabilities | misses |
| exploit reproduction rate | reproduced / confirmed | strength of the evidence trail |
| robust patch rate | security + semantic pass / proposed patches | quality of fixes |
| reviewer minutes | minutes per finding and patch | operational cost |
| escaped defects | vulnerabilities after the gate per unit of changes | residual risk |
| rollback/regression rate | rollbacks or defects after auto-patching | cost of a bad fix |
Compare these metrics with the current process at the same scope. “Hundreds of prevented vulnerabilities” without the number of reviewed changes, severity, and baseline does not provide portable ROI.
Evidence limitations
- Google’s numbers are a first-party description of internal infrastructure; the sampling method, recall, and full denominators were not published.
- The values “hundreds of millions of lines” and “hundreds of vulnerabilities per month” are approximate and do not prove causal impact from AI alone.
- The 92% precision and 3% false-positive rate apply to Google’s stated conditions; “in some cases” does not mean the average across all languages and risk classes.
- The public Mantis is described as a demonstration toolkit, not a supported Google production product; its README requires isolation and manual review.
- PatchBench is an arXiv preprint for C/C++, 213 tasks, and 11 agents; the results are not a ranking of all models, languages, or private repositories.
- The local 3/5 versus 5/5 demonstration tests five preannounced file-based cases, not the quality of the AI, scanner, or production patch.
- Russian production precision, recall, cost, review time, incident reduction, and ROI were not observed.
Search volume, keyword difficulty, rankings, traffic, CTR, backlinks, and AI citations are also Unknown. The article describes eligibility criteria, not a forecast of search or business results.
Frequently Asked Questions
Can an AI scanner replace an AppSec engineer?
No. It can expand coverage and speed up triage, but critical findings still require architecture context, impact assessment, patch verification, and human acceptance of residual risk.
What matters more: precision or recall?
Both metrics. Low precision overwhelms the team with false signals, while low recall leaves vulnerabilities undiscovered. The threshold is chosen based on severity and the cost of a miss.
Is it enough if the original PoC no longer works?
No. A PoC confirms only one entry point. You need attack variants, root-cause verification, and tests of correct behavior on safe data.
Can low-risk patches be merged automatically?
Only in a narrowly defined scope after validation on a hidden set, with independent security and semantic gates, logging, rollback, and a limited blast radius.
Why separate search and triage agents?
Separation reduces the risk of self-confirmation: a different control checks reachability, structure, and rules without repeating the generator’s same unconstrained inference.
Where should a small team start a pilot?
Choose one repository and one risk class, collect 20–50 historical and synthetic cases, measure the current baseline, run in “comments only” mode, and track reviewer minutes together with precision and recall.
How AgentSunrise Helps Build a Verifiable Workflow
AgentSunrise can help connect an AI agent to an existing development process without unverified security promises:
- define the scope, baseline, threat model, and acceptance criteria for one risk class;
- integrate search, triage, sandboxing, and logs into CI/CD;
- prepare security and semantic datasets, a policy gate, and a human review path;
- run a limited MVP, record metrics, and train the team to interpret evidence.
The first step is to choose one repository, one vulnerability class, the current baseline, and the acceptance criterion under the PATCH framework. Discuss the project.
Conclusion
Google’s recent experience shows that AI can embed vulnerability search and remediation into every code change. But transferable value comes not from the model name, but from role separation, a local threat model, structured triage, isolation, testing multiple attacks, and a human decision.
The working sequence is as follows: find the hypothesis → prove the path → reproduce the attack family → fix the root cause → verify safe behavior → approve the merge → monitor regressions. If a patch only passed the original PoC, it proved it learned to respond to one test, not that it eliminated the vulnerability.