Google Mantis

• Running a review campaign on an internal service with `./run.sh` and receiving a review packet of reproduced, risk-scored findings
• Steering a pass toward one bug class, such as IDOR or SSRF in webhook handlers, with `--focus` or `--objective`
• Reproducing suspected memory-safety bugs in a networkless gVisor or microVM sandbox before filing them
• Generating patches for confirmed findings and having independent agents try to bypass them
• Giving a coding agent the `/mantis-advise` skill so new code avoids bug classes already found in the repository
• Adapting the skills to audit infrastructure-as-code, RTL designs, or compiled firmware

Mantis is best read as a blueprint for AI vulnerability research rather than a finished scanner. Its design choices are the valuable part: grounding findings in sandboxed reproduction, having independent agents attack each patch, and calibrating severity against a rubric all address the false-positive and severity-inflation problems that make most AI code scanning hard to trust. The cost is that you own everything around it: sandbox isolation, model spend, run-to-run variance, expert triage, and any CI or ticketing integration. Teams with security engineers who want to build an internal pipeline will get the most from it; teams that would rather use a vendor-run product should look at CodeMender, which is in limited preview, or Codex Security.

About Google Mantis

Mantis comes from Google's security engineering team, which describes it as the open-source core of the multi-agent framework Google Cloud uses internally to scan its own code; Google says a fuller version runs internally. It is not a scanner you point at a repository and leave. It ships as a set of slash-command skills that you install into a coding agent such as Gemini CLI, Antigravity CLI, or an ADK app (`npx skills add google/mantis`), plus a reference harness on the Agent Development Kit (`./run.sh path/to/code`) that chains the stages for you. A pass starts by mining version-control history for past security fixes, building a Markdown knowledge base and a threat model, and writing a targeted research plan. You can steer the plan in plain language with `--focus`, or have the harness design a custom agent graph for an objective. Research agents then sweep the code, and deduplication, review, and critic stages drop duplicates, false positives, and issues that cannot occur in a release build. Surviving findings are reproduced in tiers, from a unit micro-harness up to a full sandboxed service, inside networkless gVisor containers or microVMs, or on hardened ephemeral Compute Engine VMs in a private VPC without internet access. Confirmed findings can be chained into multi-step exploits. Patches are written by separate subagents and re-attacked by independent agents with boundary-mutated variants before a fix is marked verified. Every finding gets a 1-10 risk score against a rubric meant to stop the inflated severity ratings LLMs tend to give, and learnings feed the next pass and the `/mantis-advise` skill, which your coding agent can consult while writing new code. Google says a hierarchical summary tree cuts token overhead by more than 85% on large repositories. Models are your choice: Gemini directly or through Vertex AI, Claude and GLM through Vertex AI Model Garden, or any OpenAI-compatible endpoint such as vLLM or Ollama. The tradeoffs are significant. Google labels Mantis "not an officially supported Google product" and says it is for demonstration, not production. It generates and runs code autonomously, so it must run in isolated environments, and Google requires a hardened VM for unattended use. Results are non-deterministic and every finding needs review by a security expert. There is no hosted service, pull-request reviewer, or packaged CI integration, so teams build those around the harness themselves.