Privilege Escalation in AI Agents: Attack Patterns and Detection

A technical exploit is a way to circumvent or defeat something. A semantic exploit is to get something to do what it was designed to do, but not for the one who asked it. It's because of that distinction that privilege escalation is very different with AI agents than it's been with previous software applications. No buffer overflow or a broken auth check is needed for an agent to access data it isn't supposed to be touching; all it needs is to be convinced, step by step, of a legitimate-looking tool call.

The number of incidents of agentic AI misuses and privilege escalation has exceeded all other agentic threat categories this year, with 520 cases reported by security teams monitoring incidents in this category to date in 2026. This piece will focus on how that escalation occurs: its confused deputy origins, how it was made by bad habits, the MCP-specific twist that makes it worse, and what it looks like when an agent is live in production.

The Confused Deputy Problem, Reintroduced by AI Agents

There's nothing new about privilege escalation in agents. An old one that autonomy made trigger easy. It's got a name, and a paper trail of decades, and the original variant is far from obscure for an AI agent.

The Classic 1980s Pattern

A paper written in 1988 by Norm Hardy, titled "The Confused Stupendous Deputy Problem," details the disorder at Tymshare about 10 years earlier. A compiler was executed with two files with authority: a file to write to a protected billing directory, and a file on which a user provided a path for optional debugging output. A user who directed that output path to the billing file had the compiler (which is a right unto itself) rewrite a file that he or she could never access directly. The compiler got confused because it couldn't distinguish a legitimate debug request from a malicious one. The original blog entry on the confusing deputy issue at Hardy remains the place to go for security teams to reference when they are trying to explain why identity-based permission checks continue to fail in delegated systems, agentic or not.

Why the AI Agent Variant Is Semantic, Not Technical

Hardy's job was one, and his blind spot was one. The AI agent may have thirty or more tools at its disposal, a natural language interface that can be spoken to by anyone who can provide text, and the job instruction to do its work in any way it can. That's because confused deputy AI agents are a fundamental semantic issue, not a technical one. No tool gets broken, no credential stolen; the agent is correctly authenticated, calls the tools it's supposed to call, and still does something that nobody with the authority to approve it did approve.

There has to be a vulnerability, a bounds check that did not occur, a CVE that was not patched. All that's required for a semantic exploit is language; the agent's own reason is the attack surface itself. The semantic exploit vs technical exploit difference in most 2026 incident write-ups: attackers are not breaking agents; they are speaking to them, and the job of the agent is to be spoken to.

Maker Mode: Inheriting a Creator's Privileges

Identity teams have a name for the single most prevalent enterprise pattern that is the root of agent privilege escalation: maker mode. It details the situation where an agent is created by one user, and then passed onto a team of users who have more limited permissions.

The agent doesn't re-check who's asking. It will run on the maker's effective access anytime regardless of who entered the prompt. For a finance analyst who can never directly query the general ledger, he may request a shared agent to do so, since the agent is still under the access of the manager and has never been accessed since the share.

This is the most basic form of maker mode privilege escalation, and it is prevalent just because it isn't malicious. A builder ends up attaching some tools to something to make it work and sharing the agent because it is useful, and access becomes more prevalent than anyone looks at grants. The agent is now a permanent stand-in for one person's permissions and is exercised by people an individual person never vetted.

The remedy is easily stated: check the invoking user, not the agent, for the permission they are exercising, and have a second check to ensure that the agent has access to no more than the permission that the invoking user has. Most businesses don't have a process in place to even detect when this gap appears.

Credential Sharing and the Accountability Gap

Maker mode is a permissions issue. The two are synergistic, and credential sharing is an accountability issue. Most agents are not a type of entity unto themselves. They use a shared service account or an API key to authenticate or the owner's session token in every downstream system, regardless of which agent is calling it.

The problem with agent credential sharing risk is that if there are multiple agents and a handful of human users, all of them sign in through the same OAuth application or long-lived key, they can't tell who did what. An audit log reveals who made a request on behalf of a shared identity, but not who the agent was, and which prompt it was invoking, on whose behalf.

This is important because privilege escalation relies on taking advantage of just this ambiguity. If an attacker obtains one agent who carries the same credential to act, then he will obtain all the credentials that the credential can reach, and the log entry will be the same as the legitimate calls that precede it. Non-human identities close that gap, and most organizations continue to operate their agent fleets on credentials designed for one human user at one time a day.

