Delegated access for AI agents: why the intersection rule matters

At a glance

What this is: This article explains why AI agents need delegated access governed by the intersection rule, not a simple run-as-user model.

Why it matters: It matters because IAM, PAM, and NHI teams must scope agent actions independently of user permissions if they want to prevent excessive agency and confused deputy failures.

👉 Read WorkOS' guide to delegated access and the intersection rule for AI agents

Context

AI agent delegated access is the problem of deciding what software can do on behalf of a user without giving it the user’s entire permission set. The article argues that the run-as-user pattern is too broad because it collapses user authority and agent authority into one, which creates an over-permissioned identity boundary for agentic systems.

For IAM and NHI programmes, the key issue is not whether an agent can authenticate, but whether its effective privilege is constrained at the moment of action. That matters across user-delegated workflows, service-account-backed automation, and MCP-connected tool access because the control failure is the same: software inherits more authority than its task requires.

Key questions

Q: How should security teams scope AI agent access when the user has broad permissions?

A: Security teams should scope AI agent access as the intersection of the agent’s configured role and the user’s current permissions. That means the agent can only perform actions both sides allow, with resource-specific tokens, explicit audience binding, and real-time revalidation on each tool call. This prevents a user’s full access from becoming the agent’s default power.

Q: Why do delegated AI agents create confused deputy risk?

A: Delegated AI agents create confused deputy risk when they are trusted to act on behalf of a user but can be tricked into using that authority for a different purpose. If the agent inherits broad permissions, prompt injection or content abuse can redirect legitimate access into an unintended action. Narrow agent scope and per-call authorization reduce that risk.

Q: What breaks when agent permissions are evaluated only at login?

A: When permissions are evaluated only at login, revocation, demotion, or offboarding may not take effect until the session ends. An agent can keep acting with stale authority even after the human user’s access has changed. That creates a lifecycle gap that undermines least privilege and weakens incident containment.

Q: Who is accountable when an AI agent takes an unsafe action on a user’s behalf?

A: Accountability must be shared across the person who invoked the agent, the team that provisioned the agent’s scope, and the platform that enforced downstream authorization. If any one of those layers collapses into a broad run-as-user model, the audit trail becomes ambiguous. Clear agent identity, user identity, and resource-level logs are essential.

Technical breakdown

Why run-as-user breaks delegated access for AI agents

The run-as-user model forwards the user’s token or equivalent authority to the agent, so the software can do everything the person can do. That is convenient, but it erases the distinction between human intent and machine execution. Once the agent can interpret prompts at runtime, a malicious instruction inside content can redirect legitimate authority into an unsafe action. In identity terms, the agent becomes a deputy with no independent scope. The right model separates subject identity, acting identity, and downstream resource enforcement so each tool call is evaluated against both the user and the agent role.

Practical implication: do not let an agent inherit blanket user authority when the task only needs a narrow action scope.

How token exchange and audience binding enforce the intersection rule

RFC 8693 token exchange is the mechanism that turns user authority into a scoped downstream token instead of forwarding the original session token. The token can carry the user as subject, the agent as actor, and a resource-specific audience, which forces authorization to happen at the API boundary. When paired with resource indicators, the token is valid only for the intended service, not for every connected tool. That is how the intersection rule is enforced cryptographically rather than informally. The outcome is a downscoped permission set that reflects both the user’s current rights and the agent’s configured role.

Practical implication: issue exchanged, resource-bound tokens for each downstream call instead of reusing a broad session credential.

Why real-time permission checks matter more than invocation-time approval

If permissions are cached when the agent starts, the system can keep acting after a user has been revoked, demoted, or offboarded. That creates an access lifetime mismatch between the moment of approval and the moment of execution. Real-time checks close that gap by re-evaluating the user’s status at each tool call. This is especially important for long-running workflows, where the risk is not just excess access but stale access. In practice, just-in-time issuance and short-lived tokens make the effective permission set change as quickly as the underlying identity changes.

Practical implication: recheck user and agent permissions on every tool call, not only when the agent is invoked.

Threat narrative

Attacker objective: The attacker’s objective is to make the agent misuse legitimate authority to expose data, modify resources, or execute harmful actions on the victim’s behalf.

