# How to Secure Agents using OAuth

Jared Hanson, Keycard | AI Engineer World's Fair 2025 | 18:59

Source: https://www.youtube.com/watch?v=blmAkayzE8M
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/how-to-secure-agents-using-oauth
Published: 2025-07-30
Tags: agents, mcp, privacy, security

## TL;DR
- OAuth replaces long-lived, broadly scoped API keys with tokens that can be issued, checked, rotated, and limited by an authorization server.
- MCP's early authorization design incorrectly combined the resource server and authorization server roles, while the newer draft separates them and leaves MCP servers mainly responsible for token verification.
- Securing agents will require more than user delegation, including agent identity, agent-to-agent authorization, transaction-level permissions, chain of custody, and authorization for asynchronous interactions.

## Summary
Jared Hanson explains why agents should not receive long-lived API keys copied into configuration files and environment variables. He introduces OAuth's three roles, client, resource server, and authorization server, then applies that model to MCP. In his account, MCP initially had no authorization, and its first OAuth draft combined the MCP server's resource-server and authorization-server responsibilities. The newer draft separates those roles, allowing MCP servers to verify incoming tokens while an authorization server handles the rest. Hanson then describes the work still needed for agent systems. User-delegated authorization code flows cover only one case. Agents also need client credentials for acting independently, ways to establish agent identity, controls over which LLM receives data, transaction-specific permissions, token exchange across service chains, and ways to request more access when users are away. The talk is a practical map of OAuth problems that agent developers will encounter as systems become more connected and autonomous.

