Delegated access for AI agents: why the intersection rule matters

At a glance

What this is: This article explains why AI agent access must be the intersection of user permissions and agent scope, not a direct inheritance of the user’s full rights.

Why it matters: IAM teams need this model because agentic systems can amplify human privilege, turning routine delegated access into over-authorised action paths unless scope is constrained at issuance and at each tool call.

By the numbers:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.

Context

AI agent delegated access is a governance problem, not just an integration detail. The article argues that when an agent acts on a user’s behalf, the effective permissions must be constrained by both the user’s current rights and the agent’s own configured scope.

The central failure mode is the old “run as the user” pattern, where an agent inherits a user token and can execute every action that user can perform. That model becomes unsafe once natural-language instructions, runtime reasoning, and tool access combine inside production workflows.

The article’s answer is the intersection rule: calculate effective authority from the overlap between user permissions and agent permissions at the moment of each tool call. For identity teams, that moves agent governance from broad delegation to explicit, auditable scoping.

Key questions

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: Why do AI agents need downscoped tokens instead of forwarded session tokens?

A: Forwarded session tokens let downstream services see the human’s full authority, which defeats delegated access control. Downscoped tokens preserve the user identity while restricting the call to the exact resource and permission set the agent is authorised to use. That is what makes the intersection rule enforceable in practice.

Q: How can security teams prevent confused deputy risk in agentic workflows?

A: Separate the agent’s identity from the user’s identity, constrain the agent’s own configured scope, and require every tool call to carry a token that reflects the overlap of both. That prevents a prompt, document, or malicious instruction from expanding the agent beyond its intended role.

Q: What should teams do when user permissions change during an active agent task?

A: Treat permission checks as real-time, not session-scoped. If a user is demoted, revoked, or offboarded while an agent is still working, the next token exchange must reflect the new state immediately. Cached authorisation creates stale access and defeats the purpose of delegated control.

Technical breakdown

Why “run as the user” creates excessive agency

The default pattern for many agent integrations is to attach the user’s existing token to the agent and let it call downstream systems with that identity. That collapses two different questions into one: what the human may do, and what software may do on the human’s behalf. Once an agent can interpret instructions at runtime, the gap between those two questions becomes a security boundary. In practice, a user who can delete records or access admin functions may be trusted with those actions, but the agent should not inherit that trust automatically. The result is excessive agency, where the system can take actions broader than the task requires.

Practical implication: Do not treat user authentication as sufficient authorisation for agent tool use.

How the intersection rule works in delegated access

The intersection rule sets effective authorisation as the overlap between two independently defined sets of permissions: the agent’s provisioned scope and the user’s current rights. If the user can delete records but the agent is only allowed to read and update tickets, deletion is excluded. If the agent can call a CRM but the user has been revoked, the next decision point should fail. This is not a theoretical nuance. It is the difference between broad inheritance and bounded delegation, and it is the reason token exchange and audience-bound tokens matter in agent systems.

Practical implication: Enforce downscoped tokens that reflect both the user and the agent at every call.

Why token exchange and real-time checks matter for MCP

In MCP-based systems, each tool invocation is a fresh authorisation event, not a one-time onboarding decision. RFC 8693 token exchange allows a downstream token to carry the user identity, the agent context, and the exact scope and audience for that call. That design prevents blanket tokens from travelling across tools and resource servers. Real-time evaluation also matters because user access can change mid-task. If an agent caches permissions from session start, revocation, demotion, or offboarding will not take effect until the task ends, which is too late for meaningful control.

Practical implication: Evaluate permissions at invocation time and bind each token to a specific resource server.

Threat narrative

Attacker objective: The attacker wants the agent to misuse legitimate authority and carry out actions that exceed the intended task scope.

