The promise of Artificial Intelligence in Application Security (AppSec) has, until recently, been overshadowed by a persistent and frustrating reality: the hallucination. For years, security engineers have been caught between the “velocity crisis” of modern development and the noise generated by automated tools. While Large Language Models (LLMs) showed early promise in identifying code smells, their initial integration into security workflows often exacerbated the problem rather than solving it.

Traditional AI-powered scanners and basic LLM wrappers frequently suffer from a true-positive rate of less than 7%. For a Security Operations Center (SOC) or a dedicated AppSec team, this means that for every 100 alerts generated by an AI “security assistant,” 93 are noise. This creates a massive “alert fatigue” problem, where genuine, critical vulnerabilities are buried under a mountain of false positives. The industry has reached a point where Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools, while useful for catching low-hanging fruit, are fundamentally ill-equipped to handle complex logic flaws or multi-step exploit chains that require deep contextual reasoning.

The False Positive Crisis in Modern AppSec

The fundamental limitation of traditional scanners lies in their lack of semantic understanding. A SAST tool might flag a memcpy call as potentially dangerous because it matches a known pattern, but it cannot determine if the surrounding logic effectively bounds the input. Conversely, early attempts to use LLMs for security scanning often resulted in the model “imagining” vulnerabilities that didn’t exist, simply because the code looked like a pattern it had seen in its training data.

This is more than just a minor inconvenience. In a high-velocity environment where code is deployed dozens of times a day, a security tool that provides unreliable data becomes a bottleneck. Developers begin to ignore security reports, and the gap between “code complete” and “securely deployed” widens. This is the core of the velocity crisis in modern code review, where the speed of feature delivery outpaces the ability of human or automated reviewers to verify safety.

To move beyond this, we need a system that doesn’t just predict the next token in a security report, but one that reasons about the code, validates its own assumptions, and provides empirical proof of its findings. This is the gap that Google Mantis aims to bridge.

Introducing Google Mantis: An Agentic Leap Forward

Google Mantis represents a fundamental shift in how we approach automated vulnerability management. It is not a single model or a simple wrapper around an API; it is an open-source framework for agentic vulnerability scanning. Mantis is a core component of Google’s broader “machine-speed” security strategy, designed to match the pace of modern software evolution with autonomous defensive capabilities.

The “agentic” distinction is critical. While a traditional AI scanner is passive—taking code as input and spitting out a list of potential issues—Mantis is active. It utilizes a multi-agent architecture where specialized AI entities collaborate to explore, test, and verify vulnerabilities. Instead of a monolithic model trying to do everything, Mantis breaks the security lifecycle into discrete tasks handled by specialized agents.

This modularity allows Mantis to transition from simple pattern recognition to complex reasoning. It doesn’t just say, “This looks like a SQL injection”; it asks, “Can I reach this database query with untrusted input? If so, what payload would trigger it? Let me try to run that payload in a sandbox to see if it actually works.”

Feature Traditional SAST/DAST Basic LLM Wrappers Google Mantis (Agentic)
Reasoning Pattern-based Probabilistic/Predictive Goal-oriented/Reasoning
False Positive Rate High Very High (Hallucinations) Low (Verified Findings)
Context Awareness Shallow Limited by Context Window Deep (Hierarchical)
Verification Manual Manual Automated (Sandboxed)
Discovery Known Signatures General Patterns Complex Logic Flaws

The Multi-Agent Orchestration: Critics, Reviewers, and Specialists

At the heart of Mantis is a sophisticated orchestration layer that manages a “skill suite” of specialized agents. This architecture is built on the principle that security research is a collaborative process. In a human-led security audit, you might have a lead researcher, a specialist in a specific framework, and a peer reviewer who double-checks the findings. Mantis replicates this dynamic through its multi-agent system.

Shared State and Collaboration

The agents in Mantis communicate via a shared state. This is a central repository of knowledge about the target application that evolves as the scan progresses. When a “Discovery Agent” finds a potential entry point, it updates the shared state. A “Specialist Agent” might then pick up that information to perform a deeper analysis of the specific library being used.

The Role of the Critic

One of the most innovative aspects of the Mantis framework is the inclusion of Critic Agents. The Critic’s sole job is to challenge the findings of other agents. When a “Scanner Agent” proposes that a specific line of code is vulnerable, the Critic attempts to find reasons why it isn’t. It looks for sanitization routines, framework-level protections, or architectural constraints that the first agent might have missed. This adversarial internal logic is the primary defense against LLM hallucinations.

Model Orchestration: Gemini Flash and Gemini Pro

Mantis leverages different models for different tasks to balance speed and depth:

  • Gemini Flash: Used for high-volume, initial triage tasks where speed is essential. It can quickly scan thousands of files to identify areas of interest.
  • Gemini Pro: Reserved for deep reasoning, exploit chain construction, and complex logic analysis where the higher parameter count and reasoning capabilities are required.

By orchestrating between these models, Mantis avoids the “one-size-fits-all” trap, ensuring that expensive compute resources are only used when deep reasoning is actually necessary.

Solving the Context Problem: Hierarchical Tree Summarization

One of the biggest hurdles in applying AI to large-scale software projects is the “context window” limitation. Even with the massive context windows offered by modern models, a production-grade codebase—with its millions of lines of code, dependencies, and configuration files—is often too large to be processed in a single pass.

