Google open-sources Mantis, an agent framework that reduces false positives in vulnerability scanning

Google open-sourced Mantis, an AI agent framework that automates the lifecycle of a software vulnerability: identifying, validating, reproducing, and fixing it. The project is available on GitHub and was built to tackle a specific, well-known problem for anyone who has tried plugging an LLM into code analysis: the flood of false positives and hallucinated bugs.

According to Google, sloppily built AI-based scanning tools tend to deliver true-positive rates below 7%, meaning more than 93% of what the machine flags is not a real vulnerability. For security teams, that's not a minor detail: every false finding turns into a ticket someone has to open, investigate, and close. It's exactly this triage that Mantis tries to automate.

The problem the source describes

Mantis's starting point is a critique of brute-force scanning, the kind that sweeps file by file, throwing everything at the model and hoping the result makes sense. Google describes a different approach:

While sloppiness in AI code scanning frequently leads to hallucinated bugs and weak true-positive rates under 7%, we designed Mantis to be effective by combining industry-standard agentic techniques like critic and review agents with sandboxed reproduction of vulnerabilities for grounding.

>

-- Google, on Mantis

Instead of scanning blindly, Mantis analyzes the repository's history, past security fixes, the architecture, and the threat model. It condenses the analyzed files into a hierarchical tree with directory and repository context, which, according to Google, cuts token usage by 85% while keeping the relevant structural information. For whoever is paying the model API bill, that number matters as much as accuracy.

How the agents are divided

Mantis is organized as a modular set of skills, with more than 15 tools that run in sequence or in parallel. The stages communicate by reading and writing to a shared state saved to disk, a simple design that makes it easier to debug and chain steps together. Some of the agents described by the source:

• Strategist: assesses the high-level structure of the code, threat models, and dependency graphs.
• Research (mantis-researcher): uses internal code search to examine raw files in depth, tracing data flow, control flow, and sanitization logic.
• Critic (mantis-critic) and Reviewer (mantis-review): filter out false positives and prioritize findings that make sense.
• Reproduce (mantis-reproduce): writes working crash reproducers.
• Patch (mantis-patch): generates fixes without side effects.
• Summarize (mantis-summarize) and Dedupe (mantis-dedupe): summarize the code and group similar text patterns.

The differentiator compared to a conventional scanner lies in the sandbox reproduction step: instead of relying solely on the LLM's judgment, Mantis tries to reproduce the finding in a controlled environment, producing evidence that the vulnerability is real. It's the difference between "the model thinks this is a flaw" and "here's the crash that proves it is."

Different models for different tasks

A practical point the source highlights is the guidance to pair the right model with each task, instead of always using the heaviest model.

To maximize the speed and efficiency of your automated pipeline, you should strategically pair the right AI model class with the specific task. You do not need to use the heaviest, most advanced frontier models for every stage.

>

-- Google

In Google's recommendation, tasks that don't require deep reasoning, such as the quick classification done by mantis-researcher or the pattern grouping done by mantis-dedupe, can run on "flash" or "lite" variants. Steps that require contextual understanding and zero-shot resolution, such as mantis-reproduce (which writes the crash reproducers) and mantis-patch (which generates the fixes), call for more capable models. In practice, this is a cost strategy: you don't burn the expensive model on cheap triage.

The false-positive filter comes with a caveat

The mantis-review stage applies a rule-based negative filter to eliminate probable false positives. But Google issues a warning worth underlining: the filter should be used with caution, because low-risk findings should not be automatically classified as false positives. A negative filter that's too broad can reduce the system's ability to detect real vulnerabilities.

In other words, Mantis doesn't promise to eliminate noise entirely. The documentation itself acknowledges that every scanning system generates false positives, sometimes in a "frustrating" number, and that tuning the filter is a trade-off between less noise and less coverage.

What changes for those building software in Brazil

Mantis fits into Google's internal push to find and fix vulnerabilities at machine speed. For developers and AppSec teams here, a few concrete points:

• It's a harness, not a closed product. Being open-source and modular, you can plug the stages into an existing pipeline, choose which ones to run, and use the models you already have a contract with, including cheaper variants for trivial steps.
• The core promise is reducing triage work. If the sandbox reproduction step actually delivers what it promises, the savings aren't just in the scan itself, but in the hours currently lost manually confirming whether a finding is real.
• The token number matters as much as accuracy. The 85% reduction in token usage that Google cites is the kind of data point that decides whether running this at scale fits the budget.

The main question remains open: Google disclosed the architecture and cited the below-7% true-positive rate as the market's problem, but the InfoQ piece doesn't include an accuracy number for Mantis itself on a reproducible benchmark. It's worth watching for third-party validation before blindly trusting automated triage, especially on sensitive codebases. The agents' reference guide covers the details of each stage, the contracts between them, and best practices for use.