Action Chaining: How the Blast Radius Multiplies

Action chaining is the sum of the individual authorized steps resulting in a collectively unauthorized outcome. The three permissions of an agent, read access to a CRM, write access to an email tool, and search access to a knowledge base, seem like good credentials in isolation. They were connected in a series, allowing the agent to read the customer's contact record, write a note in the internal system that was never intended for the customer, and send it all in a single process without a human ever looking at it.

This is the form of an attack with an AI agent tool chaining: no single call triggers a policy, as there is no single call to violate. The violation is the sequence, and a policy that would be able to approve or deny a call on a single action wouldn't have much to say about the significance of multiple consecutive, individually fine actions.

The radius of the effect of action chaining depends on the number of tools an agent can access and the number of steps he or she can move without a checkpoint. If the agent is very constrained (two tools), then there are few possible chains. An agent with 12 connectors and no limit on call depth has a space of combinatorial size that is impossible to see from the tip of his/her fingers.

Least privilege on a per-permission basis is important, but not enough here. The attack requires an unbounded outcome to be reached via a sequence of bounded permissions, which is a property of the sequence rather than of the grant.

MCP-Specific Privilege Escalation

The confusion of the deputy problem becomes a new problem because of the standardization that Model Context Protocol provides to agents for discovering and calling tools on servers they don't own. The trust boundary shifts from a static permission structure in the application to a real-time, third-party-supplied description, which is read and executed by the agent each time it decides on a tool to use.

The MCP Server as Its Own Confused Deputy

An MCP server typically operates with its own higher privileges to the back systems it serves, which include a database, a ticketing system, and a cloud API, all of which are independent of the access the calling agent or user may have. If the agent calls a tool on that server, this server runs the tool with its own credentials, not the user's. It's a viable system for legitimate use, and a second confused deputy behind the first deputy.

The moment someone other than the security team that approved the tool changes the tool description in the MCP server, you will have problems whenever the agent tries to read the plain text of that description to determine how to call the tool. The bulk of the MCP implementations are dynamic, so that when a publisher updates a description, the new version appears in all the clients without any further review.

This is a re-trust that does not require re-approval, the structural flaw that underlies the bulk of 2026 MCP privilege escalation attacks. When a server is approved by an organization, behavior may stray after that, and nobody else will re-check to ensure it is appropriate. The agent cannot tell a description its owner sent from one an attacker sent, as both come from the trusted channel.

Case Study: Microsoft's June 2026 Tool-Poisoning Escalation Trace (ASI02/ASI04)

So far, the most explicit evidence for an MCP-based privilege escalation is Microsoft Incident Response's disclosure of June 2026, which corresponds 1-to-1 with the OWASP Top 10 for Agentic Applications, ASI02, Tool Misuse, and ASI04, Agentic Supply Chain Vulnerabilities. The technique isn't new: It was first spotted in a disclosure by Invariant Labs in April 2025, and Microsoft saw the same pattern repeat against enterprise agents going forward into 2026.

The scenario was a Copilot Studio agent that a finance team developed for vendor invoices that was connected to three tools, including a third-party invoice-enrichment MCP server that was provisioned by a service owner and approved for production without a separate security review.

The codebase of the enrichment server was taken by someone with access to it, and a visible name for the tool was not changed; only a new instruction was inserted, one that checks for fraud. Since the metadata changes were pushed to the server live without having to go through the approval process, the poisoned description became active as soon as it was pushed to the server. The financial analyst then put an innocuous question to the agent about a supplier, to which the agent dutifully replied, picking up a pile of unpaid invoices and folding them into the enrichment call as if they were the original request. The server provided a plausible response and sent the data in an off-console manner to an external address; no alert was triggered.

This is not because of something that was broken. The tool had been tested, the query was executed by the analyst on his own valid access, and the outbound call was directed at a server trusted for months. The gap was the transition of trust from one system to another: after a tool is reviewed, it is not usually revisited to confirm that it remains as approved for review. This is an example of tool poisoning escalation in action.

Why Network and Firewall Controls Can't Catch This

Each control point within a security stack has one question to answer: "Is this connection allowed to occur?". A Firewall examines the source, destination, and port. An API gateway will determine whether the caller has a valid token and if it has the scope to access the endpoint the caller is attempting to access. Nothing was constructed to have one of those questions that really will challenge them: Is this the specific request, by this caller, actually something this caller should be doing right now?