1. Entry occurs when an AI agent is given delegated access through the user’s authenticated session or a broad service account.
2. Escalation happens when the agent inherits permissions that exceed the task scope, allowing prompt injection or confused deputy abuse to redirect authority.
3. Impact follows when the agent performs destructive or data-exfiltrating actions that the user or workflow did not explicitly intend.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The “run as the user” assumption is the wrong baseline for agent governance. That model was built for human-paced access where the person’s judgment and the software’s execution are aligned. It fails once the actor is an AI agent because the agent can re-interpret instructions at runtime and act with machine speed. The implication is that delegated access must be treated as a distinct identity problem, not a convenience layer on top of human IAM.

Intersection-based privilege is the correct control boundary for AI agents. The agent’s effective authority must be the overlap between its configured role and the user’s current permissions. That is a stronger governance model than user inheritance because it makes task scope explicit and auditable. It also aligns with OWASP Agentic AI Top 10 thinking on excessive agency and prompt injection, where the failure is not only bad input but too much authority attached to the actor.

Delegated access without its own agent identity creates confused deputy risk by design. When the agent acts through a generic user token or an overbroad service account, the system cannot distinguish who requested the action from what the software was allowed to do. That is a governance failure, not just an implementation choice. The practitioner conclusion is that agent identity, user identity, and downstream resource identity all need separate enforcement points.

Real-time authorization is now a lifecycle requirement, not an optimisation. Permission state changes during the life of a session, and an agent that does not re-evaluate access at call time can outlive the user’s current entitlement. That breaks revocation, offboarding, and least-privilege assumptions across NHI and IAM programmes. Practitioners should treat token freshness and access revalidation as core governance conditions, not optional hardening.

Named concept: intersection privilege drift. The article describes a failure mode where the effective scope of an agent quietly expands or persists beyond what the task requires because the user’s authority is treated as sufficient. That drift matters because it turns routine delegated work into a broad trust channel. The practitioner conclusion is to govern agent scope as a moving intersection, not a static grant.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same research.
• For the broader threat model, OWASP Agentic AI Top 10 is the natural next reference for teams formalising agent scope and tool governance.

What this signals

Intersection privilege drift: the operational risk is not only overbroad initial provisioning, but the quiet expansion of what an agent can do relative to the task it was asked to perform. With 80% of organisations already reporting agent actions beyond intended scope, the programme issue is no longer theoretical. Teams should move from static access grants to per-call scope checks and token freshness controls.

This pattern will increasingly sit at the boundary of IAM, PAM, and NHI governance, because the same control failure can present as a user access problem, a workload identity problem, or an agent policy problem. Programmes that already use least privilege language need to prove that the enforcement point actually follows the actor through the full delegation chain.

For practitioners

• Separate the agent identity from the user identity Register each agent as its own OAuth client or equivalent principal so its role can be scoped independently of the human who invokes it.
• Exchange tokens instead of forwarding them Use RFC 8693 token exchange to mint a scoped downstream token for each tool call, bound to the resource server and the current user permissions.
• Re-evaluate access at every tool call Avoid caching user permissions at invocation time, and force fresh authorization checks so revocation, demotion, or offboarding takes effect immediately.
• Limit the agent role below the user ceiling Define the agent’s own allowed actions as a narrower subset than the human operator’s entitlements, especially for delete, export, admin, and external-call actions.

Key takeaways

• AI agent delegated access fails when the software inherits the user’s full authority instead of a tightly bounded task scope.
• The strongest control model is the intersection of agent role and current user permissions, enforced through token exchange and real-time checks.
• If teams do not separate agent identity from user identity, they will keep creating confused deputy conditions that are hard to audit and easy to abuse.

Key terms

• Delegated Access: A model where software acts on behalf of a user but does not automatically inherit every permission that user holds. The downstream system should see a scoped, attributable request that is limited to the task and the current authorization state, not a blanket replay of the user’s authority.
• 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.
• Confused Deputy: A failure mode where a system with legitimate authority is tricked into using that authority for the wrong purpose. In agentic systems, the danger appears when prompts, content, or workflows redirect an otherwise valid delegated action into data access or modification the operator did not intend.

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 identity security programme, it is worth exploring.

This post draws on content published by WorkOS: Delegated access for AI agents: the intersection rule explained. Read the original.