Google recently open-sourced Mantis, an agentic security framework designed to automate a remarkable amount of the vulnerability discovery and remediation process. Mantis can study a software repository, examine its history, understand architecture and security context, identify potential vulnerabilities, challenge its own findings, reproduce vulnerabilities, construct exploit chains, generate patches, and test whether those patches actually work.
This is much more than another AI code scanner. It is an example of where enterprise AI is going: autonomous or semi-autonomous systems that can reason about complex environments and then take increasingly consequential actions inside them.
Google describes this evolution in unusually direct language. In discussing the technology behind Mantis, Google notes that AI models have demonstrated the ability to discover and exploit vulnerabilities with little, if any, human assistance. The company also describes the goal of addressing vulnerabilities at machine speed.
Those two ideas belong together, and enterprises should pay attention to what they imply.
If an AI can discover a vulnerability, generate code to exploit it, execute that code, determine an appropriate fix, modify software, and participate in the release process, then the important enterprise question is no longer simply whether the AI is capable of performing the task. The much harder question is whether the AI has legitimate authority to perform each of those actions.
That distinction is going to become fundamental to enterprise AI.
Mantis Is Impressive — and Its Own Safety Guidance Shows the Problem
Mantis appears to be thoughtfully designed. Google is not simply asking a language model whether a piece of code looks vulnerable and accepting the answer. The framework uses multiple stages and specialized capabilities to improve reliability. It gathers context, develops threat models, analyzes source code, critiques findings, attempts to reproduce vulnerabilities, and ultimately can propose fixes.
That is exactly the direction sophisticated enterprise agents are heading. Instead of one model answering one question, enterprises will increasingly deploy systems composed of multiple agents, tools, models, data sources, credentials, workflows, and automated actions.
But Google's own guidance around Mantis is revealing. The documentation warns that the system can generate and execute code that may be unstable or behave unexpectedly. It recommends running Mantis in restricted environments rather than on machines with access to production systems, sensitive data, or internal networks. Google also discusses the risks of automatic approval, non-deterministic agent behavior, prompt injection, unattended execution, and even the possibility that future self-improvement mechanisms could modify an agent's own operating instructions.
These are responsible warnings. They are also a preview of the architectural problem every large enterprise is going to face.
We are building AI systems that can act faster, across more systems, with more autonomy than humans can realistically supervise one action at a time. Sandboxes help. Identity systems help. Human approvals help. Policy engines help. Network controls help. None of those technologies, however, fully answers the central question: Does legitimate enterprise authority exist for this exact action, against this exact resource, for this exact purpose, at this exact moment?
That is a different problem.
Consider What Happens When Mantis Enters a Real Enterprise
Imagine a security engineer at a large financial institution gives an AI system like Mantis a perfectly reasonable objective: “Find and fix security vulnerabilities in our payment platform.”
The instruction sounds clear to a human. From an authority perspective, it is enormously ambiguous.
Does “find vulnerabilities” authorize the agent to read every repository associated with the payment system? Can it inspect repository history? Can it retrieve secrets that were accidentally committed three years ago? Can it inspect authentication systems owned by another team? Can it access production telemetry? Can it call external services?
Then there is the word “fix.” Does that authorize Mantis to modify source code? Open a pull request? Change a security policy? Alter infrastructure-as-code? Update a dependency used by 40 other applications? Modify a GitHub Action? Change a cloud configuration? Merge its own patch? Trigger CI/CD? Deploy to production?
A capable AI can make very reasonable technical arguments for doing many of those things. That does not mean the enterprise authorized them.
This is where the difference between capability and authority becomes critical. The AI may know what should be done technically. It should not be allowed to convert that technical judgment into organizational authority.
Scenario One: A Vulnerability Reproducer Accidentally Reaches Production
Suppose Mantis discovers what appears to be an authentication bypass. The reproduction agent attempts to prove that the vulnerability is real, which is precisely what the system is designed to do.
In the test environment, however, the necessary service is unavailable. During its investigation the agent discovers another endpoint in a configuration file. That endpoint happens to point to production, and credentials available to the development environment happen to work there.
From the AI's perspective, using the endpoint may be a logical next step toward completing the task. Technically, the system can do it. The credential is valid. The network route exists.
But should the AI be allowed to execute an autonomously generated exploit against a production authentication service?
The answer should not depend on whether the agent is clever enough to find a route to production. It should depend on enterprise authority.
An independent authority layer should be able to evaluate the proposed action before execution and determine that although the agent is authorized to reproduce the vulnerability inside a designated sandbox, it has no authority to execute that exploit against a production resource.
The distinction matters: the agent is not being prevented from doing useful security work. It is being prevented from deciding for itself how far its authority extends.
Scenario Two: The AI Discovers Credentials It Was Never Supposed to Use
Software repositories contain history, and history is messy. Credentials get accidentally committed. Old API keys remain in scripts. Service accounts outlive the projects that created them. Acquisitions bring together systems with very different ownership rules. Employees change jobs while technical permissions remain.
Because Mantis can study repository history to understand previous changes and security fixes, it may encounter credentials or access paths that still work even though the organizational authority behind them disappeared years ago.
This exposes one of the biggest weaknesses in traditional enterprise security. A technically valid credential is not the same thing as legitimate current authority.
An access system may determine that a token is valid and permit the connection. But perhaps the service account belonged to a discontinued project. Perhaps the employee who invoked the AI never had authority over the target system. Perhaps access to the underlying data is restricted by contract. Perhaps a temporary incident-response permission expired months ago.
Authentication tells us whether the credential is genuine. Access control tells us what that credential is technically permitted to reach. Enterprise authority needs to determine whether the action is still legitimate in the organizational context that exists today.
AI makes that distinction much more important because agents can discover and use available technical pathways far more quickly than humans.
Scenario Three: The Security AI Fixes the Security System
Now imagine Mantis finds a vulnerability inside an authorization component.
The agent correctly identifies the problem and generates a patch. The patch compiles. The automated tests pass. Perhaps the vulnerability disappears.
But the patch also changes an enterprise security control. Maybe it broadens an accepted identity type. Maybe it relaxes token validation. Maybe it removes a check that appeared redundant to the AI. Maybe it changes a GitHub workflow that controls deployments.
The software may still work exactly as intended from a functional perspective. But software correctness and organizational legitimacy are not the same thing.
An enterprise authority system might reasonably allow the AI to read the authorization module, analyze the vulnerability, generate a proposed patch, and create a security pull request. The same system might prohibit the agent from modifying production IAM policies, approving its own pull request, merging a security-sensitive change, or initiating deployment without additional authority.
This is an important architectural principle for agentic systems: authority should be granular to the effect being caused.
Giving an AI permission to investigate a problem should not silently become permission to alter every system necessary to solve it.
Scenario Four: Multiple Agents Combine Into More Authority Than Any One of Them Possesses
Mantis is especially interesting because it demonstrates another problem enterprises are only beginning to confront: multi-agent collaboration.
Suppose one agent is allowed to analyze source code. Another is allowed to execute tests. A third can create files. A fourth can open pull requests. An automated CI/CD system can deploy approved changes.
None of those components, considered individually, has explicit authority to change production.
But together they can potentially cause exactly that outcome.
The first agent identifies the opportunity. The second produces a working exploit. The third changes a configuration. The fourth submits the change. The pipeline subsequently deploys it.
At what point did the enterprise authorize the final result?
This is a problem we think of as emergent collective authority. Individually permissible actions can combine into a consequential outcome that exceeds the mandate originally granted to any participant.
An enterprise authority system therefore cannot look only at isolated API calls. It needs to understand the relationship between actions. Who initiated the objective? What authority did that person or system possess? What authority was delegated to the first agent? Was further delegation permitted? What did subsequent agents do with it? Has the aggregate effect of the workflow exceeded the original mandate?
These questions become critical when machines are coordinating with other machines at machine speed.
Scenario Five: Prompt Injection Compromises the Security Agent
Google itself identifies prompt injection as a concern for unattended environments.
That is particularly relevant for security agents because they operate on hostile material. Source code, documentation, configuration files, repository issues, build scripts, test data, and external inputs can all potentially contain content designed to manipulate an AI system.
An attacker might deliberately insert instructions that attempt to convince an AI security tool to disregard a vulnerability, execute a script, disclose information, alter a configuration, or reinterpret its assignment.
We should absolutely improve model defenses against these attacks. But enterprises should not make their security depend entirely on the assumption that an AI agent will never be deceived.
A stronger architecture assumes that eventually some agent will be manipulated.
The second line of defense should be that compromising the agent does not automatically give the attacker enterprise authority.
If prompt injection persuades an AI that it should access another repository, modify a protected branch, call a production API, or change infrastructure, an independent authority system should still determine whether that effect is actually permitted.
The compromised AI may believe the action is appropriate. The enterprise does not have to agree.
Scenario Six: A Reasonable Objective Expands Into an Unreasonable Scope
AI systems are very good at decomposing objectives and finding efficient paths toward completion.
That creates another authority problem.
Suppose the instruction is, “Fix the security problems in this application.” During the investigation, the agent discovers that the root cause is a shared library used by dozens of applications. Fixing the shared library is technically the best solution.
So the scope expands. The application leads to a shared repository. The shared repository leads to a package. The package leads to build infrastructure. The build infrastructure leads to container images. Those lead to deployment configurations and potentially production systems.
Every step may be technically logical.
None of those steps necessarily carries additional organizational authority.
This is why AI authority needs to consider more than identity and permissions. It needs to understand the authorized resource, purpose, action, delegation rights, environment, time limits, data sensitivity, maximum consequence, and other constraints established by the enterprise.
A smart agent should be allowed to reason beyond its mandate.
It should not be allowed to expand its mandate simply because its reasoning says doing so would be useful.
Scenario Seven: Yesterday's Authority Is Still Technically Alive Today
Enterprise authority is constantly changing. People move between teams. Contractors leave. Emergency permissions expire. Projects end. Production freezes begin. Data is reclassified. Acquisitions change system ownership.
Unfortunately, credentials and permissions do not always change at the same speed.
That creates an especially dangerous combination with autonomous agents. An AI may possess a technically valid credential long after the enterprise authority that justified the credential has disappeared.
Before an AI takes a consequential action, an authority decision should therefore be based on current state rather than historical configuration alone. Is the principal still in the role that granted this authority? Does the mandate still exist? Has it expired? Has it been revoked? Does the resource remain inside the authorized scope? Is the stated purpose still valid?
For human-scale systems, enterprises have often tolerated inconsistencies between organizational authority and technical permissions. Machine-speed agents make those inconsistencies much harder to tolerate.
This Becomes Even More Important as Mantis Evolves
The Mantis roadmap points toward continuous operation and increasingly autonomous software development environments. Google discusses concepts such as a “Software Dark Factory,” where agentic systems could participate continuously in vulnerability research, remediation, and release gating. The documentation also discusses potential self-improvement, where information from previous results could eventually be used to refine the agents themselves.
That future is not difficult to imagine.
An enterprise AI system discovers a problem, investigates it, reproduces it, develops a fix, tests the fix, modifies software, updates its own operating procedures based on what it learned, and participates in deciding whether the resulting software should be released.
At that level of autonomy, human approval cannot be the primary control mechanism.
Humans simply cannot review every machine-speed decision generated by thousands of enterprise agents. Eventually the organization will either automate the approvals, create broad standing permissions, or overwhelm people with approval requests until they rubber-stamp them.
Google's own warnings around automatic approval show why that approach is dangerous.
The answer cannot be to slow AI back down to human speed.
The answer has to be machine-speed authority resolution.
This Is the Problem Authorized AI Is Being Built to Solve
At Authorized AI, we believe enterprise AI is missing an independent authority layer.
IAM remains important. Policy engines remain important. Sandboxes remain important. Human supervision remains important. Security monitoring remains important.
But none of them completely answers the question that increasingly matters before an AI causes a consequential enterprise effect:
Does legitimate enterprise authority exist for this exact action?
Authorized AI is being built as an independent enterprise authority control plane designed to answer that question before execution.
The principle is straightforward: No authority, no action.
Before an AI agent changes source code, accesses protected data, calls a production API, modifies cloud infrastructure, changes a Salesforce record, invokes another agent, alters a workflow, or initiates some other consequential action, the enterprise should be able to determine whether legitimate authority exists for that effect.
That decision can incorporate the initiating principal, the organizational mandate, delegation, the target resource, the exact proposed effect, the purpose of the action, its environment, expiration, current evidence, and the cumulative consequences of related actions.
The crucial architectural point is that this determination should occur independently of the AI making the recommendation.
The model should not be the source of its own authority.
Mantis Should Not Be Restrained. It Should Be Properly Authorized.
Mantis is not the problem.
In fact, technologies like Mantis are exactly what enterprises should want. We should want AI systems capable of finding vulnerabilities that humans miss. We should want them capable of reproducing sophisticated attacks, developing fixes, and helping security teams operate much faster.
The security objective should not be to make these agents less intelligent or less useful.
The objective should be to allow powerful agents to operate at full speed inside legitimate enterprise authority.
Mantis may determine that a vulnerability exists. It may determine that running a particular exploit is the best way to prove it. It may conclude that changing a shared component is the best way to repair the problem. It may decide that another agent or tool should be brought into the workflow.
Those are reasonable machine judgments.
But the authority to carry them out must come from the enterprise.
That separation between intelligence and authority may become one of the most important architectural boundaries in enterprise AI.
Google's Own Language Is Telling Us What Comes Next
What makes Mantis particularly significant isn't just its technical capability. It is the language required to describe how a system like this must be operated safely.
Google discusses autonomously generated code, unexpected agent behavior, isolation, restricted environments, human verification, automatic approval risks, prompt injection, non-determinism, production access, and controls around future self-modification.
Those warnings should not make enterprises afraid of agentic AI.
They should tell us what infrastructure we need next.
As AI systems become capable of executing increasingly complex workflows, the enterprise needs an independent mechanism capable of distinguishing between what an AI can do, what it believes it should do, and what the organization has actually authorized it to do.
For decades, enterprise security has asked who you are and what systems you can access.
Agentic AI forces another question:
Who gave this machine the authority to cause this particular effect?
That question becomes considerably harder when agents delegate to other agents, collaborate across systems, operate continuously, consume hostile input, discover new resources, and take actions far faster than humans can supervise.
That is why we believe enterprise AI needs an authority layer.
Google Mantis gives us an impressive view of how powerful these systems are becoming.
It also gives us an equally important view of the problem enterprises now need to solve.
AI capability is accelerating rapidly.
Enterprise authority infrastructure has to catch up.
That is what we are building toward at Authorized AI.
Proof Before Execution. No authority, no action.
Stay tuned.
NEXT STEP