Mantis: AI agents that detect and fix code vulnerabilities

Artificial intelligence quickly moved into developers' tools. Code generation, documentation, testing, refactoring or searching a database: there are already many uses. With Mantis, Google pushes this logic in another direction by using several specialized AI agents to participate in the search for vulnerabilities, their verification and the preparation of patches.

Published in open source, Mantis is presented as a framework designed to automate several steps in the security analysis of a repository: discovery, sorting, reproduction and correction of vulnerabilities. Therefore, the approach is not only to ask a model to read some files and report what it believes is suspicious. It seeks to build a real process around AI.

This development is particularly interesting for teams that develop SaaS, web applications and business software. It shows how the AI could gradually participate not only in the creation of the code, but also in its control and maintenance.

1. What is Mantis?

Mantis is an open source set of tools designed to work with development agents who can work directly on a code basis. Google summarizes its goal around four main steps: discover, sort, reproduce and correct software vulnerabilities.

The project is part of a broader approach used by Google Cloud to integrate specialized agents at different stages of the software development cycle. Google indicates that it has in-house a more complete version of the system, while the published elements make it possible to experiment with the main concepts.

The goal is not simply to create a new security scanner. Rather, the idea is to orchestrate several agents capable of distributing the work and transmitting their findings to the next steps. An officer can explore the repository, another can search for potentially dangerous behaviour, a third can question the result, and another can try to replicate the problem. Finally, a correction proposal may be generated and submitted for validation.

This organization brings Mantis closer to an automated security review process than a simple conversational assistant. The value comes not only from the model used, but from how tasks, controls and evidence are chained.

2. Why a simple LLM is not enough to analyze the security of a project

Modern language models understand the code relatively well. They can explain a function, identify obvious errors or propose improvements. But this capacity has an important limit: a model can produce a very convincing answer while being wrong.

In a classic use, an error can be embarrassing. In a security analysis, it can become problematic. A model can announce that a vulnerability exists while the problem is already neutralised elsewhere in the application. On the contrary, it can miss an important control located in another file. It may also propose a correction which seems logical in isolation but does not respect the overall operation of the application.

Google explains that some too simple approaches to code scan by AI can result in real positive rates below 7%. This is precisely one of the problems Mantis seeks to address. A large number of alerts do not necessarily mean better security: a team can quickly waste time checking dozens of results that ultimately pose no real risk.

So the important question is not only "can IIA find something suspicious?", but rather "can I explain why this problem is important and bring enough elements to verify it?" In safety, a useful alert must be contextualized, reproducible and understandable.

3. Several AI agents rather than one

Mantis is based in particular on a multi-agent approach. Instead of entrusting all the analysis to a single model with a very general instruction, several specialized tasks are chained. In the architecture described by Google, a strategy agent can begin by examining the overall structure of the project, dependencies and potentially sensitive areas.

Research agents then explore the source code more accurately. Other steps are used to consolidate discoveries, eliminate duplicates, verify results and filter out uncredible problems. This separation has an important interest: an agent who is simultaneously asked to understand several thousand files, to search for vulnerabilities, to check his own conclusions and to propose corrections must solve too many problems at once.

A specialized architecture allows you to cut the work. It also allows some officers to challenge the findings of others. This principle is common in human software development: one person writes code, another reads it and tests then check his behavior. Mantis applies a logic comparable to AI agents.

4. Understanding the context of a code repository

A vulnerability almost never exists only because a line of code seems strange. The context is very important. A function may seem vulnerable when it is analyzed alone while a check is performed earlier in the application. Conversely, several perfectly legitimate components taken separately can become dangerous when combined.

For this reason, Mantis seeks to build a more general representation of the project. Google states that the framework analyses the repository history in order to learn from previous security fixes and gradually build documentation on the architecture and threat model.

To limit the amount of information sent simultaneously to models, Mantis also uses a hierarchical organization of context. Files can be summarized at the level of their folders, then this information is condensed themselves to obtain a global view of the repository. Google claims that this technique has reduced the amount of context needed by more than 85% while retaining useful structural information.

This idea goes beyond cybersecurity. In many projects using AI, the problem is not simply to send more information to the model. Above all, it must be given the right context at the right time. Clear documentation, understandable history and legible architecture become useful to developers and agents alike.

5. Reproducing vulnerabilities in an isolated environment

A vulnerability detected by the AI is not automatically considered true. The framework provides steps to try to reproduce behaviour in an isolated environment. The aim is to move from a hypothesis — "this code seems vulnerable" — to a much more usable result: "we managed to reproduce the behaviour under these conditions".

Google precisely presents sandboxed environments as one of the ways to improve the quality of results and limit false positives. To verify certain vulnerabilities, the agent may be required to generate and execute code. This operation should not of course be carried out directly on an environment containing real data or giving access to production services.

Mantis' official documentation is particularly clear on this point. Google recommends isolated and restricted environments, and explicitly advises against launching this type of code on a machine with access to production systems, sensitive data or internal network.

This step illustrates an important rule of professional use of AI: the more autonomous an agent becomes, the more its enforcement environment needs to be monitored. Automation does not remove security rules. On the contrary, it makes their application even more important.

6. From detection to corrective proposal

Identifying vulnerability is only the beginning of work. In a real application, you must then determine why it exists, measure its consequences and prepare a correction that does not break other features. Mantis is planning a stage dedicated to the preparation of patches.

