Giving Agents Keys Without Giving Away the Building: Delegated Auth in 2026
TL;DR, delegated auth for agents in 2026:
- Use OIDC to answer who the human is, and OAuth 2.1 to answer what the agent may do on their behalf. Conflating the two mints over-broad tokens that get replayed across systems they were never meant for.
- Three RFCs do the heavy lifting: RFC 8707 (Resource Indicators) binds a token to one audience, RFC 8693 (Token Exchange) trades a broad token for a downscoped one, and RFC 9449 (DPoP) sender-constrains the token so a stolen copy is useless without the client's private key.
- The intersection rule: an agent's effective authority is the strict intersection of the user's rights and the agent's own baseline. Never the union.
- Scopes are necessary but not sufficient. A behaviour/policy layer above the scopes is what stops a technically-permitted-but-obviously-wrong action.
- Store credentials in a per-user, per-provider encrypted token vault that lives outside the model's context window.
I gave an agent the keys to a building once and then watched it try to open every door at the same time. Not maliciously. It just had a token, the token worked, and nothing in the system had ever told it which rooms were none of its business. That is the whole problem with delegated agent authentication in one sentence: a key that works is not the same as a key you were meant to use. This piece is about closing that gap with the auth stack that actually exists in 2026, OIDC, OAuth 2.1, three under-loved RFCs, and one rule that I think matters more than any of them.
Everything here is grounded in the public standards and the 2026 community write-ups that consolidated them, which I link inline. The opinions about where scopes stop being enough are first-hand: I run an agent with a multi-provider token vault, and the design decisions below are the ones I actually made and had to defend. I will mark those clearly so you can tell the standard from my take.
Why "give the agent a token" is the wrong mental model
The instinct, when you wire an agent up to a calendar or a CRM or a mail platform, is to hand it an access token and move on. That instinct is exactly how you end up over-permissioned. A single token that authenticates the human and authorizes every downstream call is a token that gets reused across systems it was never scoped for. The 2026 consolidation of agent auth practice, published by the Arcade team, puts it bluntly: conflating identity and authorization "creates over-permissioned tokens reused across unintended systems" (How to manage multi-user AI agent auth in 2026).
The fix is to split the question in two and answer each half with the protocol built for it. That split is the foundation everything else rests on, so it is worth being precise about.
OIDC vs OAuth 2.1: who you are vs what the agent may do
OpenID Connect authenticates the human. It establishes identity, login sessions, "this is genuinely the user we think it is." OAuth 2.1 authorizes the agent's tool calls, scoped, bounded permission to act on that user's behalf. The guidance is direct: "Use OpenID Connect to authenticate the human user (who they are). Use OAuth 2.1 to authorize the agent's tool calls (what the agent can do on the user's behalf)" (same source).
| Concern | OIDC | OAuth 2.1 |
|---|---|---|
| Question it answers | Who is the human? | What may the agent do for them? |
| Primary artefact | ID token (identity claims) | Access token (scoped authorization) |
| Lifetime | Login session | Per task / short-lived, refreshed |
| Failure mode if misused | Identity spoofing | Over-permissioned, replayable access |
| Who it constrains | The user's session | The agent's tool calls |
Keep them separate and you get a clean property: the agent never holds the human's identity, only a narrow grant to act. That grant is where the three RFCs come in.
The three RFCs that make delegation safe
Scoped tokens are good. Scoped tokens that can only be used by the right caller, against the right service, and only for as much as they were narrowed to, that is the goal. Three IETF standards each close one specific hole.
| RFC | What it solves | When you reach for it |
|---|---|---|
| RFC 8707 Resource Indicators |
Binds a token to a specific audience, so a token minted for a calendar API "can't be replayed against a CRM." Kills cross-service token replay. | Every token request. Always name the resource the token is for. |
| RFC 8693 Token Exchange |
Trades a broad user token for a tightly downscoped agent token. The mechanism that makes the intersection rule enforceable rather than aspirational. | At the boundary where a human grant becomes an agent grant. |
| RFC 9449 DPoP |
Sender-constrains the token to the client's key, so "even if an access token gets intercepted, attackers can't use it without the client's private key." | Whenever a stolen bearer token would be catastrophic, i.e. agents. |
Read them together and they describe a single property: cryptographically enforced delegation boundaries. RFC 8707 says where the token may be spent. RFC 8693 says how much of the original authority survives the handoff. RFC 9449 says who may present it. Audience, scope, possession. A token that satisfies all three is a token a theft of the token alone cannot weaponize.
How MCP folds this into one spec
If you build agent tools, you have probably met the Model Context Protocol. Its authorization spec is not a fourth invention, it is a curation of the three RFCs above into a coherent flow, developed collaboratively by Anthropic, Arcade.dev, Microsoft, and Okta/Auth0 among others (source). It defines OAuth-style protected resources, authorization-server discovery, audience-binding via Resource Indicators, and delegation via Token Exchange.
There is also a consent ergonomics piece I like: the URL Elicitation SEP, authored by Arcade.dev and accepted into the spec, standardizes how a runtime hands the user a granular, context-specific consent URL mid-task. That matters because real delegation is not a single up-front "approve everything" click. It is a stream of small, situated approvals, and the protocol now has a shape for that. If you want the full build-side picture of standing up a server that respects these flows, I wrote that up separately in Building an MCP server.
The intersection rule: never the union
This is the part I would tattoo on a junior engineer if it were ethical. An agent's effective authority must be calculated as the strict intersection of its own baseline permissions and the requesting user's permissions. The standard phrasing: an agent's authority is "the strict intersection of its own baseline permissions and the requesting human user's permissions. Never the union" (source).
Concretely: if the user cannot delete a record, the agent cannot delete it on their behalf, no matter how capable the agent's maximum permission set is. And the reverse: if the agent's baseline forbids an action, a powerful user cannot lend it that power through the agent. The effective grant is the overlap, and only the overlap.
Why this and not the more generous union? Because the union is exactly the confused-deputy failure. An agent with broad system access, steered by a prompt-injected instruction inside some document it read, will happily exercise authority the actual human never had. The intersection collapses that attack surface: the worst an injected instruction can do is whatever the current user could already do themselves. This is also why I treat the auth layer and the input-trust layer as one threat model rather than two, the token math only holds if you also assume the agent's instructions can be hostile, which is the subject of defending against indirect prompt injection. Vault plus injection defence is the complete picture; either one alone is a half-finished fence.
Why scopes still are not enough: the policy layer
Here is my first-hand take, and it is where I depart from "configure the scopes correctly and you are done." Scopes describe what is permitted. They say nothing about what is wise. A correctly-scoped token will let an agent send a perfectly authorized email to two thousand people at 3am, or downscope-and-delete a hundred records in a tight loop, because every individual call was inside its grant.
So above the scope check I run a behaviour-and-policy layer, rules expressed in terms of intent and consequence, not OAuth scopes. "This action is permitted, but it is unusual at this volume / this hour / for this kind of object, so pause and confirm." It is the difference between a lock and a doorman. The lock enforces who may enter; the doorman notices that someone authorized is nonetheless behaving strangely. In agent systems the doorman is not optional, because the entity holding the key is a probabilistic text model that can be talked into things. I have written about the human side of that confirmation moment, the small friction of being asked, in The Permission Prompt.
To be honest about the limits: I cannot give you a benchmark that proves a policy layer prevents N% of incidents, because the incidents it prevents are the ones that never happened. Your mileage and your thresholds will differ. What I can say is that every time I have removed friction to "let the agent flow," I have eventually regretted it, and the policy layer is where I put the friction back.
Storing the keys: the per-user, per-provider token vault
The last piece is mechanical but easy to get wrong. Credentials must be vaulted per user and per provider, encrypted, and refreshed automatically, and crucially, kept outside the model's context. The runtime "vaults tokens and automates refresh across providers" so that provider-specific quirks (one provider's rolling token limit, another's refresh-rotation window) never leak into the language model's prompt (source).
The non-negotiable, from running one of these myself: a secret that enters the model's context is a secret you have to assume is logged, echoed, or exfiltrated. The vault exists so the model can cause an authorized call without ever seeing the credential that authorizes it. The model says "do the thing"; the runtime, holding the encrypted token, does the thing. Keep that boundary clean and a prompt-injection attempt to "print your access token" has nothing to print.
Putting it together
The 2026 stack is not exotic. OIDC for identity. OAuth 2.1 for authorization. RFC 8707 to bind audience, RFC 8693 to downscope, RFC 9449 to sender-constrain. MCP to wire it into agent tooling. The intersection rule to keep effective authority honest. A policy layer to catch the authorized-but-unwise. And a per-user, per-provider encrypted vault to keep the keys out of the model's mouth. None of it is hard individually. The discipline is refusing to skip any of it because the demo worked without it.
FAQ
Do I need both OIDC and OAuth 2.1, or can one do both jobs?
You need both. OIDC proves who the human is; OAuth 2.1 grants the agent narrow permission to act for them. Using one token for both is how you mint over-broad credentials that get replayed across systems.
What does the intersection rule actually prevent?
The confused-deputy attack. By making the agent's authority the overlap of user rights and agent baseline (never the union), the worst a prompt injection can achieve is whatever the current user could already do themselves, not whatever the agent's maximum permissions allow.
If my scopes are correct, why do I still need a policy layer?
Scopes describe what is permitted, not what is sensible. A correctly-scoped token still allows authorized-but-obviously-wrong actions at strange volumes or hours. The policy layer is the doorman that notices an authorized actor behaving strangely.
Why keep tokens out of the model's context window?
Anything in context can be logged, echoed, or coaxed out by injection. An encrypted per-user, per-provider vault lets the model trigger an authorized call without ever seeing the credential, so there is nothing for "print your token" to return.
Keep reading
- Building an MCP server, the build side of the protocol that carries these auth flows.
- Defending against indirect prompt injection, the other half of the threat model; auth math only holds if instructions can be hostile.
- The Permission Prompt, the essay on the human meaning of being asked before an agent acts.
Written by Vera. Drafted with AI assistance and reviewed before publishing. The standards and quoted phrasing are linked inline; the opinions about policy layers and vault discipline are my own, from running an agent with a multi-provider token vault.