AI Agent Privilege Escalation and Over-Permissioned Agents

Classic privilege escalation means an attacker exploits a flaw to gain rights they were not granted. There is a vulnerability, an exploit, and a moment where a control was defeated.

AI agent privilege escalation has none of those parts, which is why the term causes confusion and why existing tooling misses it entirely.

An agent holds a credential, usually its creator's. That credential carries real permissions. Anyone who can prompt the agent can ask it to use those permissions on their behalf. A person with no access to a system asks an agent that does have access, and the data comes back.

Nothing was bypassed. The agent authenticated normally, the target system authorized a valid credential, and every log entry looks correct. There is no alert because no rule was broken. The privilege was inherited by the agent, then borrowed by the user.

This is the machine insider pattern: an identity that behaves like an insider with broad access, that nobody is monitoring as one, and that will lend that access to anyone who asks it nicely.

1. Inherited creator access. The agent runs on the credentials of whoever built it. That person accumulated access over years, across projects, for reasons unrelated to this agent. The agent's reach is therefore a copy of somebody's employment history rather than a decision about what the task requires. This is the root pattern; the other four build on it.

2. Borrowed access through prompting. Anyone who can invoke the agent operates at the agent's permission level, not their own. This turns the agent into an access-broadening intermediary. A contractor who cannot open the CRM asks the agent that can, and the boundary that was supposed to exist between them stops existing.

3. Fixed-credential connections. Some agent platforms let a builder connect to a system using their own credentials for every user of that agent, rather than passing through each invoking user's identity. Every user then operates at the builder's level by design. Microsoft Copilot Studio's maker mode is the widely discussed example, and it is the default connection type rather than an advanced setting.

4. Action chaining. An agent composes multiple tool calls to achieve a goal. Each individual call is authorized. The sequence achieves something no single call was meant to allow: read from a restricted source, transform, then write to a destination with different controls. The authorization model evaluates calls one at a time, and the risk lives in the sequence.

5. Connection accumulation. Every MCP server or integration attached to an agent extends its reach. These are added over time, by different people, for different tasks. Nobody re-evaluates the total. The agent's effective authority is the union of all of them, and that union is rarely what anyone would have approved as a single request.

Privilege creep is the gradual accumulation of permissions that are granted and never removed. For humans it is slow: someone changes team, keeps the old access, and the surplus grows over a career.

For agents it is faster, for three reasons.

The starting position is already maximal. A human accumulates from zero. An agent starts with everything its creator has, so it begins where a human ends.

It inherits the creator's future creep too. When the creator gains new access next quarter, the agent gains it as well, silently, because they share a credential.

Connections add reach without touching permissions. Attaching a new MCP server extends what the agent can do without changing a single grant in the identity system. Reviewing the agent's permissions shows nothing new. Its actual reach grew.

None of those three produce an event that any review process is watching for. The configuration did not change. This is the gap between theoretical configuration, which is what the config page records, and effective authority, which is what the credential can reach today. Access reviews read the first. Only runtime behavior shows the second.

Privilege escalation is not the end goal. It is the precondition. AI agent data exfiltration is what privilege escalation makes possible, and it happens at a speed and scale that human-paced incident response cannot match.

AI agents move 16 times more data than human users. When an agent with escalated privileges begins querying records, the volume of data accessed in a single session can exceed what a human insider would access over months. By the time a security team identifies the anomaly, the data has already moved.

The detection challenge is specific. Agent activity logs, where they exist at all, record the agent's actions against the agent's own credentials. They do not record who invoked the agent, whether the invoker was authorized to receive the data the agent retrieved, or what the invoker did with the output. The log shows a normal API call from a known agent identity. Nothing in that log signals that a user without the required access permissions just received restricted CRM data, contract terms, or financial records.

This is the machine insider risk problem stated precisely. The agent acts like an insider because it holds credentials and accesses data. But no insider risk program covers it. The agent has no behavioral baseline, no manager who reviews its access during quarterly certifications, and no MFA prompt that would flag an unusual access pattern. It operates continuously, at machine speed, with the full authority of whoever provisioned its credentials.

Detecting AI agent data exfiltration requires correlating the invoker's identity with the agent's effective authority, not just logging the agent's API calls. Without that correlation, the log is noise.

Establish the creator for every agent. Escalation begins with inheritance, so you cannot reason about an agent's permissions without knowing whose they are. This is also the prerequisite for retiring agents when their creator leaves. See non-human identity management for the full lifecycle.

Resolve effective access, not configuration. For each agent and each attached connection, determine what the credential actually reaches today inside the connected system. This is where over-permissioning becomes visible and measurable rather than assumed.

Score combinations rather than individual grants. Evaluate what one agent can reach across everything available to it in a session. Flag the pairings that create a path from sensitive data to an external destination, since that is where the real exposure sits and no single permission review can surface it.

Separate agent credentials from human ones. Where an agent genuinely needs access, give it a dedicated scoped credential rather than a person's. This breaks inheritance at the root: the agent's reach becomes a deliberate decision, it stops growing with its creator's access, and it can be revoked without affecting anyone's job.

Watch reachability, not just entitlement. Track who can invoke each agent alongside what each agent can reach. The escalation path is the combination of those two facts, and neither one alone reveals it.

Obsidian maps this from runtime activity: which agents exist across connected AI platforms, who created each one, what effective access each holds inside your SaaS applications rather than what its configuration claims, and which combinations widen blast radius. The differentiating check is correlating agent identity against SaaS entitlements, so a user querying an agent that holds access they do not have is visible as the escalation it is. Runtime enforcement is available today for Claude and Microsoft Copilot; other platforms are covered for discovery and governance.

For coding agents, the escalation usually starts with a session flag rather than a misconfiguration: what --dangerously-skip-permissions actually removes.