Mantis solves this through a technique called Hierarchical Tree Summarization. Instead of feeding the entire codebase into the model, Mantis builds a semantic map of the application.

  1. Bottom-Up Summarization: Mantis starts at the function and module level, creating concise summaries of what each component does, its inputs, and its outputs.
  2. Tree Construction: These summaries are then aggregated into higher-level summaries of packages and services.
  3. Context Engineering: When an agent is investigating a specific potential vulnerability, Mantis provides it with a “pruned” version of the tree. The agent gets the full code for the immediate area of interest, but only the high-level semantic summaries for the rest of the application.

This approach is a masterclass in context engineering for root cause analysis. By focusing the model’s “attention” on what matters while maintaining a high-level understanding of the system’s architecture, Mantis reduces token usage by approximately 85%. This doesn’t just lower costs; it significantly improves accuracy by removing the “noise” that often leads models astray in large contexts.

Grounding Findings: The Power of Sandboxed Reproduction

The “holy grail” of automated security is the ability to not just find a bug, but to prove it. This is where Mantis separates itself from almost every other AI-driven tool on the market. It employs a “trust but verify” mechanism through sandboxed reproduction.

When the agentic loop identifies a high-confidence vulnerability, it doesn’t just stop and file a ticket. Instead, it enters a reproduction phase:

  1. Exploit Generation: The agent attempts to write a Proof-of-Concept (PoC) script (e.g., a Python script or a curl command) that would trigger the vulnerability.
  2. Sandboxed Execution: Mantis spins up a secure, isolated containerized environment that mirrors the target application’s runtime.
  3. Validation: The PoC is executed against the sandbox. Mantis monitors the logs, memory state, and network traffic to see if the exploit was successful.

“The difference between a hallucination and a finding is empirical evidence. If the agent can provide a working PoC that triggers a crash or an unauthorized data leak in a sandbox, the finding is no longer a ‘potential issue’—it is a verified fact.”

Case Study: CVE-2026-66066

A prime example of this in action is the handling of complex vulnerabilities like CVE-2026-66066 in Ruby on Rails Active Storage. This vulnerability involved a sophisticated interaction between file uploads and data processing logic. A standard scanner might miss the subtle logic flaw, and a basic LLM might flag it but fail to explain why. Mantis, however, was able to reason through the file-handling logic, generate a specific malformed upload, and confirm the vulnerability by observing the unauthorized file access within its sandbox.

This grounding in reality is what allows Mantis to achieve its “machine-speed” goals. Because the findings are verified, they can be acted upon immediately without requiring hours of manual reproduction by a human security engineer. This is particularly vital for identifying complex logic flaws like those found in Chrome Passkeys, where the vulnerability exists in the interaction between components rather than a single line of code.

Implementation: Integrating Mantis into the CI/CD Pipeline

For organizations looking to adopt Mantis, the power lies in its integration. It is designed to be a “silent partner” in the development lifecycle, operating within the CI/CD pipeline.

Workflow Integration

Mantis can be triggered as part of a GitHub Action or GitLab CI pipeline. Upon a Pull Request (PR), Mantis begins its autonomous scan. Because it uses hierarchical summarization, it can focus specifically on the diff and the parts of the application that the diff interacts with, making it efficient enough for per-commit analysis.

Policy-as-Code and Governance

To prevent the agents from going “rogue” or performing overly aggressive testing, Mantis uses a policy-as-code layer. Organizations can define the boundaries of the autonomous scan using structured formats. For teams already familiar with Terraform and HCL-based governance, this approach feels natural. You can define which environments are “safe” for reproduction, what types of data the agents can interact with, and at what threshold a finding requires immediate human intervention.

# Example Mantis Agent Policy
agents:
  discovery:
    depth: 3
    focus: ["api_endpoints", "auth_modules"]
  reproduction:
    enabled: true
    sandbox_image: "us-docker.pkg.dev/security-images/rails-safe:latest"
    max_attempts: 5
policies:
  - name: "no-data-exfiltration"
    rule: "deny"
    condition: "payload.contains_pii()"

Human-in-the-Loop

While Mantis is autonomous, it is not meant to replace security engineers. Instead, it elevates them. Rather than spending their time triaging 500 false positives, engineers spend their time reviewing 5 verified PoCs and architecting long-term fixes. Mantis provides the “empirical proof,” and the human provides the “architectural context.”

The Future: Autonomous Patching and Machine-Speed Defense

The trajectory of Google Mantis points toward a future where the entire vulnerability lifecycle—from discovery to remediation—is handled at machine speed.

The next logical step for the framework is autonomous patching. Once an agent has generated a PoC and verified a vulnerability in a sandbox, it can then attempt to generate a fix. This fix is then tested in the same sandbox: if the PoC no longer works but the application’s functional tests still pass, the agent has successfully remediated the bug.

This shift will be the ultimate solution to the velocity crisis. As software grows more complex and the attack surface expands, the only way to maintain a secure posture is to have defensive systems that can reason and act as quickly as the code is written. Mantis isn’t just a tool for finding bugs; it’s a blueprint for a new era of autonomous security research, where the “hallucination” is replaced by a cycle of constant, empirical verification.

The transition from passive scanning to agentic reasoning is not just an incremental improvement—it is the foundation of a proactive, machine-speed defense that can finally stay ahead of the curve.