Authentication and authorization for AI agents
Who is acting, for whom, and who said they could?
Every API your agent calls needs those three answers, whether it is a calendar, a repository or a customer’s account. An API key gives it one. This guide starts from that key and goes as deep as the specifications.
What can the API tell?
The agent attaches: Its own API key
| Who is acting? | Yes | The key belongs to the agent’s account. |
|---|---|---|
| For whom? | No | alice is whatever the agent typed. The API cannot confirm it. |
| Who said they could? | No | An administrator gave the agent its access. Alice approved nothing. |
The API knows the agent is calling, and has to take its word for everything else. If Bob asks for Alice’s calendar and the agent sends Alice’s name, the API sees a valid key and answers. Alice is protected only while the agent tells the truth about who is asking. Do not rely on a key to keep users apart.
The agent attaches: A key Alice made
| Who is acting? | No | The key is Alice’s. Nothing shows which software is using it, or that software is involved at all. |
|---|---|---|
| For whom? | Yes | Alice’s account, because the key is hers. |
| Who said they could? | Partly | Alice made the key, so she agreed to something. Most keys open the whole account and never expire. |
The API can now tell Alice’s requests from Bob’s. But as far as it can tell, the agent is Alice: whatever it does is recorded as her doing it, and the key usually allows everything her account can do, for as long as it exists. It names the person and hides the software.
The agent attaches: A token Alice approved
| Who is acting? | Yes | The token names the app it was issued to. Like a key, it works for whoever holds a copy. |
|---|---|---|
| For whom? | Yes | The token names Alice, and the service that signed it vouches for that. |
| Who said they could? | Yes | Alice did, for reading her calendar and nothing else. |
The API can now tell Alice’s requests from Bob’s, refuse anything beyond reading a calendar, and block this one agent without locking Alice out. What the agent can do for Alice is now limited by what Alice approved, and the API is the one enforcing it.
A token Alice approved answers all three. Lesson 1 shows why
Learn it in order
Each lesson answers one question and builds on the one before. How the lessons work →
Or start from what you are building
Each goes to the page that says what to build, and what to leave to a library or a product.
- An assistant that works in each user’s own accountsHosted apps and backends
- A job that runs on a schedule, with nobody signed inLesson 4: the agent’s own identity
- A remote MCP serverMCP authorization: if you are writing the server
- An agent on KubernetesAgents on Kubernetes: the short answer
- A tool that has to call another API for the userLesson 5: chains of calls
- An agent that runs code it was givenSandboxes
Whose authority is the agent using?
If you know the ground, start here. It is the first question to settle, and it decides whose name is on the token.
ThenIs a person available when access is needed?
Yes, in the session
- MCP authorizationcalling an MCP server
- Authorization code + PKCEcalling an HTTP API, with a browser at hand
- Device authorizationno browser where the agent runs
- Enterprise-managed (ID-JAG)the company identity provider decides
- Step-up authorizationa fresh approval for one sensitive action
- URL elicitationan MCP server needs a grant from a third party
Reachable, but elsewhere
- Backchannel approval (CIBA)ask them on a device they already use
No
The agent runs unattended on authority the person delegated earlier. The arrangement to be most careful with.
- Authorization code + PKCEconsent once, then run on a refresh token
ThenWhere does its identity come from?
The platform it runs on
- Workload identity federationKubernetes or a cloud workload calling an outside API
- SPIFFE + mTLSservice to service inside your own platform
A registered client credential
- Client credentialsa client with a key or secret of its own
The decision guide asks four more questions: what the agent calls, who runs that, where the agent runs and what is at stake. Chains of agents and tools have flows of their own.
What is here
20 flows
Every flow as a sequence diagram you can step through, with the HTTP on the wire and who holds what at each step.
Deployments
Hosted apps, Kubernetes, managed agent platforms, desktops and CLIs, CI pipelines and sandboxes: where identity comes from in each, and what a gateway in front changes.
Standards tracker
96 RFCs, drafts and specifications with current status. 28 of them are still drafts.
Concepts on one page
The lessons, compressed, with every caveat left in: the roles, what an API can verify, delegation and an annotated tour of nine tokens.
Moving this year
For readers who follow the specifications. As of November 2026. Full tracker →
- MCP 2026-07-28The protocol went stateless, deprecated Dynamic Client Registration, and made issuer validation mandatory for clients.
- Agents are workloadsThe IETF WIMSE working group adopted an architecture for agent identity that composes existing standards and defines no new protocol.
- Pod Certificates are GAKubernetes 1.37 gives every pod a native, auto-rotated X.509 identity. You bring the signer.
- Approval can waitThe OAuth working group adopted Deferred Token Response: any grant may answer “not yet” while a human decides.