Google Mantis: Open-Source AI Vulnerability Harness, Architecture, Setup and Sandbox Requirements

By AiCybr Editorial · Published September 16, 2026

Google released Mantis as an open-source framework for AI-assisted software security review on September 2, 2026. The project automates repository analysis, vulnerability hypothesis generation, triage, reproduction, patch generation and post-fix verification through a set of modular skills plus a reference agent harness.

Google says the design addresses two recurring problems in AI vulnerability scanning: weak repository context and high false-positive rates. Its published implementation builds hierarchical security summaries from source code and repository history; Google reports that this reduced token overhead by more than 85% while preserving structural context. The framework also combines critic/review agents with sandboxed reproduction so findings can be tested before engineers act on them.

Mantis is Apache-2.0 licensed and available in the google/mantis GitHub repository. The current project documentation describes it as a starting point for security teams and coding-agent workflows, with explicit requirements for isolation, human verification and controlled execution of AI-generated code.

Mantis at a glance

Why Google built Mantis

AI coding models can inspect large repositories quickly. Vulnerability scanning becomes costly when the model lacks architecture context or floods a team with low-confidence findings.

Google's September 2 launch post says poorly designed AI scanning workflows can deliver true-positive rates below 7%. Mantis adds multiple filtering and verification stages before a model-generated security claim becomes actionable security evidence.

The framework first gathers repository context, then creates higher-level representations that agents can reuse throughout the review. Google says Mantis examines commit history to learn from previous security fixes and can construct architecture and threat-model documentation when teams have not already supplied it.

The system then uses specialized stages to research hypotheses, deduplicate overlapping findings, critique results, attempt reproduction, generate patches and verify whether fixes hold under further testing.

Architecture: a pipeline of specialized security skills

Mantis separates the review workflow into specialized skills. The repository currently exposes modules for architecture analysis, threat modeling, planning, research, criticism, deduplication, reproduction, patching, reporting and post-run reflection.

A typical deep-review flow can be understood as five broad phases:

1. Build repository context. Mantis reviews source structure and history, generates summaries and develops architecture and threat-model context.
2. Plan security research. Planning and research agents generate hypotheses and direct deeper analysis toward relevant code paths.
3. Filter findings. Critic, review, deduplication and calibration stages reduce duplicate or low-confidence findings and assign a more useful severity signal.
4. Reproduce and patch. The harness can attempt to reproduce a candidate vulnerability, create a patch and test the modified code.
5. Retain security knowledge. Reflection and advisory stages preserve useful security context so later coding work can consult prior findings, fixes and threat models.

This decomposition matters for engineering teams because each stage can be changed independently. A team can keep its preferred coding model, swap the orchestration layer, add organization-specific threat models or replace the supplied sandbox with a stronger internal isolation boundary.

Hierarchical repository summaries reduce context cost

Large security reviews can exceed a model's practical context budget long before every file has been analyzed in detail. Mantis addresses that problem with a hierarchical security-summary tree.

Individual files are summarized into higher-level directory representations and eventually repository-level context. Google reports that this design reduced token overhead by over 85% in its work while retaining important structural information.

The benefit is operational as well as financial. Security agents can consult the summarized architecture before deciding which source paths deserve expensive deep analysis, while lower-value areas can be handled with shorter contextual representations.

The published 85% figure is a Google-reported result from the Mantis design, so teams should measure token use and finding quality against their own repositories before using it for capacity or cost planning.

How Mantis validates findings

Mantis uses several mechanisms to improve the quality of AI-generated security findings:

• Critic and review agents challenge candidate issues before they progress.
• Deduplication reduces multiple reports that describe the same underlying weakness.
• Calibration maps findings to an established severity rubric for more consistent prioritization.
• Reproduction workflows can move a finding from static reasoning toward a unit test, mock server or executable reproducer when the target environment allows it.
• Patch verification can re-run the relevant security workflow after a fix and use adversarial testing to check whether the same vulnerability class still survives.

The repository documentation explicitly requires human review of findings before disclosure. Successful reproduction establishes stronger evidence than a model assertion, while final exploitability and business impact still depend on the real deployment context.

Installation and first run

The reference setup expects a Python environment. Google's README gives the following basic path:

git clone https://github.com/google/mantis.git
cd mantis/reference
./install.sh

The project then provides automated configuration and launch tooling. For Vertex AI, Google documents Application Default Credentials as the authentication path:

gcloud auth application-default login
python3 scripts/configure.py --auto
python3 scripts/configure.py --test --probe

A repository or source directory can then be reviewed with:

./run.sh path/to/code

Mantis also accepts a targeted research objective. For example:

./run.sh path/to/code --objective "Audit for Server-Side Request Forgery and SSRF in webhook handlers"

The objective path is useful when an organization already knows the attack surface it wants to examine and wants the research graph concentrated around a specific vulnerability class or subsystem.

Sandboxing is part of the deployment design

