Google has replaced periodic, large‑scale vulnerability scans with an AI‑native security scanning workflow that evaluates every code check‑in in real time. By embedding high‑precision agents directly into the development pipeline, the approach delivers near‑instant feedback, reduces false positives, and automates remediation, which directly impacts the productivity and risk profile of engineers and security teams.
Why AI‑native security scanning matters
Traditional security assessments are performed as infrequent, heavyweight jobs that often miss vulnerabilities until after code is merged. The new workflow shifts detection to the moment of code submission, allowing each change to be examined with the full context of live metadata and call‑graph information. This reduces the window of exposure and aligns security with the speed of modern development cycles.
Key components of Google’s approach
Mantis multi‑agent harness – An open‑source framework that coordinates several specialized agents. It pairs scanning agents with localized threat models that are generated from live codebase metadata and dependency graphs, keeping the models current and driving false‑positive rates down to roughly 3% in some cases.
Pre‑submit scanning agents – Deployed as part of the developer’s existing toolchain, these agents run on each check‑in, using a lightweight validation step that parses abstract syntax trees, traverses call graphs, and applies pre‑indexed safety rules. The triage stage achieves about 92% precision and completes in under a minute, ensuring that developers receive actionable feedback without noticeable latency.
Post‑submit nightly scans – A secondary, more exhaustive scan runs during off‑peak hours to catch issues that span multiple changes or that were not fully covered by the pre‑submit pass.
Bug‑fix generation agents – When a vulnerability is confirmed, an autonomous agent constructs a fix that conforms to internal coding standards and attaches it to the original pull request for human review. This closes the detection‑to‑remediation loop within a single change cycle.
Architectural and operational considerations
Implementing a similar workflow requires separating the scanning pipeline from the main CI/CD execution to avoid resource contention. The pre‑submit agents must be lightweight enough to run on developer workstations or short‑lived build containers, while the post‑submit stage can leverage larger, batch‑oriented resources. Maintaining up‑to‑date threat models implies a continuous process of ingesting code metadata and dependency information, which may necessitate additional indexing services.
From an operational standpoint, teams need to monitor agent latency, false‑positive rates, and the success ratio of auto‑generated fixes. Governance processes should be established to review automated patches before they are merged, preserving code quality and compliance. Because the agents rely on live call‑graph data, any changes to build tooling or language versions may require adjustments to the model extraction pipeline.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
Practitioners should evaluate whether their current vulnerability scanning can be decomposed into a fast, pre‑submit component and a deeper, post‑submit component. Consider piloting a lightweight agent that uses AST analysis and existing dependency graphs to provide immediate feedback, and assess the impact on developer velocity and false‑positive volume. If the pilot shows acceptable latency and precision, extend the pattern with automated fix generation, but enforce a review step to retain control over code changes. Finally, invest in a process for continuously updating threat models from live code metadata to keep the scanning context accurate as the codebase evolves.
