Google Mantis: Agentic Vulnerability Scanning Harness

Google has open-sourced Mantis, an agentic vulnerability scanning harness — a pipeline of artificial-intelligence (AI) agents that validates security findings by reproducing them in a sandbox and drafts fixes for the ones that prove real. Google's stated motivation is blunt: sloppy AI code scanning "frequently leads to hallucinated bugs and weak true-positive rates under 7%."

What Is Google Mantis?

Mantis is an open-source AI-agent framework that automates the software vulnerability lifecycle end to end: identifying vulnerabilities, validating them, reproducing them, and fixing them. Sergio De Simone reported on the framework for InfoQ on September 6, 2026, and that InfoQ report on Google Mantis is currently the fullest public description of how the harness works. Google positions Mantis as part of its internal approach to finding and fixing vulnerabilities "at machine speed."

What separates Mantis from a brute-force file scanner is what it reads before it judges. Mantis analyzes repository history, previous security fixes, architecture, and threat models, so every finding is evaluated against how the codebase actually handles security rather than in isolation. If multi-stage agent pipelines are new territory for your team, our practical guide to AI coding agents covers the operational patterns these systems share.

How Mantis Validates Findings: Reproduce Them in a Sandbox

The core grounding mechanism is reproduction. Mantis can reproduce findings in a sandboxed environment, providing evidence that a finding is a real vulnerability "in a safe and controlled way," rather than relying solely on the judgement of a large language model (LLM). Google says it "designed Mantis to be effective by combining industry-standard agentic techniques like critic and review agents with sandboxed reproduction of vulnerabilities for grounding." For a developer, the difference is concrete: a finding that ships with a working crash reproducer is verifiable in minutes, while an LLM's opinion that a line looks dangerous is just another item in the manual triage queue.

One caution before wiring this into anything: the sandbox executes proof-of-concept code for findings that have not been proven real yet, which makes it a genuine security boundary. Agent-run code escaping sandboxes is not hypothetical — OpenAI's model escaped a sandbox and breached Hugging Face — so treat Mantis's sandbox as production-grade isolation, not a formality.

The agent roles: strategist, research, critic, reviewer

Around the sandbox, Mantis runs specialized agents:

• Strategist agent — evaluates the high-level code structure, threat models, and dependency graphs before deeper analysis starts.
• Research agents — use code search to examine raw source files in depth, tracing data flows, control flows, and sanitization logic.
• Critic and reviewer agents — industry-standard agentic techniques that filter out false positives and prioritize the findings worth acting on.

Architecture: 15+ Modular Skills, One Shared State on Disk

Mantis is organized as a modular skill suite of more than 15 tools that can be executed sequentially or in parallel, including mantis-summarize, mantis-review, and mantis-critic. The stages communicate by reading and writing to a shared state stored on disk.

That design choice is what makes Mantis pipeline-friendly. Disk-based stage contracts mean each step's output is inspectable, cacheable, and independently re-runnable — exactly the properties you want when vulnerability triage runs inside CI (continuous integration) rather than an interactive session. Google frames its own guidance around this use case: "To maximize the speed and efficiency of your automated pipeline, you should strategically pair the right AI model class with the specific task."

The full breakdown of every stage, the inter-stage contracts, and best practices live in Google's agent reference guide; both the GitHub repository and that guide are linked from InfoQ's Mantis coverage.

Matching the model class to each stage

Mantis supports multiple models, including combining different models for different phases. Google's cost guidance is explicit: "You do not need to use the heaviest, most advanced frontier models for every stage."

Stage	What it does	Model class Google recommends	Why
mantis-researcher	Rapid classification of findings	"Flash" or "lite" variant	Shallow task that does not require logic depth
mantis-dedupe	Clusters similar text patterns	"Flash" or "lite" variant	Pattern matching, not reasoning
mantis-reproduce	Writes functional crash reproducers	More powerful model	Needs deep contextual understanding and zero-shot problem solving
mantis-patch	Generates side-effect-free fixes	More powerful model	Needs deep contextual understanding and zero-shot problem solving
mantis-review	Rule-based negative filter for likely false positives	Not specified — the filter is rule-based	Deterministic filtering, no model judgement

The economics follow directly: cheap models on the high-volume shallow stages, frontier models reserved for the two stages that write code. For what each model class costs per token right now, see our AI model API pricing comparison. One calibration note before you lock choices in: model-class claims come from vendors, and our explainer on why LLM benchmark scores mislead is worth a read first.

Cutting Token Usage by 85% With Hierarchical Summarization

Before any agent reasons about a repository, mantis-summarize compresses the analyzed files into a hierarchical tree containing directory- and repository-level context. Google reports this reduces token usage by 85% while retaining important structural information — in effect, agents get a map of the codebase instead of the codebase itself.

Two caveats worth stating plainly. First, the 85% figure is Google-reported, not independently verified. Second, InfoQ's report includes no benchmark of Mantis itself: there are no published numbers yet for Mantis's own true-positive or false-positive rate, so "reducing false positives" is currently a design claim grounded in reproducers, not a measured result.

The False-Positive Filter Google Says to Tune Carefully

Every vulnerability scanning system produces false positives — "sometimes in a frustrating number," as Google puts it. Mantis's first line of defense is the mantis-review stage, which applies a rule-based negative filter to eliminate likely false positives before findings reach anyone's queue.

The warning attached to that filter is the most operationally important part of the announcement: low-risk findings should not automatically be classified as false positives, because an overly broad negative filter could reduce Mantis's ability to detect genuine vulnerabilities. In practice, that makes the filter a tuning surface rather than a set-and-forget switch — tighten it against your noise, then audit what it starts suppressing.

What to Do With Mantis Now

1. If you triage scanner output by hand today, start with a repository where you already know which findings are real. Run the pipeline there first so you can measure what the critic, reviewer, and reproduce stages catch — and what the mantis-review filter suppresses.
2. If you are cost-sensitive, follow Google's pairing guidance: flash- or lite-class models on mantis-researcher and mantis-dedupe, frontier models only for mantis-reproduce and mantis-patch.
3. If you own a release process, reproduced and validated findings are exactly the input a fixed security-release cadence needs; Next.js's monthly security release program is a mature example of that structure.
4. Before anything touches production, verify the sandbox setup — the reproduction stage executes code for unproven findings.

What InfoQ's report does not cover: licensing details, setup requirements, and a step-by-step CI recipe are absent from the announcement. Check the GitHub repository and the agent reference guide — both linked from InfoQ's coverage — for those specifics.