Mantis can generate and execute code while attempting to reproduce vulnerabilities. Google therefore requires risky runs to operate inside isolated environments with explicit security boundaries.

The project README advises against running the suite on hosts that can reach production systems, sensitive data or internal networks. Its reference material includes sandbox options, while the detailed agent guide recommends stronger containment for unattended or frontier-model workflows.

For a production security team, the minimum practical architecture should separate the orchestrator, target repository, reproduction environment, credentials and network access. A hardened implementation can add ephemeral workers, network-deny defaults, scoped service accounts, disposable filesystems and independent logging outside the agent's control plane.

This isolation is particularly important during exploit reproduction. A valid test may intentionally create crashes, malformed requests, hostile files or code-execution paths that should remain contained even when the agent behaves exactly as designed.

Human context still improves the scan

Google recommends combining organization-specific context with Mantis's automatically generated repository summaries.

Examples include:

• security boundaries and trust assumptions;
• bug classes that matter for the deployed product;
• intentionally unsupported configurations;
• authentication and authorization architecture;
• build and test commands;
• historical vulnerability patterns;
• acceptance criteria for confirming a finding;
• internal coding and disclosure standards.

That context helps the research agents spend more effort on findings that can affect the real deployment and less on technically valid but operationally irrelevant behavior.

The role of mantis-advise

Mantis also includes a security-advisor skill intended for use during future development. The repository describes /mantis-advise as a way to query accumulated threat models, historical vulnerability lineages, verified patch patterns, false-positive decisions and other learned security context before or during code changes.

This creates a second use case beyond periodic security scans. A team can preserve knowledge from earlier investigations and make that context available to a coding agent while new features are being implemented.

The practical goal is to move some security review earlier in the software lifecycle. Prior mistakes, dangerous data flows and established remediation patterns can become reusable input to code generation and refactoring.

Where Mantis fits in a security toolchain

Mantis is best evaluated as an agentic security-review orchestration framework. It can complement deterministic tools such as SAST, SCA, secret scanning, fuzzing and conventional test suites by giving coding agents more repository context and a workflow for investigating and validating suspected vulnerabilities.

A mature deployment can use deterministic scanners as signal generators, pass selected findings into Mantis for contextual analysis and reproduction, and then require normal human review plus existing CI/security gates before accepting a patch.

This model also avoids using one AI-generated score as the sole release decision. Existing security controls remain useful because they provide repeatable checks while Mantis handles tasks that benefit from broader reasoning, repository history and generated experiments.

Deployment checklist

Before running Mantis on an internal codebase, verify the following:

1. Clone and pin the framework version used for the review so results are reproducible.
2. Run the target in an isolated environment with no unnecessary production, internal-network or sensitive-data access.
3. Use scoped credentials for the selected model provider and source-control access.
4. Define vulnerability acceptance criteria for each important bug class.
5. Provide architecture and trust-boundary context where the automatic summaries are insufficient.
6. Connect existing build and test commands so generated patches can be validated using the project's normal tooling.
7. Record reproducer artifacts and evidence alongside the finding.
8. Require security-engineer review before disclosure, ticket escalation or patch approval.
9. Treat generated patches like normal code changes and run standard code review, CI, regression and security checks.
10. Measure precision, token use and remediation time on your own repositories before scaling unattended scans.

Limits that matter

Google states that Mantis is a demonstration framework and is not an officially supported Google product. The repository also states that AI models can hallucinate findings or generate incorrect patches, and it requires manual verification before findings are reported.

Reproduction depth depends on the vulnerability and available test environment. Some findings can be exercised in a unit test or isolated service; others depend on infrastructure, hardware, race conditions or production-only state that a test harness may not fully reproduce. Mantis supports multiple reproduction depths to accommodate those different conditions.

Teams should also treat model and sandbox selection as part of the security architecture. A more capable agent can perform deeper analysis and generate more realistic reproducers, which raises the importance of isolation, logging and least-privilege credentials.

Bottom line

Mantis gives security teams an open-source blueprint for moving AI vulnerability research from one-shot code inspection toward a structured pipeline: build repository context, generate hypotheses, challenge findings, reproduce them where possible, create patches and verify the result.

Its most consequential design choices are the hierarchical context system, the separation of security work into specialized skills, and the requirement to ground high-risk testing in isolated environments. Google's reported 85%+ reduction in token overhead and its critic/reproduction workflow make Mantis worth testing for teams already experimenting with coding agents, provided the evaluation includes precision, sandbox safety and integration with existing security gates.

Sources

• Google Cloud, Getting started with Mantis, our open-source bug finding-and-fixing harness, September 2, 2026: https://cloud.google.com/blog/products/identity-security/getting-started-with-the-mantis-harness-to-find-and-fix-bugs
• Google Mantis repository and README: https://github.com/google/mantis
• Mantis agent reference guide: https://github.com/google/mantis/blob/main/README_AGENTS.md
• Apache 2.0 license in the Mantis repository: https://github.com/google/mantis/blob/main/LICENSE