AI privilege escalation does not require an exploit.
Security teams understand traditional privilege escalation well. An attacker exploits a vulnerability, abuses a misconfigured permission rule, or cracks a credential to move from a low-privilege account to a high-privilege one. The escalation requires an active attack step. Something breaks or something is abused, and forensics can usually find the seam.
AI privilege escalation works differently. Nothing breaks. The agent is doing exactly what it was configured to do. The escalation happens because the agent holds credentials that exceed what the invoking user is authorized to access, and no existing control checks whether the invoker's permissions align with the agent's permissions before execution begins.
The core mechanism: an AI agent is not a passive tool. It holds tokens, OAuth grants, service account credentials, and embedded API keys. When a user invokes that agent, the agent acts using its own stored credentials, not the user's. If the agent's credentials grant access to data the user is not authorized to see, the user gets that data anyway. The IAM boundary that was supposed to stop them never had a chance to fire.
This is the visibility gap that security teams describe as ghost chasing. The configuration looks correct. The user's access policy is correctly scoped. But the agent operates in a layer between the user and the SaaS application where no traditional access control applies.
The distinction from traditional privilege escalation matters for how security teams respond. Traditional privilege escalation leaves exploit artifacts. AI privilege escalation leaves only normal agent activity logs, which look identical to authorized usage.
AI agent privilege escalation is not a single attack pattern. It is a family of five related mechanisms, each with a different trigger and a different remediation path.
When an agent is built using the creator's credentials and those credentials are embedded into the agent's connector configuration, every user who invokes the agent operates at the creator's privilege level. A business analyst invokes a Copilot Studio agent built by a Salesforce administrator. The agent queries CRM records using the administrator's embedded credentials. The analyst retrieves data they were never provisioned to see. No access policy was violated from the agent's perspective. The IAM boundary was bypassed entirely.
This is maker mode privilege escalation. It is the most common pattern in enterprise environments and the most difficult to detect without correlating the invoker's identity against the agent's credential source.
A single agent call triggers a sequence of downstream tool calls across multiple applications. Each step in the chain may appear authorized in isolation. The combined sequence accesses data that no single step should have reached. Action chaining is how an agent with moderate permissions produces an outcome that requires elevated permissions, by assembling access across multiple authorized but individually limited steps.
An agent with elevated permissions is manipulated into performing an action on behalf of a user who lacks the authority to request that action directly. The agent is the deputy. The user is the unauthorized principal. The agent cannot verify whether the invoker has the right to request the specific action being executed. It trusts the invocation. This is the confused deputy problem applied to agentic systems, and it is a direct consequence of agents lacking invoker-permission verification at runtime.
Agents inherit OAuth tokens, service account roles, and API keys from the applications they connect to. When those credentials are over-scoped, the agent inherits excess authority. When the agent is then shared across teams or made org-wide accessible, every user in the organization effectively inherits that excess authority through the agent. Credential inheritance is not a configuration error in isolation. It becomes a privilege escalation vector when combined with broad agent accessibility.
Agent A has limited permissions. Agent B has broad permissions. Agent A is configured to call Agent B as part of its workflow. A user invokes Agent A, which invokes Agent B, which accesses data the user and Agent A were never supposed to reach. The trust relationship between agents creates a transitive escalation path. No single agent in the chain violated its own permission boundary. The chain as a whole crossed a boundary that no individual component was supposed to cross.
These five patterns frequently appear together. An agent operating in maker mode that also performs action chaining and calls a second agent via transitive trust represents a toxic combination: multiple risk factors on a single agent creating compounding, critical-priority risk.
Action chaining deserves a concrete walkthrough because it is the mechanism that turns a moderate escalation event into a high-severity incident.
Consider this scenario: a sales operations user invokes an n8n workflow agent to pull a summary of recent deal activity. The agent is authorized to read Salesforce opportunity records. That is the intended scope.
Step one: The agent queries Salesforce and retrieves opportunity data. Authorized.
Step two: The agent calls a connected document tool to retrieve the contract templates associated with those opportunities. The document tool connection was added by the workflow builder for a different use case. The agent's connector has read access to the entire contracts folder, not just the templates. Authorized by the connector scope, but broader than the task requires.
Step three: The agent calls a summarization tool and passes the full document folder contents as context. The summarization tool logs inputs to an external service for model improvement. The contracts folder contains compensation data, legal terms, and client PII. That data just left the organization.
No single step was an exploit. Each tool call was within the agent's configured permissions. The chain as a whole produced a data exposure that no individual step would have caused. This is the multiplicative blast radius of action chaining: each additional tool call in the sequence expands the potential exposure surface, and the final outcome bears no resemblance to what the agent was supposed to do.
The challenge for security teams is that action chaining is invisible to tools that only examine agent configuration. The configuration shows what tools the agent can call. It does not show what sequence of calls the agent actually executed, what data moved between steps, or what the cumulative access footprint of the full chain was. Runtime truth, not theoretical configuration, is the only way to see the chain as it executes.
These risk factors map directly to OWASP Low-Code/No-Code Security project categories, particularly LCNC-SEC-01 (Account Impersonation) and LCNC-SEC-06 (Excessive Data Access).
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.
Privilege escalation prevention in agentic systems requires three layers working together. Each layer addresses a different failure mode. None of the three is sufficient alone.
Probabilistic agents require deterministic guardrails. An AI agent's behavior is non-deterministic by design. It can deviate from its intended workflow based on input, context, and model state. A deterministic guardrail does not try to predict what the agent will do. It enforces fixed rules about what the agent is allowed to do, regardless of what the agent decides.
Effective deterministic guardrails for AI privilege escalation include:
The visibility gap in AI privilege escalation is an identity correlation problem. Security teams need to know three things simultaneously: who invoked the agent, what credentials the agent used to execute, and whether the invoker's permissions align with the agent's effective authority. No single data source provides all three.
Closing this gap requires an identity graph that maps the relationship between human identities, agent identities, and the SaaS entitlements those agents hold. Effective authority, not theoretical configuration, is the output. When a runner invokes an agent, the system checks the runner's identity against the agent's maker-mode credentials and flags the delta. That is the correlation event that makes privilege escalation visible.
Configuration review catches what agents are set up to do. Runtime monitoring catches what they actually do. For AI privilege escalation prevention, the monitoring layer must capture:
See how Obsidian's identity correlation layer surfaces AI privilege escalation before data moves.