Agents can have a valid API connection to a customer database, meaning that all queries generated by that account are the same, so the firewall okays all of them. It does not know the difference between a single lookup and a bulk extraction performed as such, as the same port is used and the same authenticated identity is used.

This is the semantic validation gap, an action is technically okay, but it is semantically wrong, and there's no perimeter control that picks up the context. Closing it does not simply mean looking at whether it's supposed to be able to connect, but at what it's doing at the application and tool-call level.

Multi-Agent Systems: Escalation Without a Human in the Loop

The ability of one agent to escalate privileges is limited by the privileges they have and the ability to escalate those privileges. That's not true of a multi-agent system, because agents regularly delegate subtasks to other agents and much of the context and access that the delegating agent was willing to share is transmitted as part of the delegation, with no need to re-verify that the delegating agent had indeed transferred it.

This is what they call cross-agent privilege inheritance: a low-privilege agent sends a request to a high-privilege agent to do something on its behalf; in order to do so, the high-privilege agent needs to be able to verify at least two things: that the agent from which it received the request has the authority to make such requests; and that the requester actually is the agent it claims to be. The permission was not stolen; it was handed over hop-by-hop by agents that are designed to trust one another.

The difficulty in catching this variant is that there is no point in the chain where a human decision is made. Agent A may delegate to agent B, who delegates to agent C, who has access that is relevant, and the delegator of the original delegate may never see what agent C eventually does. The blast radius isn't just large; it's difficult to follow back to any decision that anyone made.

What the Data Says About Over-Privileged Agent Identities

This problem is visible in the level of provisioning of identities that aren't human. According to Non-Human Identities Top 10, an over-privileged non-human identity was cited as the top cause of security incidents, accounting for 37% of all incidents related to non-human identities, a research project by the Open Web Application Security Project (OWASP) developed from Cloud Security Alliance (CSA) research. The same study revealed that 26% of organizations felt that more than half of their service accounts were over-privileged.

Both numbers are exacerbated by long-lived API keys. OWASP lists this as a separate category, as it is an open-ended window for an attacker who gets these credentials rather than a bounded one if they are open-ended or if they are set years in the future. An over-privileged agent identity is a wide door; a long-lived credential on this identity means the door doesn't get narrower over time even after the agent who needs this access has retired.

The numbers add up to an ecosystem where, before the attack occurs, default permissions and the long-lived credentials required for privilege escalation are already present.

Detecting Privilege Escalation in Practice

Static reviews are what an agent is told to look for. First, they can't see what it does once it is up and running, so the only way to detect privilege escalation in production is to use behavioral anomaly detection for agents and not just a permission audit at deployment time.

There are 3 signals that are most important. The first is something that is in an agent's baseline but they're making a tool call to something they've never called before, and that's a deviation that's worth flagging even if they're allowed to do it. The latter is session or credential reuse between contexts where there is no need to have any overlap, which is typically the first sign of maker mode or credential sharing abuse. The third one is cross-boundary chaining, a succession of individual valid tool calls that span from one data domain into another, with no previous reason for the agent to have interacted with it.

All of these signals do not need to be known ahead of an attack taking place. They need an idea of what normal is for a given agent, and a system that monitors to detect that an agent is not normal.

Mitigation Principles

Two NIST SP 800-207A principles more effectively address this gap than any individual product function: a short-lived credential issued for each task as opposed to standing access; and an individual, verifiable identity for each agent, instead of a shared account applicable to an entire fleet. Short-lived credentials reduce long-lived API key risks to just the duration of a single task. Cross-agent privilege inheritance/cross-agent credential-sharing incidents are attributable, because there is a distinct identity per agent.

To get there takes a bit of a mind shift from agents, as opposed to reusing the RBAC and ABAC approaches developed for human users, and as an identity management discipline on its own, agent identity, rather than an extension of existing IAM.

How Akto Detects and Blocks Privilege Escalation Patterns

Escalation of privilege is a problem of runtime and discovery, not only a configuration audit, for Akto. The agent calls the same tools on the same machines in this same sequence that it does in production, as Akto Argus is an inline proxy on both MCP and homegrown agent traffic. Action chaining visibility is achieved by that positioning, where Argus looks at the chaining of calls an agent makes, rather than whether each individual call was authorized.

On the discovery side, Akto maps cloud and on-prem MCP servers and agent connections, and conducts adversarial probes, over 1,000 of them, to find over-permissioned tools and unsafe access paths, and has audit-ready records mapped to frameworks such as OWASP and MITRE ATLAS.