1. Entry occurs when a user invokes an agent with a broad token or inherited session context that is not separately scoped for tool use.
2. Escalation happens when the agent is allowed to act beyond the task boundary, so a prompt or instruction can drive it into privileged operations the user did not need for the request.
3. Impact follows when the agent executes destructive or sensitive actions, such as deleting production resources or exposing data, within the limits of the overbroad authorisation model.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The intersection rule is a governance control, not an implementation preference: it is the point at which agent access stops being a proxy for human access and becomes an independently governed identity decision. The article is right to separate user rights from agent rights because the security question changes once software can reason over tasks at runtime. Practitioners should treat that split as a baseline assumption for agent authorisation design.

“Run as the user” is an obsolete trust model for agentic systems: it assumes the user’s full permission set is a safe ceiling for software action, which is precisely the wrong premise when tool use, prompt interpretation, and downstream execution are all in play. That premise fails even more sharply when the agent can follow embedded instructions from content it processes. The control problem is not just overreach, but unreviewed transposition of human privilege into machine action.

Ephemeral authority must be defined by intersection, not inheritance: the article’s token exchange pattern shows that effective access can and should be recomputed at each call. That aligns with NHI governance realities where standing permissions and cached assumptions produce the widest blast radius. The practitioner conclusion is simple: do not let an agent carry a user’s security posture by default.

Identity blast radius becomes the decisive metric for agent design: once an agent can access multiple tools, the real question is how much damage a single scoped request can authorise. The article exposes a named concept worth carrying forward: intersection-bound delegation, where the agent’s role and the user’s rights must both be true before any action is allowed. Teams should build authorisation models around that overlap rather than around convenience.

Agent authorisation now sits at the boundary of IAM, NHI, and workflow security: the same pattern that prevents a confused deputy also prevents accidental over-delegation in MCP-connected environments. That makes agent access governance a lifecycle problem, not a one-off integration setting. Security teams should expect the control plane to enforce scope continuously, because runtime reasoning turns static permissions into active risk.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Zero Trust for AI Agents

What this signals

Intersection-bound delegation: agent access should be computed as the overlap between user rights and agent scope, not as a copy of the user’s full permission set. That shifts control from broad inheritance to explicit authorisation decisions at each tool call, which is where agentic risk actually appears.

Agentic workflows make stale permissions more dangerous than in ordinary SaaS access because the system can act between review cycles. Real-time checks, scoped tokens, and resource-specific audiences are the practical signals that an IAM programme has adapted to machine action rather than just human login.

MCP-connected agents increase the need for callable scope boundaries because each tool becomes a potential overreach point. Identity teams should expect policy to move closer to issuance, with audit logs proving why a given action was allowed or denied.

For practitioners

• Define a separate agent principal Register each agent with its own client ID and provision a role that reflects the smallest task scope it must perform. Do not reuse the invoking user’s identity as the agent’s identity boundary.
• Downscope every tool call with token exchange Use RFC 8693 token exchange so downstream services receive a token that reflects both the user and the agent, plus a resource-specific audience. Never forward the original session token to tools.
• Recompute access at each invocation Evaluate the user’s current permissions at the moment of the tool call, not at session start. If access changes mid-task, the next exchange must reflect the change immediately.
• Constrain MCP tool permissions by function Map each agent capability to an explicit tool and action set so runtime prompts cannot expand scope into unrelated systems such as billing, admin, or production deletion.
• Log the full authorisation context Record the user identity, agent identity, tool called, resource audience, and resulting scope for every sensitive action so investigations can reconstruct why the action was allowed.

Key takeaways

• AI agent access becomes risky when the user’s full permissions are treated as the agent’s permissions, because that turns routine delegation into excessive agency.
• The article’s core control is the intersection rule, which limits an agent to the overlap of its own configured scope and the user’s current rights.
• For identity teams, the practical shift is from inherited authority to scoped, auditable, real-time authorisation at every tool call.

Key terms

• Intersection Rule: A control principle that limits an agent’s effective authority to the overlap between its own configured scope and the user’s current permissions. It prevents the user’s maximum access from becoming the agent’s default power and creates a smaller, auditable permission set for each tool call.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.