The Permission Gap: Why Your AI Agent is a Privilege Escalation Machine
The Permission Gap: Why Your AI Agent is a Privilege Escalation Machine
In our last post, we argued that cryptographic identity gets an agent to the door, while application access management decides which rooms it can enter. Let’s follow that thread one room deeper. A critical question hides behind “which rooms,” and it’s the one most agent deployments get wrong by default.
When your security team onboards an agent, they define what it may do—which tools and resources it can access. That’s necessary, but it doesn't dictate what the agent can actually do. An agent's true capability is the intersection of what security allows and what the human behind the agent is permitted to do in the application. Miss that intersection, and you’ve built a privilege-escalation machine with a friendly chat interface. This failure mode has a name: the confused deputy problem, and it is currently the dominant concern in agent security.
How the Gateway Ends Up Holding the User’s Token
Let's walk through the mechanics. A human asks an agent to execute a task—say, working with data in Snowflake. The agent doesn’t talk to Snowflake directly; it routes through a gateway. To act on the user's behalf, the gateway acquires an OAuth token for that user—typically a delegated, on-behalf-of token via OAuth 2.0 Token Exchange (RFC 8693) obtained through a user-consented flow—and presents it to the application during each interaction.
That token is the agent’s passport. This leads to a comfortable assumption: if the call carries the user’s token, the application will enforce the user’s permissions, keeping us safe. In a true delegated flow, this holds up. The token names the user as its subject, and the app applies their specific permissions.
The problem? That is not how most autonomous and multi-user agents operate. Let’s hold that thought.
OAuth Scopes Were Never Built for This
The first crack appears in the scopes themselves. OAuth scopes lack a standardized vocabulary; every application invents its own scope strings and granularity (RFC 6749 leaves values entirely up to the application). There is no portable way to declare, “this token may call these specific tools for this specific agent.” Scopes were designed to gate an application's capabilities, not the tools exposed to an AI agent. While newer RFCs attempt to bridge this gap, implementation remains highly subjective. The result? Overly broad scopes that grant far more access than an agent needs.
The second crack is subtler: plain scopes describe capabilities, not resources. You can grant the ability to “run queries,” but you cannot specify “run queries against the Finance database, but not HR.” The OAuth ecosystem has standardized solutions for this, but they are barely deployed:
- Resource Indicators (RFC 8707, 2020): Binds a token’s audience to a specific resource server, ensuring a token minted for one server isn't valid at another.
- Rich Authorization Requests (RFC 9396, 2023): Enables tokens to carry structured JSON authorization details.
If implemented globally, these standards provide firm ground. But operationally, an unimplemented standard and a nonexistent one fail exactly the same way. (Notably, the Model Context Protocol (MCP) authorization spec now mandates RFC 8707 resource indicators, so momentum is shifting where MCP is adopted.)
The Part Everyone Underweights: The Human’s Real Permissions
Now consider the operational reality. Your security team declares an agent may use specific tools on specific resources. That’s good policy, but it’s an upper bound, not the ground truth. The true boundary is dictated by what the end user is actually allowed to do. If Alice cannot create a database in Snowflake, an agent acting for Alice must not be able to either—regardless of the agent’s onboarding policy.
Effective permissions are the strict intersection of three layers:
- Agent Allowances: What the security team permitted the agent to access (tools + resources).
- Token Scopes: What the application’s OAuth scope actually grants the token.
- User Entitlements: What the human behind the request is genuinely entitled to do in the app.
In a delegated, on-behalf-of flow, the application enforces that third layer because the token reflects the user's identity. But the moment an agent runs under its own identity—such as a service principal or shared agent credential, which is increasingly the norm for autonomous and multi-user agents—the application only sees the agent’s broad permissions.
The user’s individual ceiling completely vanishes from the provider’s view. A low-privilege human can now reach through a high-privilege agent to perform actions they could never execute from their own desk. The application won't catch this because, from its perspective, a privileged identity simply made a permitted call. This is the essence of the confused deputy problem.
Why This Lands at the Gateway
Where do you enforce this three-way intersection? Not in the OAuth scope—it can’t express tools or per-resource constraints in ways modern applications honor today. And not solely in the application, because in the critical shared-identity use case, the app is entirely blind to the human’s constraints.
That leaves the gateway layer. It is the single architectural point that sees the agent’s policy, the user’s identity, and every individual tool call simultaneously before it ever reaches the application.
To be precise, "the only place" is too strong of a claim for all scenarios. In a true delegated-token flow, the application still enforces the user's ceiling. The ideal posture is defense in depth: enforce policy at the gateway while letting the resource server validate the token audience (the exact direction MCP and RFC 8707 are pushing). However, the gateway remains the only place capable of enforcing all three constraints simultaneously, and it is the only layer that stays accurate when the agent runs under its own shared identity.
This is the same lesson as before, pushed one step further:
- Lesson 1: Tool-level allow/deny isn’t enough; you must govern resources.
- Lesson 2: Governing resources isn’t enough; you must govern them against the real-time permissions of the human in the loop.
The gateway is the single point capable of executing this across every deployment model, even when the target application has gone blind.
Conclusion
Cryptographic identity gets the agent to the door. Resource governance decides which rooms it can look at. The intersection with the user’s real permissions determines which rooms it may actually enter today, as this specific person.
At Andromeda, we are building agentic security on these exact principles, delivering a solution that extends our deep context of human and non-human identity security.
The Permission Gap: Why Your AI Agent is a Privilege Escalation Machine
In our last post, we argued that cryptographic identity gets an agent to the door, while application access management decides which rooms it can enter. Let’s follow that thread one room deeper. A critical question hides behind “which rooms,” and it’s the one most agent deployments get wrong by default.
When your security team onboards an agent, they define what it may do—which tools and resources it can access. That’s necessary, but it doesn't dictate what the agent can actually do. An agent's true capability is the intersection of what security allows and what the human behind the agent is permitted to do in the application. Miss that intersection, and you’ve built a privilege-escalation machine with a friendly chat interface. This failure mode has a name: the confused deputy problem, and it is currently the dominant concern in agent security.
How the Gateway Ends Up Holding the User’s Token
Let's walk through the mechanics. A human asks an agent to execute a task—say, working with data in Snowflake. The agent doesn’t talk to Snowflake directly; it routes through a gateway. To act on the user's behalf, the gateway acquires an OAuth token for that user—typically a delegated, on-behalf-of token via OAuth 2.0 Token Exchange (RFC 8693) obtained through a user-consented flow—and presents it to the application during each interaction.
That token is the agent’s passport. This leads to a comfortable assumption: if the call carries the user’s token, the application will enforce the user’s permissions, keeping us safe. In a true delegated flow, this holds up. The token names the user as its subject, and the app applies their specific permissions.
The problem? That is not how most autonomous and multi-user agents operate. Let’s hold that thought.
OAuth Scopes Were Never Built for This
The first crack appears in the scopes themselves. OAuth scopes lack a standardized vocabulary; every application invents its own scope strings and granularity (RFC 6749 leaves values entirely up to the application). There is no portable way to declare, “this token may call these specific tools for this specific agent.” Scopes were designed to gate an application's capabilities, not the tools exposed to an AI agent. While newer RFCs attempt to bridge this gap, implementation remains highly subjective. The result? Overly broad scopes that grant far more access than an agent needs.
The second crack is subtler: plain scopes describe capabilities, not resources. You can grant the ability to “run queries,” but you cannot specify “run queries against the Finance database, but not HR.” The OAuth ecosystem has standardized solutions for this, but they are barely deployed:
- Resource Indicators (RFC 8707, 2020): Binds a token’s audience to a specific resource server, ensuring a token minted for one server isn't valid at another.
- Rich Authorization Requests (RFC 9396, 2023): Enables tokens to carry structured JSON authorization details.
If implemented globally, these standards provide firm ground. But operationally, an unimplemented standard and a nonexistent one fail exactly the same way. (Notably, the Model Context Protocol (MCP) authorization spec now mandates RFC 8707 resource indicators, so momentum is shifting where MCP is adopted.)
The Part Everyone Underweights: The Human’s Real Permissions
Now consider the operational reality. Your security team declares an agent may use specific tools on specific resources. That’s good policy, but it’s an upper bound, not the ground truth. The true boundary is dictated by what the end user is actually allowed to do. If Alice cannot create a database in Snowflake, an agent acting for Alice must not be able to either—regardless of the agent’s onboarding policy.
Effective permissions are the strict intersection of three layers:
- Agent Allowances: What the security team permitted the agent to access (tools + resources).
- Token Scopes: What the application’s OAuth scope actually grants the token.
- User Entitlements: What the human behind the request is genuinely entitled to do in the app.
In a delegated, on-behalf-of flow, the application enforces that third layer because the token reflects the user's identity. But the moment an agent runs under its own identity—such as a service principal or shared agent credential, which is increasingly the norm for autonomous and multi-user agents—the application only sees the agent’s broad permissions.
The user’s individual ceiling completely vanishes from the provider’s view. A low-privilege human can now reach through a high-privilege agent to perform actions they could never execute from their own desk. The application won't catch this because, from its perspective, a privileged identity simply made a permitted call. This is the essence of the confused deputy problem.
Why This Lands at the Gateway
Where do you enforce this three-way intersection? Not in the OAuth scope—it can’t express tools or per-resource constraints in ways modern applications honor today. And not solely in the application, because in the critical shared-identity use case, the app is entirely blind to the human’s constraints.
That leaves the gateway layer. It is the single architectural point that sees the agent’s policy, the user’s identity, and every individual tool call simultaneously before it ever reaches the application.
To be precise, "the only place" is too strong of a claim for all scenarios. In a true delegated-token flow, the application still enforces the user's ceiling. The ideal posture is defense in depth: enforce policy at the gateway while letting the resource server validate the token audience (the exact direction MCP and RFC 8707 are pushing). However, the gateway remains the only place capable of enforcing all three constraints simultaneously, and it is the only layer that stays accurate when the agent runs under its own shared identity.
This is the same lesson as before, pushed one step further:
- Lesson 1: Tool-level allow/deny isn’t enough; you must govern resources.
- Lesson 2: Governing resources isn’t enough; you must govern them against the real-time permissions of the human in the loop.
The gateway is the single point capable of executing this across every deployment model, even when the target application has gone blind.
Conclusion
Cryptographic identity gets the agent to the door. Resource governance decides which rooms it can look at. The intersection with the user’s real permissions determines which rooms it may actually enter today, as this specific person.
At Andromeda, we are building agentic security on these exact principles, delivering a solution that extends our deep context of human and non-human identity security.