Notifications
Clear all
Topic starter
22/06/2026 10:17 am
TL;DR: AI agents should not inherit a user’s full permission set, because delegated access must be bounded by both the user’s current rights and the agent’s configured scope, according to WorkOS. The intersection rule is the practical control that prevents excessive agency, confused deputy abuse, and avoidable production damage.
NHIMG editorial — based on content published by WorkOS: Delegated access for AI agents: the intersection rule explained
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
WorkOS' full article covers the operational detail this post intentionally leaves for the source:
- The full OAuth 2.1 and RFC 8693 token exchange flow, including how the user, agent, and resource server fit together.
- Concrete examples of client credentials, authorization code with PKCE, and per-agent M2M credential patterns.
- The MCP authorization model and why scoped tokens matter for multi-tool agent environments.
- Implementation details for audit logging and resource binding that support incident investigations.
👉 Read WorkOS' guide to delegated access and the intersection rule for AI agents →
AI agent delegated access and the intersection rule?
Explore further
22/06/2026 11:07 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Delegated access for AI agents: why the intersection rule matters
