Identity Management for Agentic AI [pdf] (2025)

What it claims

The paper's practical dividing line is this: existing OAuth 2.1 works for agents within a single trust domain with synchronous operation. Examples are an enterprise agent calling internal tools, or a consumer reaching their own services through an AI tool. It "may fall short" in four cases:

• cross-domain access
• highly autonomous operation
• asynchronous operation
• acting for several human users at once

For consumer agents connecting to third-party services such as email, social media or financial data, the standard OAuth 2.1 user-consent flow is named as the primary delegation mechanism. For enterprises, the recommendation is to conform agents to interoperable profiles of existing standards (IPSIE) rather than adopt vendor-specific agent identity systems. The paper warns that proprietary systems would force one-off integrations and multiply security models.

Two further open problems are not in the catalog summary:

• No automated verification of trustworthy autonomy. Scaling past human-in-the-loop needs programmatic checks that an agent's actions stay within its goals and constraints.
• Hybrid agents. An agent may switch between acting on its own (needing its own credentials, permissions and audit trail) and acting on behalf of a user.

How it works

The paper frames an agent as an OAuth client workload, synchronous or asynchronous with the user. The resource server must identify the agent, the user, or both. It then applies existing OAuth and OpenID Connect practice rather than inventing new primitives.

It argues agents need new authorization models because of how they take instructions. Users give agents unstructured, multimodal input, such as a scanned invoice plus a voice command, or a forwarded email thread. Clicks and form submissions carry explicit, auditable consent signals; these inputs do not. The agent itself has to infer the scope of delegated authority.

It also notes that MCP's initial design included no authentication.

The table of contents lists sections the fetched text does not reach:

• Dynamic Client Registration
• asynchronous authorization
• closing the auditability gap
• guardrails
• registries for dynamic tool connection
• an "economic layer" covering identity, payments and financial transactions
• IAM as a safety system for cyber-physical agents

Limits

• This is a position and agenda paper. It has no implementation, benchmark or reference code.
• The fetched text stops in section 2.2, so none of the concrete section-2 guidance (DCR, async auth, audit) could be checked here.
• Section 1.1 puts computer-use and web-search agents out of scope, yet the executive summary lists browser and computer-use agents as a key challenge. Expect that problem to be named but not worked through.
• The focus is foundation-model agents such as ChatGPT, Claude, Gemini and LLaMa-based systems, not other ML automation.
• WorkOS supported the work, contributing the author's time.