Identity for AI Agents - Patrick Riley & Carlos Galan, Auth0

Auth0’s vision, “to free everyone to safely use any technology,” which predates the current AI era, provides the foundation for their approach to securing AI agents. The rise of Large Language Models (LLMs) introduces new challenges and threats, as highlighted by the updated OWASP LLM Top 10, necessitating new solutions for identity and access management.

A Four-Pillar Model for AI Agent Identity

A conceptual model for thinking about AI agent security is proposed, based on four key pillars that cover various agent modalities, from interactive chatbots to fully autonomous systems:

1. AI needs to know who I am: An agent must be aware of the user’s identity (the “subject”) to apply any security, permissions, or authorization. Without this, the user is an anonymous actor.
2. AI needs to call APIs on my behalf: Agents are not standalone; they must consume other resources and call external APIs to perform tasks for the user.
3. AI can request my confirmation: For high-risk operations, such as financial transactions, an agent must have a mechanism to request explicit, real-time approval from the user.
4. AI access should be fine-grained: Users must have granular control over exactly which resources, documents, or collections an agent is permitted to access.

In an enterprise context, Okta manages the employee’s identity, while Auth0 provides the specific features and capabilities to implement this four-pillar model for the agents acting on the employee’s behalf.

Core Features for Securing AI Agents

A recent product release introduces several core features designed to address these pillars.

Token Vault: Delegated Access to Upstream APIs

To enable agents to call APIs on a user’s behalf, the Token Vault provides a new mechanism for securely persisting and managing refresh tokens for upstream resources like Google Calendar, Slack, or other third-party APIs.

• Token Exchange: It facilitates a token exchange flow where an agent can use its own access or refresh token to request a token for an upstream service with specific scopes.
• Lifecycle Management: Auth0 handles the complexities of storing refresh tokens, managing their lifetimes, and using them to issue new access tokens, simplifying the SDK experience and keeping the agent’s connection to resources alive and secure.
• Flexible Flows: The implementation can vary based on the application architecture. For instance, a single-page app might use a short-lived access token, whereas a traditional web app with a secure backend can use a longer-lived refresh token.

Asynchronous Authorization: User Consent for Risky Operations

For scenarios requiring user confirmation, Auth0 has implemented Asynchronous Authorization, which is built on the Client-Initiated Backchannel Authentication (CIBA) protocol. This allows a long-running or autonomous agent to pause its operation and request user approval.

The flow works as follows:

1. The agent initiates an authorization request when it needs to perform a risky action (e.g., “place a stock order”).
2. This triggers a notification to the user on an out-of-band device, such as a push notification from the Auth0 Guardian MFA application.
3. The notification contains structured, rich details about the transaction (e.g., stock symbol, quantity, price).
4. The user reviews and approves the request.
5. Upon approval, the agent receives an access token embedded with the exact details of the approved transaction, which it can then use to securely complete the operation.

MCP Servers and Dynamic Client Registration (DCR)

The framework models agents and Machine-Readable Credential Profile (MCP) servers as OAuth clients. This allows for a secure, chained architecture where an agent (client) communicates with an MCP server (also a client), which in turn calls upstream APIs.

• Dynamic Client Registration (DCR): The system supports DCR, allowing third-party tools and platforms (like Claude or MCP Inspector) to dynamically register themselves as clients and connect to the MCP server.
• Metadata Discovery: The MCP server exposes a .well-known/protected-resource-metadata endpoint, which advertises its supported scopes and capabilities, enabling automated and secure integration.

This approach allows developers to build secure, shareable tools that can be exposed via an MCP server and consumed by various agents and platforms, all while enforcing consistent authentication and authorization policies.

• Tags:
• AI Agents
• Security
• MCP
• OAuth
• Identity Management
• Access Management
• Okta
• Auth0
• CIBA