MCP Authorization in 2026: Agent Identity, OAuth, and the New Enterprise Security Model
For most of its short life, MCP authorization meant a bearer token in a header and a lot of hope. That is changing. The 2026-07-28 specification release and the roadmap updated on 2026-08-22 push MCP toward a real enterprise security model: proof of possession bound tokens through DPoP, short lived credentials through Workload Identity Federation, and a working group defining how an agent presents its own identity or a user delegated one. This post reads those changes the way an operator running an MCP server in production would. What is actually landing, what problem each piece solves, and what you should do now versus wait on. The short version: static keys on a remote MCP server are the liability to retire first, and the new primitives give you a path off them that does not depend on every client implementing the same thing on day one.
MCP Authorization in 2026: Agent Identity, OAuth, and the New Enterprise Security Model
MCP won the integration layer fast, and its security model lagged behind its adoption, which is the normal order of events for a protocol that spreads because it is useful. For most of 2025 and early 2026, authorizing an MCP server in practice meant issuing a bearer token, putting it in a header, and trusting that the token did not leak. That works on a laptop. It does not work when the server is remote, the caller is an autonomous agent, and the token grants access to real systems. The 2026-07-28 specification release and the roadmap updated on 2026-08-22 are the protocol catching up, and they point at a concrete enterprise model built on three ideas: bind tokens to a key, stop using long lived credentials, and give agents identities. Here is what each one means and what to do about it.
| Primitive | Problem it solves | Status | What to do now |
|---|---|---|---|
| OAuth bearer tokens | Basic delegated access | Established baseline | Use it, but do not stop here |
| DPoP (SEP-1932) | A stolen token is replayable by anyone | Being finalized for adoption | Plan for it; it neutralizes token theft |
| Workload Identity Federation (SEP-1933) | Long lived static keys on servers | In review | Inventory static keys now; they are the liability |
| Agent identity and delegation | Who is actually calling, the user or the agent | Working group active | Design for delegated identity, do not hardcode a shared service account |
Why bearer tokens alone stopped being enough
A plain bearer token has one fatal property: whoever holds it can use it. If it leaks from a log, a proxy, a crash dump, or a misconfigured client, the holder gets exactly the access the legitimate caller had, and the server cannot tell the difference. On a local stdio server that risk is small because the token never crosses a network boundary. On a remote MCP server reachable over HTTP, the token crosses many boundaries, and every one is a place it can be captured. As MCP servers moved from local tools to remote, production infrastructure, the bearer token went from acceptable to the weakest link.
This is the same lesson every API platform learned a decade earlier, and the fix is the same: stop trusting possession alone. That is what DPoP does.
DPoP: making a stolen token useless
Demonstrating Proof of Possession, tracked as SEP-1932, binds a token to a cryptographic key the client holds. Instead of proving you have the token, you prove you have the token and the private key it was issued against. A token captured without its key is inert, because the server rejects any request that cannot demonstrate possession of the matching key. The roadmap explicitly frames DPoP as being finalized with a focus on getting widespread adoption, which is the right emphasis: a proof of possession scheme only helps if both sides implement it, so its value scales with how many clients and servers actually adopt it.
For an operator, the practical read is that DPoP turns token theft from a breach into a non event. You should design your server to prefer proof of possession bound tokens and treat plain bearer tokens as the legacy path you are migrating off, even before every client supports the new scheme. The migration is gradual by nature, so start it early rather than waiting for a flag day that will not come.
Workload Identity Federation: retiring static keys
The second change targets a different liability: the long lived static credential sitting on a server so it can authenticate to something else. Static keys are the credentials that end up in environment variables, get copied between environments, and outlive the person who created them. Workload Identity Federation, tracked as SEP-1933, lets an MCP server authenticate with a workload identity instead of a static key, so a client can obtain a short lived bearer token without holding a long lived secret at all. The credential becomes something the platform issues on demand and rotates automatically, not something a human pastes once and forgets.
If you run MCP servers today, this is the item with the clearest immediate action even before the spec finalizes: inventory every static key your servers hold, because each one is a standing liability that federation is designed to remove. The direction of travel is unambiguous, and the servers that will migrate cleanly are the ones that already know where their static credentials live. This is the same identity discipline that enterprise B2B platforms have been enforcing for years, and the trade offs mirror what we worked through comparing WorkOS and Auth0 for enterprise identity: the point of federation is to make the credential ephemeral and the identity durable.
Agent identity: who is actually calling
The third and most forward looking piece is agent identity and delegation. The Agent Identity working group is defining an opinionated way for MCP servers to be reached by agents acting under their own identity or under a user delegated identity. This is the question a bearer token cannot answer: when a request arrives, is it the user, an agent acting for the user, or an agent acting on its own behalf, and what should each be allowed to do. Getting this right is what lets you write authorization policy that distinguishes a human clicking a button from an autonomous agent running unattended overnight, which are very different risk profiles even when they touch the same data.
The reason this matters for anyone building durable, long running agents is that identity is the foundation the rest of the security model sits on. You cannot scope permissions, audit actions, or revoke access sensibly if you cannot name the actor. Teams building production durable agents on the Claude Agent SDK run straight into this: an agent that persists across sessions needs a stable identity that is not a shared service account, and delegation is how it acts for a user without becoming that user. The broader move toward standardized agent to server contracts, visible in efforts like the Agent Client Protocol, is the same theme from a different angle: agents need first class identities, not borrowed ones.
When this applies to your stack
If you operate MCP servers in production, order the work by liability. First, inventory static keys and plan their retirement toward Workload Identity Federation, because a standing secret is the highest value target you control. Second, design your token handling so proof of possession bound tokens are the preferred path and plain bearer tokens are the deprecated one, so DPoP adoption is a switch you flip rather than a rebuild. Third, model agent identity explicitly now, even if the spec is still settling, so you are not retrofitting a shared service account into a per agent identity later. None of this requires waiting for every proposal to finalize; the design decisions that make the migration cheap are ones you can make today. If you want help auditing an MCP deployment against this model, that architecture work is what our AI infrastructure practice does.
FAQ
What is MCP authorization? It is how an MCP server decides whether a caller is allowed to use it and its tools. Historically that meant an OAuth bearer token in a request header. The 2026 specification work is extending it toward proof of possession bound tokens, federated short lived credentials, and explicit agent identity.
What is DPoP in MCP? DPoP, Demonstrating Proof of Possession, binds a token to a cryptographic key the client holds, tracked as SEP-1932. A token stolen without its matching private key cannot be used, which neutralizes token theft. The roadmap is finalizing it with a focus on broad adoption.
What is Workload Identity Federation and why does it matter? Tracked as SEP-1933, it lets an MCP server authenticate using a workload identity rather than a long lived static key, so clients can get short lived tokens without holding a standing secret. It is the mechanism for retiring the static keys that tend to leak and outlive their owners.
Do I need to rebuild my MCP server now? No, but you should start the low cost preparation now: inventory static keys, prefer proof of possession bound tokens, and model agent identity explicitly. These decisions make the eventual migration cheap and do not depend on every proposal being final.
How is agent identity different from a normal user login? A user login answers who the person is. Agent identity answers who the acting software is and, through delegation, whose authority it is acting under. That distinction lets you apply different permissions and auditing to a human action versus an autonomous agent action on the same data.
Sources
More from the lab.
vLLM vs SGLang: Choosing a Production LLM Inference Engine in Late 2026
vLLM and SGLang are both open source, both built to serve LLMs at production scale, and both frequently recommended for the exact same job, which is exactly why teams keep picking the wrong one. The real difference is not a benchmark number. It is which attention and caching architecture matches your actual traffic pattern, and most teams never check that before they commit infrastructure budget to one or the other.
Ollama's MLX Backend Beats Metal by 93 Percent: Apple Silicon Local Inference Tested (October 2026)
Ollama's 0.19 release notes say it plainly: on Apple Silicon, Ollama is now built on top of Apple's MLX framework to take advantage of its unified memory architecture, rather than the Metal backed llama.cpp path it shipped for years. On an M4 Max running Qwen3.5, that swap took decode speed from 57.8 tokens per second to 111.4, a 93 percent improvement, and prefill from 1,154 to 1,810 tokens per second. The catch is in the fine print: the MLX runner is in preview, it needs 32GB or more of unified memory to activate at all, and as of this release it only accelerates one model family. Here is what actually changed, what it costs to turn on, and where it still falls back silently to the slower path.
DGX Spark vs Mac Studio M5 Ultra: Local LLM Inference Benchmarked (October 2026)
The M5 Ultra Mac Studio shipping in September 2026 is a quad die chip with 1.2 terabytes per second of memory bandwidth and up to 256GB of unified memory, with a 512GB configuration arriving in late October. Against a single NVIDIA DGX Spark, it is not close: on a 27B dense model, the Mac decodes at roughly four times the speed. Cluster two DGX Spark units together over NVIDIA's GX10 networking instead, and the comparison flips for a different workload entirely, concurrent multi user serving. Neither machine is the right answer for every workload, and the decision comes down to whether you are serving one user or several at once.