Google Open-Sources Mantis: AI Agents That Find, Validate and Fix Software Vulnerabilities

Google has open-sourced Mantis, a framework that deploys specialized AI agents to find, validate, reproduce and patch software vulnerabilities. The system addresses two persistent problems in AI-powered code scanning: findings that describe plausible vulnerabilities without proving an application can actually reach the vulnerable code, and true-positive rates so low that developers spend more time disproving false alerts than fixing real flaws.

Google says some AI-assisted scanning workflows generate true-positive rates below 7%. That statistic limits the value of such tools in automated security pipelines. Conventional scanners often flag suspicious code patterns without enough repository context—missing the surrounding architecture, dependency relationships and earlier security fixes that determine whether a flaw is actually exploitable.

Context Building with Summarization

Mantis builds context before it searches. The summarize stage converts analyzed files into a hierarchical tree that preserves directory structure and repository-level information. Google reports that this summary reduces token consumption by 85% while retaining the context agents need for later analysis. That reduction lowers model costs and creates more room for source-level reasoning within a fixed context window.

Multi-Agent Investigation Architecture

Once the system has mapped a codebase, a strategist agent examines the repository’s high-level structure, trust boundaries and threat model. Research agents then trace data flow through individual functions—following a value from an external input to a database call, command execution path or authorization check. Critic agents challenge proposed findings, and reviewer agents apply additional checks before the system promotes a result. Reviewers can question whether an apparent flaw depends on unreachable code, an existing sanitizer or a configuration the repository never enables.

This division of labor gives each model a narrower task. A critic might ask whether an input actually reaches a dangerous sink. A reviewer might verify whether the suspected vulnerable code path can execute in practice. Mantis groups these capabilities into more than 15 tools that teams can run in sequence or parallel, depending on the repository and available compute budget. The shared on-disk state lets maintainers inspect intermediate results and rerun a failed stage without restarting the entire workflow.

Sandboxed Reproduction

Language models can generate convincing explanations for vulnerabilities that don’t actually exist in a runnable code path. Mantis addresses this with a reproduction stage that runs findings inside a sandboxed environment. The reproduce stage writes a functional crash reproducer or test case that exercises the suspected flaw. The sandbox limits the impact of that test while giving security engineers inspectable evidence. A reproducer can also streamline triage—developers can run the test against a patched revision, add it to a regression suite or compare behavior across versions. The test converts a model-generated claim into an artifact that an engineer can evaluate directly.

Mantis also includes a patch stage that generates a side-effect-free fix for the codebase. Teams still need to review the change, run their test suite and check for regressions, but the patch stage can shorten the path from confirmed vulnerability to candidate fix.

Model Selection and Pipeline Cost

Model selection affects pipeline cost. Mantis supports multiple models and lets teams assign different models to different stages. Google recommends flash or lite model variants for classification and pattern-matching work—triage and duplicate clustering, for example. The framework reserves stronger models for tasks that need extended context and zero-shot problem solving. Reproduction requires a model that can write a working test against unfamiliar code. Patch generation requires a model that can modify code without breaking adjacent behavior. A pipeline can use a smaller model to group similar findings, then route a short list to a stronger model for reproduction and patching. The design also creates a path for model upgrades: teams can replace the model at one stage, compare results with the previous version and keep the rest of the workflow stable.

False Positive Management

False positives remain a central concern. The review stage applies a rule-based negative filter to remove findings that match known false-positive patterns. Google warns teams to keep that filter narrow. A low-risk finding can still reveal a real vulnerability, and a broad rule can hide a flaw before a human examines it. Reviewers should inspect the evidence, configuration and reachable execution path before dismissing a result. A useful practice is preserving rejected findings in an audit record. Engineers can then measure how many dismissed findings later proved valid and adjust the filter with evidence from their own codebase.

Getting Started with Mantis

Teams evaluating Mantis can start with a single repository and run summarization, research and review stages against a known set of security issues. That baseline shows whether the system finds existing vulnerabilities and how much triage work it creates. The next step can add sandboxed reproduction for findings that pass review. Engineers should capture the generated reproducers, compare them with existing tests and inspect the sandbox boundaries before connecting the workflow to a production CI gate. Patch generation should come after teams understand their review and reproduction results. Developers can treat each generated patch as a candidate change and require normal code review, unit tests and security testing before merge.

Mantis gives security teams a concrete pattern for agentic scanning: build context, divide the investigation, challenge each finding and reproduce the result in a controlled environment. The workflow addresses the main weakness of model-based scanners, which can produce convincing explanations without sufficient evidence of an exploitable code path.