The idea of having coding agents run a security review is not new. What is new is describing that work not as a single prompt but as a pipeline of linked stages.
Google has open-sourced exactly such a pipeline under the name Mantis. The tool is stack-agnostic: a set of skills you load into your existing agent, plus a strict set of rules about where that agent may execute code.
This guide covers what Mantis does, how a small team can try it safely, and where it should stop. It focuses less on install commands than on the decisions to make before trying the tool: where it runs, which stage cannot be skipped, and how much of the resulting report can be trusted. Get those wrong and the tool does no damage, but it does waste time.
What Mantis is and is not
Mantis is not a scanner you aim at a repository and walk away from. Each stage ships as a separate skill directory and is invoked as a slash command. The stages chain sequentially; if you prefer, a supervisor skill, the meta agent, drives the whole loop itself in a long-lived session.
Today you can clone it and run it with Gemini CLI, Antigravity CLI, the Google ADK or a comparable agent framework. Google publishes the tool under Apache 2.0, but its documentation states plainly that it is demonstration-only and not recommended for production.
- It is a reference implementation, not a product. It is not positioned as a supported Google service.
- It is not model-agnostic, but it is stack-agnostic: it does not dictate your language or framework.
- The inter-stage contracts are published, so the skills can be wrapped in a deterministic harness.
- It suits local and internal evaluation, not automatic runs against customer code.
The pipeline: learn, find, prove
The stages fall into three clusters. The first learns the target, the second produces candidate findings and filters them, the third proves a finding and patches it. That split is also the skeleton of the rest of this guide.
| Cluster | What it does | Notable skills |
|---|---|---|
| Learning | Maps the repository and the threat surface | Version history sweep, directory map, architecture note, threat model, plan |
| Finding and filtering | Generates candidates and drops false positives | Researcher, dedupe, review, critic |
| Proving and fixing | Reproduces the bug, patches it, scores the risk | Reproduce, chain, patch, calibrate, report |
The most interesting step in the learning cluster is the version history sweep. Security bugs closed in a repository's past are the strongest hint about where the same class will recur. Mantis reads that history and narrows the plan for later stages accordingly.
Publishing the stages as separate directories looks like a detail at first, but it is the most useful property in practice. You can remove a stage you do not need and insert one carrying your own rules. If you already have an internal checklist, it can be attached to the filtering step as a skill.
Three boundaries to draw before you start
Having an agent hunt for vulnerabilities means giving it permission to run code. The proving stage executes payloads; setting this up without taking that seriously means turning your own machine into the target while trying to audit something else.
- Execution belongs only inside gVisor or a virtual machine with networking disabled. Mantis's own rules require this.
- Mount the repository copy read-only; patches should be written to a separate branch and never merged without human approval.
- Secrets and production credentials should not exist in the environment at all. A key leaked during a scan costs more than the bug you found.
These three boundaries are not a technical preference but the tool's operating assumption. Google's documentation defines where execution may happen at the skill level; loosening that definition removes the tool's security model.
The first pass, step by step
Start with a small repository. The first goal is not to find a vulnerability but to see the pipeline run end to end on your stack.
- Clone the repository and link the skills into your agent framework's command directory.
- Run only the learning stages first, and read the architecture note and threat model yourself.
- If a component is misunderstood in that note, correct it and regenerate; every later stage rests on that text.
- Limit the researcher stage to a narrow directory rather than releasing it across the whole repository.
- Do not skip the filtering stages; the raw finding list arrives almost always unusable.
- Enable the reproduction stage only once the sandbox is ready, and try a single finding on the first run.
Breaking that order costs time. If the learning stage is weak, the researcher looks at irrelevant files, the filtering stages have to drop more false positives, and the token cost climbs quickly.
The real difference: re-attacking the patch
Most agentic security tools stop at generating findings. What sets Mantis apart is treating reproduction and the re-attack on the patch as the trust boundary. A finding counts as a finding only when it can be run and shown in the sandbox.
The same logic applies on the fixing side. After the patch is applied, the pipeline tries the same payload again; if it passes, the patch is rejected. This is a criterion grounded in an observable outcome rather than the model's confidence, and in practice it is the part that saves the most time.
There is a price: findings that cannot be proven fall off the list, and real ones can be among them. In exchange, the list you receive is short and every item on it is demonstrable. Since a review is measured by how many items were acted on rather than how many it produced, that trade sits on the right side for most teams.
The two numbers Google gives
Google describes the problem the tool targets with a single figure: in naive AI code scanning, the true-positive rate is below 7 percent. That is, the vast majority of findings are not worth examining, and the real cost is not the scan but the human hours spent filtering the list.
The second number is on the cost side. According to the company, the hierarchical summary tree cuts the token overhead an agent spends understanding a repository by over 85 percent. That figure decides whether the pipeline stays runnable on large repositories.
Scoring risk and reading the report
The calibration stage at the end of the pipeline assigns each finding a risk score from 1 to 10. The score is not an absolute measure; it exists to rank findings within the same repository and to tell the reader where to start.
- A finding with a high score but no reproduction belongs at the end of the list, not the top.
- Findings the chaining stage combines may look individually low-scoring; assess them together.
- The reflection stage writes its lessons into the next pass, which is why the first report should be kept.
- The report packet is produced for human reading; simplify its headings yourself before pouring it into a ticket system.
A newer skill, the advice stage, inverts the flow. Before code is written, it queries the accumulated threat model, past bug lineages and verified patch patterns. The aim is to stop the same class of bug from landing twice. That is the hardest part of any review tool: not closing what you found, but preventing the same bug from returning in the next release. By defining it as a separate stage, Mantis at least makes it measurable.
What one pass costs
There is no single answer on cost, because the bill depends not on repository size but on how many files the agent has to read. When the learning stage works well, later stages look at a narrow surface and the cost stays predictable.
The practical measurement is this: record the tokens spent on the first pass, then see how far that drops on a second pass over the same repository. The hierarchical summary tree engages from the second run onward, and that is where the real saving appears. Turning the tool into a weekly habit without taking that measurement means seeing the bill afterwards.
A realistic plan for a small team
Turning Mantis into a weekly habit is not yet realistic for small teams. The better fit is a review invoked at specific moments.
- When a new external dependency is added, run it only over the surface that dependency touches.
- When you change an authentication or payment flow, take the full pipeline through once.
- When you close a security bug, check whether the same class recurs elsewhere.
- Run it a few days before a release rather than right before it; the patches produced need to be read by a person.
That last item looks like a detail but is the most important part of this guide. A patch produced by the agent should be treated as a proposal to review, not as something that lands in production code automatically.
Where to stop
Mantis does not take security review out of human hands. What it does is absorb three jobs that eat an auditor's hours: learning the repository, filtering the candidate list, and showing that a vulnerability actually works.
Those three jobs are the repetitive bulk of a review day. The time the agent gives back turns into time the team can spend on the questions that genuinely require a decision.
What remains human is whether the threat model is right, what the risk means for the business, and whether the patch breaks the product. That is also why the tool is not recommended for production: the pipeline's output is not a decision but a file prepared for one.