AI agents need an authenticated user identity before they can apply user-specific authorization rules.
2
Token Vault lets agents exchange user tokens for upstream API tokens and handles refresh-token storage and access-token renewal.
3
Asynchronous authorization lets an agent pause a risky operation, request human approval, and resume with a token containing the approved transaction details.
Summary
Patrick Riley and Carlos Galan explain how Auth0 and Okta features can give AI agents identity, delegated access, and human approval flows. They model an agent as a client and external services as APIs or resource servers. The talk covers four needs: an agent must know the user, call APIs on the user's behalf, request confirmation for risky actions, and receive fine-grained access. The workshop builds a Next.js trading chatbot, connects it to an upstream identity provider, uses Token Vault to access a user's portfolio, and exposes the same tools through an MCP server. The speakers also demonstrate dynamic client registration and protected resource metadata for MCP. A stock order uses asynchronous authorization through Guardian, with the symbol, quantity, and price shown to the user before execution. They are direct about the newness of the MCP and DCR integrations, which had shipped only recently and were still being tested with several clients.
Agents need a user identity before authorization can work
Carlos Galan says an agent cannot apply authentication, authorization, or restrictions if it does not know who the user is. The user may be an employee, owner, or administrator, and the relevant subject is a human identity. The agent also needs its own permissions, so the design covers both who is using the agent and what the agent may access. In an enterprise, an employee can act for a company, which means the company must control what the agent does on that employee's behalf. This identity relationship is the starting point for the rest of the security flow.
Agents need delegated API access with fine-grained scope
The speakers describe agents that access services for a user, then request confirmation when an action becomes risky. Access should be limited to particular resources, documents, collections, or API operations. Their model treats the agent as a client and external services as OAuth resource servers. Scopes come from the upstream service and describe the access token it requires. The local tenant can model its own scopes, but the connection must translate them to the upstream scopes. A scope that is not part of the connection cannot end up in the access token, even if an agent tries to request it through prompt injection.
Async authorization lets an agent pause until a person approves
Carlos introduces async authorization as a protocol for an autonomous agent to contact a user when an operation needs approval. The example is an agent making a purchase or placing a stock order. A simple SDK call starts the authorization request, the user receives structured transaction details, and approval returns to the agent as an access token. The token contains the exact details the user approved. In the trading example, the request includes the stock symbol, quantity, and price. The order tool waits for the user's response before it runs, so the agent does not place a risky order without supervision.
Token Vault manages upstream tokens for long-running agents
Patrick Riley describes Token Vault as a way to persist upstream refresh tokens and exchange tokens on behalf of users. An agent can present an access token or an application's refresh token and request scopes for an upstream service such as Slack or Facebook. Token Vault stores the refresh token, keeps access tokens until they expire, and obtains a new access token when the agent needs the service. This avoids passing a user's short-lived token directly to the agent. Riley says the flow is adapted to different application shapes, including single-page apps, native apps, traditional web apps, LangGraph deployments, and asynchronous agents.
MCP servers can be secured as clients and resource servers
The workshop models an MCP server as a client that can call upstream APIs. An agent can call the MCP server, which then calls a third-party service. The speakers add protected resource metadata, scope verification middleware, JWT verification, and dynamic client registration. They also introduce a custom API client and linked clients so an MCP server can have its own client identity and credentials. Shared TypeScript tools can run directly in the agent or move to the MCP server. This lets the same portfolio and trading capabilities be exposed through different clients while keeping the authorization policy in place.
The workshop builds identity into a Next.js trading agent
Patrick builds a Next.js application with an embedded chatbot, local tools, an upstream identity provider, and access to a stock trading API. The initial chatbot can answer ordinary generative AI questions, but it does not know the user or trading data. The team first adds a stock-price tool, then adds login and a connection to the upstream application. After login, the agent knows the user's identity, but it still cannot access the user's portfolio. A connected-account step requests additional scopes and establishes the relationship between the user, the agent, and the upstream service. The portfolio tool then obtains an upstream token through the SDK.
Agent identity supports audit and policy decisions
In a discussion about autonomous task runners, Carlos explains that an agent should not simply receive a user's access token. The token will expire, and repeatedly asking the user to log in would limit how autonomous the agent can be. With an agent identity, the access token can identify both the user and the client acting for that user. Carlos points to the authorizing party claim as the place to distinguish the agent from the human subject. An application can then tell which agent acted on behalf of which user and apply its own policies. The user's connected accounts can be established once and reused until the upstream refresh-token policy requires reconnection.
The speakers describe their MCP support and dynamic client registration as recent releases and preview or beta work. The flow uses a protected resource metadata endpoint to advertise supported scopes, an authorization server, registration of a new client, and the authorization code flow with PKCE. They test the deployment with MCP Inspector, Claude, and other clients. Claude supports authentication, but the speakers mention an open issue around specifying scopes. They also show that the same deployed MCP tools can be reached from another client after authentication. The workshop code was available in a final-state branch, with a warning that the app could change as development continued.
"If the agent doesn't know who I am, it can never apply any security or any restriction or any authorization."05:14
Who should watch
You are building an agent that needs to use a user's Slack, calendar, trading, or other protected API data without repeatedly asking the user to log in.
Your agent can run asynchronously and needs a human approval step before purchases, stock orders, or other sensitive operations.
You are adding MCP tools and need a concrete OAuth design with protected resource metadata, scopes, dynamic client registration, and separate agent identity.