## Key ideas
### Long-lived API keys give agents too much access
[01:07](https://www.youtube.com/watch?v=blmAkayzE8M&t=67s)
Hanson says connected agents are more useful, but current MCP setups often give them API keys that are long-lived and broadly scoped. Developers paste these keys into configuration files or environment variables, then let the agent use them. Repeating that pattern across hundreds or thousands of agents creates a large security problem. OAuth provides a move away from static secrets toward dynamic access. The authorization system can issue tokens with a controlled lifetime and scope instead of leaving a reusable secret inside the agent's environment.

### OAuth separates requesting access from deciding access
[01:43](https://www.youtube.com/watch?v=blmAkayzE8M&t=103s)
OAuth lets a client request access to an API, called a resource server, through an authorization server. Hanson uses Calendly connecting to Google Calendar as the example. Google checks that the user is logged in, asks for consent, and sends Calendly an access token. Calendly presents that token to the calendar API. Refresh tokens allow access tokens to remain short-lived and rotate while the connection continues. The resource server verifies tokens, while the authorization server handles login, consent, and token issuance. This keeps authentication work out of each individual API.

### OpenID Connect adds identity information to OAuth
[05:18](https://www.youtube.com/watch?v=blmAkayzE8M&t=318s)
Hanson distinguishes OAuth authorization from sign-in. When an application uses OAuth for sign-in, the API is replaced with a user-info API that returns claims such as an ID, name, and email address. OpenID Connect standardizes this identity layer and adds an ID token, a cryptographically signed JSON Web Token describing the user. The terminology changes, with the authorization server called an identity provider and the application called a relying party, but the underlying arrangement remains familiar. In practice, authentication and authorization flows often run together so an application knows who signed in and can access that person's resources.

### MCP's first OAuth design combined two different roles
[06:59](https://www.youtube.com/watch?v=blmAkayzE8M&t=419s)
Hanson describes MCP's early versions as having no authorization, followed by a first OAuth attempt in a late-March draft. That draft required MCP clients to implement the client side while MCP servers handled the full OAuth server role as well. This combined the MCP server's resource-server and authorization-server responsibilities. Hanson points to criticism from Christian Posta and Aaron Parecki, including the argument that the design was a poor fit for enterprise use. The later draft separates the OAuth authorization server from the MCP server. An MCP server can then verify HTTP tokens and leave login, consent, and token issuance elsewhere.

### Agent systems need authorization for machine-to-machine calls
[10:52](https://www.youtube.com/watch?v=blmAkayzE8M&t=652s)
User delegation through an authorization code flow covers only the case where an agent acts for a person. Hanson says agents will also communicate with other agents and MCP servers on their own behalf. OAuth's client credentials flow applies to that situation. He also questions how agents should get identities. Manual developer-portal registration with a client ID and secret does not fit a protocol where agents and tools may not know each other ahead of time. Dynamic client registration can issue credentials at runtime, but its unauthenticated registration request leaves agents anonymous and makes trust difficult.

### Public and identified agents need different registration approaches
[12:49](https://www.youtube.com/watch?v=blmAkayzE8M&t=769s)
For public clients whose identity does not need verification, Hanson discusses push client registration. A well-known string can identify the public client without a full registration exchange or stored registration state, and the request can carry client metadata when needed. For agents that do need authentication, he proposes URLs combined with public-key infrastructure. An identifier such as agent.com could identify a client, while the agent signs JWT assertions or HTTP message signatures. The authorization system can verify those signatures using the corresponding public keys. This reuses identifiers associated with existing applications while giving agents a way to prove who they are.

### Agent authorization must cover data sent to models and individual transactions
[14:07](https://www.youtube.com/watch?v=blmAkayzE8M&t=847s)
After an agent accesses a resource, it may send the resulting information to an LLM. Hanson says protected environments can sometimes treat the LLM as another API, but edge-deployed agents on desktop or mobile devices create harder questions because developers do not control the software environment. Remote attestation and software supply-chain security could help establish which device and software are running, then include that information in OAuth decisions. He also says OAuth scopes such as read and write can be too broad or long-lived for financial and commercial actions. Rich authorization requests could support permissions tied to a specific transaction, amount, or budget.

### Authorization has to follow an agent through a chain of services
[16:01](https://www.youtube.com/watch?v=blmAkayzE8M&t=961s)
MCP describes the authorized connection between an agent and an MCP server, but Hanson says the security profile is unspecified when that server calls another API. He recommends looking at OAuth token exchange for calls within a domain. When an MCP server calls a third-party API, identity chaining across domains and the identity assertion grant can support back-end authorization. In larger graphs of agents, authorization will need end-to-end visibility as it moves across multiple servers. The original permission cannot be treated as the whole story once an agent's work continues through other services.

### Background agents need ways to ask for access without a browser
[17:13](https://www.youtube.com/watch?v=blmAkayzE8M&t=1033s)
OAuth usually assumes that a user is in front of a browser during an authorization flow. Agents can continue working after a user walks away, then discover that they need more permission. Hanson says they need ways to contact the user through channels such as SMS or push notifications. He also points to voice, video, and fully background interactions as open security problems. Existing real-time technologies including SIP, XMPP, and WebRTC may offer useful prior work. These cases extend authorization beyond a one-time browser consent screen.

## Notable quotes
- "Agents that are more connected are more useful." (00:50)
- "We can give agents broad-based access and accept security risks or we can limit their capabilities and sacrifice business value." (01:07)
- "The MCP server itself is handling authorization." (08:56)
- "This makes it hard to build trust in agents." (12:26)
- "We're going to need end-to-end visibility as the authorization flows along these graphs." (16:53)

## Tools & references mentioned
- Keycard
- Passport.js
- OAuth
- OpenID Connect
- MCP
- Calendly
- Google Calendar
- Google
- Okta
- Auth0
- Christian Posta
- Aaron Parecki
- dynamic client registration
- push client registration
- rich authorization requests
- OAuth token exchange
- identity assertion grant
- SIP
- XMPP
- WebRTC

## Who should watch
- You are building an MCP server and need to decide which OAuth responsibilities belong in your server versus an authorization server.
- Your agent calls private APIs, other agents, or third-party services and you need a model for delegated and machine-to-machine access.
- You are designing background or edge-deployed agents that may need identity, transaction-level permissions, or a way to ask users for more access.

## Related talks

- [Building Protected MCP Servers](https://aietalks.com/talks/building-protected-mcp-servers) (Den Delimarsky & Julia Kasper, Microsoft, 20:13)
- [It's 10pm. Do You Know Where Your Agents Are?](https://aietalks.com/talks/its-10pm-do-you-know-where-your-agents-are) (Kim Maida, Keycard, 23:02)
- [Agents, Access, and the Future of Machine Identity](https://aietalks.com/talks/agents-access-and-the-future-of-machine-identity) (Nick Nisi, WorkOS & Lizzie Siegle, Cloudflare, 14:17)
- [Securing Agents with Open Standards](https://aietalks.com/talks/securing-agents-with-open-standards) (Bobby Tiernay & Kam Sween, Auth0, 18:41)
- [Better Auth](https://aietalks.com/talks/better-auth) (Bereket Habtemeskel & Paola Estefania, Better Auth, 40:56)