google/mantis: A Skill Pipeline for Agent-Driven Security Review
A modular, stack-agnostic toolkit of security review skills for AI coding agents to autonomously find, reproduce, and patch vulnerabilities.
At a glance
- What is it?
- Mantis is a set of slash-command skills that walk a coding agent through planning, reproducing and patching vulnerabilities. The README is candid about the risks: non-deterministic models, hallucinated findings, and a hard requirement for isolated execution.
- Who is it for?
- Mantis suits teams that already run a coding agent in a disposable VM and want a structured, human-approved path from threat model to patch. It is the wrong tool for anyone hoping to point an agent at a production checkout and walk away, and the README itself warns against mass-filing unverified reports.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Mantis Is Actually For
Mantis addresses a narrow gap: a coding agent can read code, but it has no built-in procedure for deciding what to look at, proving a bug exists, and producing a patch. Mantis supplies that procedure as a set of skills, which the README describes as decoupled, sequential and security-focused. The intended user is a security engineer or a developer doing defensive review who already has an agent CLI running and wants the agent to follow a repeatable path instead of freeform prompting. The repository frames the skills as a starting point rather than a fixed specification, and explicitly says you should adapt and extend them for your own stack. That framing matters. This is not a scanner you install and run against a repository. It is a template for a review harness, and the quality of the output depends heavily on how much internal context (threat models, coding standards, build systems) you feed into it.
The Sequential Skill Pipeline and Its Inter-Stage Contracts
The mechanism is a chain of slash commands invoked from inside an interactive agent session. The README names three: /mantis-plan, /mantis-reproduce and /mantis-patch. A fourth, /mantis-review, is described as applying negative rules to filter false positives. The README points to a separate Agent Reference Guide for the detailed breakdown of pipeline stages, sequential flow and inter-stage contracts, so the exact handoff format between stages is not visible in the main document. What is visible is the division of labour. Planning produces the target. Reproduction attempts to demonstrate the issue by executing code. Patching writes a fix. Review filters. The README states that the reproduce and patch skills are explicitly instructed to execute payloads inside isolated container environments with networking disabled, using flags such as --network none. That instruction is a prompt-level constraint, not a kernel-level one, and the README says so: agents may attempt unsafe actions or bypass intended constraints if the local environment allows it.
Installation and the Commands You Actually Type
Installation is a single command, run after cloning the repository: npx skills add google/mantis. The README notes you can install globally or locally to a specific workspace, and that you can also just ask your coding agent to help. The README does not recommend a specific agent platform. It states the skills have been used with Gemini CLI and Antigravity CLI, and with the Google ADK and Antigravity SDK, and that any coding agent framework should work. For sandboxing, the README suggests Docker and, for stronger isolation, gVisor. Two registration paths are given for runsc. The first is a shell command: sudo runsc install -- --network=none && sudo systemctl restart docker. The second is a Docker daemon configuration entry in /etc/docker/daemon.json, adding a runtimes.runsc block with path runsc and runtimeArgs set to --network=none. Either way, the goal is the same: make networkless execution the default for the container the agent uses to run generated reproducers.
Interactive Mode Is the Intended Starting Point
The README's beginner guidance is unusually direct about not automating the first runs. It tells you to launch your agent in your normal workflow and type the slash commands individually, and it warns against --yolo, --dangerously-skip-permissions, or any automatic approval of actions. The expectation is that the agent pauses for human approval before sensitive steps, particularly when /mantis-reproduce or /mantis-patch attempt to write files or run code. This is a deliberate design position: the human inspects what the agent intends to execute before it executes. Running unattended is possible, but the README makes it conditional on implementing strong boundaries and points to a later section on unattended cloud deployment with mandatory hardening requirements. The advice to start with narrow-scope scans rather than a repository-wide sweep on day one follows the same logic. Tuning the negative filters in /mantis-review against a small surface is cheaper than discovering the filter set is wrong across an entire monorepo.
Where the Design Pushes Risk Back Onto You
The caution block at the top of the README is the most important part of the document. It states the suite is designed to generate and execute autonomously generated code that may be unstable or perform unexpected actions, and that it should be used only in isolated, restricted environments, never on a machine with access to production systems, sensitive data or internal networks. The responsible-use note adds that AI models are non-deterministic and can hallucinate findings or generate incorrect patches, that all findings must be manually verified by a security expert before being reported, and that a failure to reproduce does not definitively mean a false positive, nor does a successful reproducer guarantee exploitability in every context. Those are not hedges bolted on for legal cover. They describe the failure modes you will hit. The negative-filter rule in /mantis-review exists precisely because AI scanning produces false positives, and the README tells you to customise those filters for your codebase. If you skip that tuning step, the review stage is filtering with someone else's assumptions.
How Mantis Differs From a Conventional SAST Tool
A conventional static analysis tool such as Semgrep or CodeQL parses source into a queryable representation and matches rules against it. The result is deterministic: the same code and the same ruleset produce the same findings, and a rule author can reason about exactly what will and will not match. Mantis takes the opposite approach. It has no rule engine visible in the material. Detection is delegated to a language model reading the code under a planning skill, and the pipeline's value comes from what happens after detection: attempting to reproduce the issue by executing code, then generating a patch. That is a capability a rule-based scanner does not have, and it is also why Mantis needs a sandbox and a human approver while a SAST tool needs neither. The trade is determinism and auditability for reach. A Semgrep rule will not hallucinate a finding. An agent running /mantis-plan might, which is why the README routes everything through manual verification before reporting.
Maintenance, Licensing and the Cost of Keeping Up
The repository is licensed Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, though the usual caveat applies: this is a description of the licence text, not legal advice, and organisations with strict open source policies should route it through their own review. On maintenance, the honest answer from the supplied material is that there are no retrieved releases. The default branch is main and the last push is dated 2026-09-03, so development is active, but there is no tagged version to pin to and no changelog to read. That shifts upgrade cost onto you. Because the skills are prompt artefacts rather than a library with a stable API, updating them means re-reading the skill files and re-checking that your local customisations (negative filters, threat model additions, stack-specific adaptations) still apply. The README's recommendation to use AI to iterate on the skills implies exactly this kind of ongoing editing. Budget for it as prompt maintenance, not dependency bumps.
Who Should Adopt It and What to Check First
The fit is a security team with an existing agent workflow, a disposable VM or gVisor-backed container setup, and the discipline to keep a human in the loop for reproduce and patch steps. The misfit is anyone without that isolation, anyone who wants deterministic repeatable findings for compliance evidence, and anyone tempted to let the pipeline file reports to upstream maintainers without expert review. The README's own warning against mass-filing unverified AI-generated reports should be read as a boundary, not a suggestion. The adaptability section notes the skills can be extended to hardware and RTL, infrastructure as code, ML pipelines and compiled firmware, but that extension work is yours to do. Practically, the first thing to verify after npx skills add google/mantis is whether your agent framework resolves the slash commands at all, and the second is whether /mantis-reproduce genuinely runs under --network none in your configuration rather than assuming the prompt instruction holds.
Editorial conclusion
Mantis suits teams that already run a coding agent in a disposable VM and want a structured, human-approved path from threat model to patch. It is the wrong tool for anyone hoping to point an agent at a production checkout and walk away, and the README itself warns against mass-filing unverified reports. Before adopting it, verify three things: that your agent framework can load skills installed with npx skills add google/mantis, that /mantis-reproduce actually executes payloads under --network none in your setup, and that your /mantis-review negative filters have been tuned against your own codebase rather than left at defaults.
Community notes