The documentation describes an agent able to apply a minimum change and then verify in the sandbox that the previously reproduced problem is no longer present. This is an important evolution from traditional security scanners. A report indicating "risk of injection detected in this file" remains useful, but an analysis that presents the problem, explains why it seems real, shows how it was reproduced and proposes a modification brings much more context to the developer.

Therefore, the AI starts to intervene not only in detection but also in remediation. However, this does not mean that the change must be automatically applied in production. The correction can affect a business rule, change performance, introduce incompatibility or move risk to another part of the system.

7. Why Human Validation Is Needed

Mantis' documentation explicitly emphasizes this issue. The d的IA models are non-deterministic. They can hallucinate a vulnerability, misinterpret the operation of an application, or generate an erroneous fix.

For this reason, Google recommends that new users start with an interactive mode. When a sensitive action is to be performed — such as writing to files or executing a reproduction code — the agent must be able to stop and request human validation.

As a result, the AIA becomes a tool to assist decision-making. It can dramatically speed up some analyses, but it must not become an automatic source of confidence.

8. What it changes for a SaaS or business software

For a company that develops an application, Mantis' main interest is not necessarily to install the framework immediately. The most interesting is probably to look at the direction taken by the development tools.

Let's take a SaaS held for several years. New features are added, developers intervene successively, dependencies evolve and parts of the code gradually become more difficult to understand. In this context, agents able to analyze the history of the project, rebuild part of its architecture and continually search for certain suspicious behaviors can provide important assistance.

They could intervene in a code review, major change, dependency update or predeployment control. They can also help prioritise areas that deserve further human inspection, document the path of execution and reconcile a report with an earlier correction.

But this evolution does not change a fundamental rule: an AI cannot compensate a poorly designed architecture. An application without clear separation of permissions, without sufficient testing or without control of its dependencies will remain difficult to secure, regardless of the number of agents used.

9. Can I replace a security audit?

No, at least Mantis must not be presented like this. The security of a software product is not limited to searching for certain forms of vulnerable code. Comprehensive analysis may require understanding architecture, roles and permissions, manipulated data, business rules, infrastructure, dependencies and actual conditions of use.

Some vulnerabilities exist only because of incorrect business logic. The code can be technically perfectly valid while allowing an action that should never be allowed. An automated tool may have much more difficulty in recognizing this type of problem if it does not know the precise rules of application.

Google recommends that analysis be enriched with human information: documentation, internal requirements and project-specific knowledge. As a result, AI can become an additional, high-performance tool, but it remains one layer among others in a security strategy.

10. Good practices

Even without using Mantis directly, several lessons can already be applied to a professional project. A human team like an AI better understands a system when the responsibilities of its components are clearly defined. Sustained documentation also prevents important decisions from disappearing over time.

• Keep a useful history: Mantis builds on previous corrections; readable and explained changes therefore facilitate future analysis.
• Test each correction: Unit tests, integration and non-regression remain essential to ensure that a patch does not introduce a new problem.
• Isolate any generated code: automatic execution must never have the same access as the production application.
• Limit permissions: network, files, secrets, duration, memory and processor must be reduced to the strictly necessary.
• Start small: the documentation recommends limited analysis to adjust the filters before scanning an entire repository.
• Require verifiable elements: an alert should not be considered true only because it is formulated with confidence.

A properly organized Git history has a value that goes beyond the simple possibility of going back. It documents intentions, compromises and old risk areas. Similarly, reproducible tests provide a concrete basis for assessing a correction proposed by a human or an AI.

11. Is Mantis ready for production?

The answer requires an important nuance. Mantis is well available in open source and Google provides instructions to start using it with different development agents. But its documentation does not recommend giving it free access to a critical system.

Google states that Mantis should be seen as a starting point to adapt to the needs and environment of each organization. For autonomous uses, the documentation describes enhanced measures: isolated environment, limited permissions, controlled network and dedicated infrastructure.

For a TPE or an SME, the main teaching is probably not "install Mantis tomorrow on your server". Rather, development tools will gradually integrate much more advanced analytical and verification capabilities. Prior to actual adoption, it is necessary to define the scope analysed, the accessible data, the authorised actions, the required validations and how to control the results.

12. Towards a more integrated security for development

For a long time, safety was sometimes seen as a separate step. An application was developed and checked before delivery. On the contrary, approaches such as that presented by Google seek to further integrate security directly into the development cycle.

Google Cloud describes an architecture where different agents intervene at several stages of the software cycle, from design to code analysis. Vulnerability could be detected by modification, automatically analysed, and then replicated in an isolated environment. A correction could be proposed, tests check its behavior and a developer review the whole before validating the modification.

The principle is no longer simply "check the application security once it is finished". It becomes "progressively integrating security controls into development itself". This approach can shorten the time between the introduction of a defect and its detection, while providing more context to the person who must make the final decision.

13. Conclusion: automate analysis without automating confidence

Mantis illustrates an important evolution of artificial intelligence applied to development. After code generation, documentation or testing, agents begin to intervene in more complex tasks: analyzing an architecture, seeking vulnerabilities, confronting their own results, replicating problems and preparing fixes.

For developers, this evolution can become extremely useful. An AI can quickly navigate an important code base, provide context and draw attention to a change or behaviour that deserves consideration. But this automation does not remove fundamentals. A professional application remains dependent on the quality of its architecture, its tests, the mastery of its dependencies and the follow-up carried out after it is put into production.

The future of AI-assisted safety is probably not based on a model capable of doing everything alone. Rather, it is based on a series of controls: analyze, confront, reproduce, correct, test and validate. Much of this process can be automated by the AI. Trust must continue to be built by verification.