Agents need user-bound identity and short-lived, narrowly scoped tokens instead of shared service credentials.
2
Retrieval systems should enforce fine-grained authorization before data reaches the model.
3
CIBA lets an agent request user approval for sensitive actions when there is no user interface.
Summary
Bobby Tiernay and Kam Sween describe identity and authorization patterns for agents that call APIs, retrieve private data, and act for users. They contrast shared API keys with short-lived tokens issued for one user and one API through backend token exchange. The talk also places authorization before retrieval in RAG systems, so an LLM does not decide which data a user may see. For actions that need approval, Client-Initiated Backchannel Authentication, or CIBA, sends a request to the authorization server and notifies the user on a trusted device. Kam demonstrates these ideas in a TypeScript trading assistant that uses OIDC, a token vault, and CIBA before a simulated stock purchase. The speakers are direct about the remaining implementation work, while arguing that open standards reduce the need for custom identity code.
When agents call APIs, start workflows, and change systems, their actions need to happen in the context of a real user. A shared API key from an environment variable may work across users, environments, and services, but it makes auditing difficult and makes rotation manual. The proposed flow has the agent ask a backend for help. The backend retrieves a credential from a vault and uses token exchange to mint a short-lived token for one user and one API. The token is handed to the agent for use and then does not remain there. This creates a record of who acted and avoids making the agent carry long-lived secrets.
Excessive agency comes from access without guardrails
As agents move beyond chat, they call APIs, pull data, use tokens, and touch credentials. Bobby describes this as the risk OWASP calls excessive agency: an agent has too much access without enough control. Broad scopes and poor visibility make it hard to understand what happened until a security incident occurs. Sensitive data exposure often has the same cause. If an agent reaches data it should not have, nobody enforced the boundary. Access needs to be scoped, monitored, and tied to a real user so that actions can be traced and limited.
Delegation standards prevent the confused deputy problem
An agent that has access but does not know whom it represents can end up running as a service account. Bobby connects this to the confused deputy problem. He recommends anchoring the agent to a user through OAuth 2.1, Rich Authorization Requests, and token exchange. The flow should preserve upstream identity and refresh tokens correctly. The backend, rather than the agent, handles credentials and issues a short-lived token for the requested user and API. This uses established identity flows instead of custom credential handling.
RAG authorization belongs before retrieval reaches the model
A retrieval-augmented generation system decides which information the model sees. Users should not automatically receive the same data context, so authorization must be fine grained. Bobby says the LLM should not decide access inside its own generation process. Policy enforcement should happen at the retrieval layer, before sensitive data enters the model context. This limits data exposure and gives the application a clear place to check which records or documents an agent may retrieve for a particular user.
CIBA provides approval when an agent has no screen
Client-Initiated Backchannel Authentication, or CIBA, lets an agent ask an authorization server to obtain approval without opening a user-facing browser flow. The authorization server contacts the user on a trusted device, such as through a push notification. The user can approve, deny, or request more information. This fits background agents and other workflows without a screen. In the demo, the notification identifies the agent's requested action, including a simulated purchase of 10 shares, so the user can decide whether to continue.
Remote MCP tools need request identity and scoped tokens
MCP began as local standard input and output on a laptop, but the speakers describe it becoming part of remote, distributed systems. Once an MCP server is on the network, security has to be built into the request flow. Their pattern uses an OAuth 2.1 browser sign-in, with the MCP server handling token minting. The agent receives a token that is scoped and bound up front, while the client does not expose third-party credentials. Shared servers need reliable information about who made each request and what action they are taking.
The demo combines user context, a token vault, and approval
Kam's TypeScript command-line application models a local AI trading assistant that calls a broker service. The user asks the agent to buy stock, the LLM selects a buy-stock tool, and middleware identifies the user and obtains tokens on that user's behalf. A token vault keeps client secrets out of the code. A CIBA wrapper intercepts the sensitive tool call and pauses the application with a blocking callback until approval arrives. Kam notes that an asynchronous or polling flow could replace the blocking version in a more complete application.
Open standards still leave integration work for developers
The speakers say OAuth, OIDC, CIBA, Rich Authorization Requests, token exchange, token vaults, and fine-grained authorization are available as standards or platform components. Standards avoid repeating the identity design from scratch, but developers still have to assemble many building blocks. Auth0 and other platforms are trying to package these pieces into a simpler developer experience. Bobby also mentions OpenFGA as an option for fine-grained authorization and says he is involved in discussions around the open MCP specification.
"Standards are great. It means you're not reinventing things over and over again, but there's still a lot of building blocks that you would have to build."17:08
Who should watch
You are building an agent that calls APIs or changes systems and need each action tied to the right user.
Your RAG application handles private company or user data and you need authorization to happen before retrieval.
You need human approval for background-agent actions without forcing the user through a browser interface.
