google/mantis

Selection

Select when

• You need a staged defensive review workflow rather than one-pass vulnerability generation.
• You can run generated code only inside a dedicated isolated VM, container, microVM, or hardened cloud sandbox.
• Security experts will manually verify findings, exploitability, and patches.
• You want to adapt review skills to organization-specific architecture, standards, build systems, and risk tolerance.
• You need both static analysis and sandboxed reproduction or patch re-attack workflows.
• You want snapshot provenance and conservative handling of code drift across repeated passes.
• You need a reference multi-agent harness built on Google ADK.
• You need support for source, binary, firmware, hardware, or infrastructure targets.
• You want accumulated threat models and prior remediation evidence available during development.
• You accept substantial setup and operational governance for safer execution.

Boundaries

Avoid when

• You need an officially supported or production-certified Google security product.
• You require a documented native Claude Code plugin or guaranteed Claude Code compatibility.
• You cannot isolate generated payload execution from production systems, secrets, and internal networks.
• You need deterministic findings with low false-positive rates and no expert review.
• You intend to mass-file automatically generated vulnerability reports.
• You need a turnkey setup with no Docker, virtualization, cloud, model, or sandbox configuration.
• You require native Windows execution of the supplied reference harness outside WSL2.
• You cannot permit an agent to read proprietary source or send context to configured model providers.
• You require an independent security audit or validated sandbox-escape analysis.
• You need automatically applied production patches rather than reviewed patch artifacts.

Strengths

Capabilities

Risk profile

Risks and limitations

• Uncertainty: only selected first-party files were supplied, so the full skill inventory, schema, reference-harness implementation, tests, dependency lock contents, sandbox code, meta-agent, and security controls were not directly inspected.
• Uncertainty: repository metadata is dated in 2026 relative to this analysis context, so activity, adoption, issue counts, and maturity cannot be independently reconciled.
• Uncertainty: Claude Code is not named in the supplied first-party files, so native compatibility, skill discovery, slash-command behavior, and installation location are unverified.
• The repository explicitly says it is a demonstration, not intended for production, and not an officially supported Google product.
• AI findings, reproducers, exploitability conclusions, and patches are non-deterministic and require manual security-expert verification.
• Generated code may be unstable or dangerous, and skill instructions cannot guarantee that an agent will honor sandbox boundaries.
• Dynamic reproduction and patch testing can require Docker or Podman, gVisor, KVM-based MicroSandbox, or a hardened GCP environment.
• The supplied reference installer rejects native Windows, while macOS lacks the documented KVM microVM path.
• Unattended operation creates prompt-injection and high-impact execution risks even with documented hardening.
• Static-only mode skips dynamic exploit execution and patch testing, limiting confidence in findings and fixes.
• The reference setup depends on external models, Google ADK, cloud credentials or services depending on configuration, and stack-specific build tools.
• No independent security audit, measured detection benchmark, false-positive benchmark, sandbox-escape assessment, privacy policy, telemetry statement, or Claude compatibility matrix was supplied.

The repository repeatedly requires isolated, restricted environments and warns against production systems, sensitive data, and internal networks. Reproducer and patch stages direct execution into networkless gVisor containers, MicroSandbox microVMs, or hardened ephemeral GCE VMs; a static-only backend avoids dynamic execution. Pinned snapshots are treated as read-only, patch work occurs in private shadows, and VERIFIED_SECURE requires an unpatched trigger, patched compile, benign sink-reaching control, attack failure, and at least three unsuccessful re-attack variants. These are documented controls rather than independently verified guarantees, and the authors explicitly warn that agents may bypass intended isolation.