Agentic Apps Are Exposing the Next Identity Problem: Delegated Access, Not Just Login

The login screen is the wrong threat model

When an AI agent books a meeting, submits a pull request, or transfers funds on a user's behalf, the question is no longer whether the user authenticated. The question is whether the agent was authorized to perform that specific action, under what scope, for how long, and with what audit trail.

Standard OIDC and OAuth 2.0 flows answer the first question adequately. They were not designed to answer the rest. That gap is now a live engineering problem as agent deployments move from sandboxed demos into production workflows that touch real APIs, real data, and real money.

The open-source auth ecosystem is beginning to respond. Authorizer, a self-hosted authentication and authorization server on GitHub (github.com/authorizerdev/authorizer), has been described in project materials as targeting enterprise app and agent-era use cases. Its current documentation and maintenance state were not independently fetched for this article; it is cited as one signal among several that identity maintainers are treating agent delegation as a first-class engineering problem rather than an edge case, not as a verified category-defining product.

The four gaps standard auth leaves open

1. Scope is too coarse

OAuth 2.0 scopes were designed for discrete API surfaces: read:email, repo:write. Agentic workloads need narrower, context-sensitive authority — not "write to this repo" but "write only to branches prefixed agent/, only during this task session, and never merge to main."

The IETF's Rich Authorization Requests standard, RFC 9396, defines a structured authorization_details object for finer-grained OAuth requests. Identity teams evaluating agent frameworks should ask directly whether the agent token carries a RAR authorization_details object or just a broad scope string — most frameworks do not implement this today.

A RAR payload for a payment agent can specify the exact operation being requested — instructed amount, currency, creditor account — rather than simply asserting payments:write scope. Without that specificity, a compromised or misbehaving agent with a payments:write token can initiate any payment, not just the one the user intended.

2. Token lifetimes are calibrated for humans, not machines

Browser sessions tolerate long-lived tokens because there is a human who will notice anomalous behavior and who will eventually log out. Agents run unattended. A stolen access token with a 24-hour lifetime and no refresh rotation gives an attacker a full working day of unattended API access.

The LiteLLM supply-chain incident surfaced in open signals illustrates the structural risk: a master key compromise enabled attackers to steal GitHub tokens and hijack a CI/CD release pipeline. The attack surface was an unrotated, long-lived credential attached to an automated process — structurally identical to an agentic service account.

Mitigation implies three things that are underspecified in most agent deployments today:

• Short-lived access tokens (minutes to single-digit hours, not days)
• Refresh token rotation with immediate invalidation on reuse detection (RFC 6749 §10.4, reinforced in the OAuth Security BCP at RFC 9700)
• Per-task token issuance via OAuth 2.0 Token Exchange (RFC 8693), which allows an orchestrator to mint a narrowly scoped token for a sub-agent without passing its own credential downstream

3. Consent flows do not map to delegation chains

When a user consents to an app's OAuth scope, they are consenting to that app accessing their data. When that app spins up an agent that calls a sub-agent that calls a third-party tool, the user's original consent has been delegated across a chain they never explicitly reviewed.

Multi-agent architectures — orchestrators spawning specialist agents that invoke external APIs — are the dominant pattern in production agentic deployments. Each hop in that chain is a delegation event. Without an explicit consent model for delegation, the user's intent is the only thing that attenuates as the chain grows.

The OpenID Foundation's AuthZEN working group (openid.net/wg/authzen) is developing interoperability specs for authorization decisions that can traverse these chains. It is early work. In the interim, identity teams would be well served by a design rule: any agent that can spawn sub-agents or invoke third-party tools should carry a token issued specifically for that sub-task, not the parent task's token. Token Exchange (RFC 8693) is the standard mechanism for this pattern.

4. Audit logs do not record agent identity separately from user identity

Most SIEM and audit logging infrastructure records the OAuth client_id and the user's sub claim. In an agentic workflow, the client_id is the agent framework or orchestration layer, not the specific agent that took the action. When an agent books a meeting, deletes a file, or submits a form, the audit trail often records "the app acted on behalf of the user" — not which agent, which task, which prompt context, or which tool invocation produced that action.

This matters for compliance. The EU AI Act's high-risk system obligations, which took effect for covered systems earlier in 2026, are widely reported to require deployers to maintain logs sufficient to support post-incident review — with some interpretations citing retention periods around six months for high-risk AI systems. A direct citation to the legal text or a European Commission guidance document should be consulted for authoritative detail; this article treats that reading as a reported interpretation, not a legal conclusion. What is not in dispute is that coarse-grained OAuth audit logs are unlikely to satisfy any serious post-incident review of an agentic workflow.

Practical mitigation: inject a structured act claim (defined in RFC 8693 §4.1) into every agent-issued token. The act claim encodes the delegation chain — which principal is acting on behalf of which user — and survives into downstream API logs. A token carrying nested act claims tells every downstream API exactly what chain of agents produced the request. Without it, incident response after an agentic system misbehaves reduces to reading LLM traces and hoping they were preserved.

What passkeys change (and do not change)

Passkeys solve the phishing problem for human authentication. They do not solve the delegation problem for agents. An agent does not authenticate with a passkey — it authenticates with a client credential, a service account key, or a derived token. The FIDO Alliance's Passkey Index and associated enterprise adoption work focuses on human-in-the-browser flows.

The relevant intersection is step-up authentication: when an agent attempts a high-value action (large financial transaction, privileged configuration change, irreversible deletion), the system should interrupt the agentic flow and require a fresh, phishing-resistant human authentication before proceeding. That step-up challenge must be passkey-capable to be resistant to real-time phishing. The OAuth 2.0 acr_values parameter and the OIDC max_age claim are the standard mechanisms for signaling that a step-up is required; most agent frameworks do not implement them today.

What identity teams should verify now

The standards infrastructure exists. What is missing is implementation discipline inside agent frameworks and enforcement by the identity teams reviewing them. The first practical step is a scope audit: inventory every OAuth client your agent infrastructure uses, map the scopes it carries, and identify where a single compromised or misbehaving agent could act beyond the user's actual intent.

Review note: The Authorizer GitHub repo was available as a lead but its current documentation scope and maintenance state were not fetched. Claims about its feature set are attributed to the research brief's characterization only. The IETF RFC links above point to published standards verifiable at rfc-editor.org. The LiteLLM incident is cited from open signals context; a separate investigation into that incident is warranted. The EU AI Act logging interpretation should be verified against the official legal text at eur-lex.europa.eu before reliance in a compliance context.