The other side of the credential-sharing and risk coverage gets done in Maker mode via Akto Atlas. It monitors the actions of employees when invoking AI agents and MCP servers from their own devices, and blocks any agent that is still running on the creator's legacy access and connectors with sensitive data access that hasn't been accessed since setup.

Argus and Atlas make up the complete picture that the article outlined in this post: what an agent is capable of doing and what they are actually doing with it.

Final Thoughts on Privilege Escalation in AI Agents

Privilege escalation is succeeding with AI agents because, for decades, the controls that are supposed to block it are designed to answer the question, "Is this allowed? Agents should have a system that continues to ask that question after the initial yes, after each subsequent tool call, and again after each subsequent tool call after that, because once they say yes, it isn't an answer that should live forever without any questions. When a chain of calls finishes in less than a minute, and a security program doesn't reach the point where it has to wait for a quarterly access review, it's a position that isn't defensible in 2026.

Akto provides runtime visibility and inline enforcement to bridge that gap between employee-driven AI use and homegrown agents, to watch tool sequences in real-time, rather than reconstructing them after an incident. If privilege escalation is on your risk register this quarter, make sure to book a demo and see how Akto Argus and Akto Atlas deal with privilege escalation in real life.

FAQs: Privilege Escalation in AI Agents

1. What is the confused deputy problem, and how does it apply to AI agents?

It was named by Norm Hardy in 1988, referring to a trusted program that has been used in a way that is not intended. AI agents replicate it since they are not always able to distinguish between a proper instruction and one that sneaks in via the metadata of a tool or from user input.

2. What is "maker mode," and why is it a common privilege escalation pattern?

Maker mode is the mode that a shared agent continues to run in whenever it is called by any user. It is common because sharing a useful agent is very easy, but a review of the access grant underlying them is rarely conducted every time it is shared.

3. How does action/tool chaining amplify the blast radius of a privilege escalation attack?

The more tools and unchecked steps an agent can build up in a chain, the bigger the unapproved outcome can get, as each call in the chain can be individually authorized, but the whole chain leads to an outcome that is not authorized.

4. How is privilege escalation in AI agents different from traditional software privilege escalation?

Typical privilege escalation will attempt to take advantage of some malicious weakness, such as a bug, misconfiguration, or broken check. Agent privilege escalation is a semantic thing; it's nothing really. It's an agent that does things that its owner did not approve.

5. What is MCP-specific confused deputy, and how does it differ from application-level confused deputy?

An MCP server runs with its own elevated credentials, separate from the caller's access, and reads plain-text tool descriptions that can change after approval without triggering re-review, a dynamic, publisher-controlled layer a fixed application permission model doesn't have.

6. What happened in Microsoft's June 2026 tool-poisoning escalation disclosure?

The tool description of an MCP server has been subtly modified after approval to include hidden instructions. A Copilot Studio finance agent followed, extracting unpaid invoice details and passing them out to the outside world via a seemingly benign enrichment call, but no alert was triggered.

7. Why can't traditional firewalls or network controls detect this kind of escalation?

Firewalls and gateways determine if a connection or token is authorized, not if a specific request is "substantively appropriate" at this time. A malicious query is sent through the same authenticated path as a regular query, and thus network controls are not able to tell the difference.

8. How much more dangerous does privilege escalation become in multi-agent systems?

Orchestration passes context and access between whatever agents; there's no human decision point in between agents, so a low-privilege agent can find a higher-privilege agent to do its work, and the chain never appears to the human who started.

9. What percentage of non-human identity security incidents involve over-privileged accounts?

The Non-Human Identities Top 10 project, run by OWASP, identified that, more than any other root cause tracked, overprivileged identities were the root cause of 37% of NHI-related security incidents, and 26% of organizations believe more than half of their service accounts are over-privileged.

10. What does NIST SP 800-207A recommend to prevent maker-mode-style escalation?

Short-lived, task-scoped credentials, rather than standing access and application-level identity infrastructure where every workload has an independent verifiable identity as opposed to a shared one, limiting the amount of access a maker-mode agent can inherit.

11. How does Akto detect and block privilege escalation patterns in production agents?

Akto Argus performs live inspection of MCP and agent traffic, not just individual calls, and validates sequences of tool calls for unsafe chaining and excessive permissions, whereas Akto Atlas raises the flag on employee endpoints before ever reaching production systems for maker-mode and credential sharing risk.