MCP authorization decides what context agents see

The Model Context Protocol shipped its Enterprise-Managed Authorization extension as a stable feature on June 18, 2026, and most coverage filed it under security. That framing is incomplete. The authorization stack that MCP standardized over the past year does more than decide who can log in to a server. It decides which sources an agent can ever pull into its context window, one token at a time. Read that way, MCP authorization is one of the most consequential context engineering decisions a team makes, and almost nobody treats it like one.

This post walks through what changed in MCP authorization in 2026, why token scoping is a context boundary rather than only a security wall, and how to design those scopes so an agent’s working context stays narrow and current.

What changed in MCP authorization in 2026

MCP authorization moved from per-user logins to centralized, identity-provider-managed access. The Enterprise-Managed Authorization extension, stable as of June 18, 2026, lets an organization provision MCP server access from the same identity provider console it already uses for everything else. The mechanism is an Identity Assertion JWT Authorization Grant: during single sign-on the client obtains an assertion from the identity provider and exchanges it for an access token at the MCP server’s authorization server. The result is what the maintainers call “zero-touch setup,” where the servers a user needs are connected on first login with no per-app OAuth dance.

Adoption arrived with the spec. Okta shipped the first identity-provider support using its Cross App Access protocol, with Anthropic’s Claude, Claude Code, and Cowork plus Visual Studio Code on the client side, and Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase on the server side. This sits on top of foundations laid earlier: since the June 2025 spec, MCP servers are formally OAuth 2.1 resource servers, and since November 2025 the default client identity model is the Client ID Metadata Document, a URL pointing to a JSON file the client controls rather than a registration stored per server. With MCP SDKs seeing roughly 97 million monthly downloads and the registry holding close to 2,000 server entries, this is the authorization model a large share of agent traffic now runs through.

Authorization is a context boundary, not only a security wall

The single most important line in the MCP authorization spec is the audience binding, and it is a context engineering rule disguised as a security one. MCP requires clients to use RFC 8707 resource indicators, which means the client names the exact server it wants a token for, and the authorization server stamps that target into the token’s audience claim. The receiving server then validates that the token was issued specifically for it. A token minted for one server is rejected by every other server.

That rejection is the part worth dwelling on. An access token is the credential an agent uses to fetch data, and a fetched document is context that enters the window. When RFC 8707 binds a token to one server’s audience, it is not only stopping a stolen token from being replayed elsewhere. It is guaranteeing that the agent holding that token cannot assemble context from any source outside its scope, because the credential will not authenticate anywhere else. The audience claim is a retrieval boundary. Scope the token and you have scoped the set of sources that can ever reach the model.

This is why the security framing undersells the change. Teams that think of MCP authorization as a gate on the front door miss that the same gate is silently shaping the agent’s information diet. Every scope you grant is a source you have made retrievable. Every scope you withhold is context the agent will never see, no matter how its retrieval logic behaves.

Over-permissioned access is a context-quality problem

Broad access does not just raise breach risk; it degrades answers. The reflex when wiring up an agent is to grant wide scopes so nothing blocks the task, and most deployments end up with agents that can reach far more than any single job requires. We have written before about how AI agents end up with too much access, and the security cost of that is well documented. The context cost is less discussed and just as real.

An agent scoped to a wide surface retrieves from a wide surface. The more sources are reachable, the more likely a query pulls in adjacent, outdated, or conflicting material alongside the relevant slice. That dilutes the share of useful tokens in the window, and retrieval accuracy falls as that share drops, a degradation pattern we cover under context rot. The agent is not wrong because the model is weak. It is wrong because it was allowed to assemble a noisy context, and the permission grant is what allowed it.

Narrowing the scope narrows the retrieval surface. A token that can only reach the three sources a task needs cannot accidentally surface a stale fourth. This is the same discipline as connecting AI to private data safely: the goal is not to lock the model out, it is to make sure that what it can reach is exactly what it should reach, so the working context stays dense.

The 2026 MCP authorization stack at a glance

Each building block in the current MCP authorization model controls a different part of what an agent can assemble. Read across the table: the left column is the security mechanism teams already know, and the right column is the context engineering consequence they usually miss.

The table is also a design checklist. If you cannot say which sources a given agent’s tokens are scoped to, you cannot say what its context can contain.

Token scope is retrieval scope

The practical takeaway is to design token scopes the way you would design a retrieval policy, because they are the same thing. The emerging pattern that makes this concrete is session-scoped authorization: rather than handing an agent a long-lived token that can reach a broad set of servers for as long as it runs, you issue a token limited to the duration and surface of one task. When the task is to reconcile two invoices, the agent gets a token whose audience is the billing source and nothing else, and it expires when the job does.

That is just-in-time access, and it is structurally identical to just-in-time retrieval, one of the context offloading patterns that keeps a window small by pulling state in only when a step needs it. The difference is enforcement. Retrieval policy implemented in application code can be bypassed by a clever prompt or a buggy tool. Retrieval policy implemented as token audience is enforced by the resource server itself, below the agent’s reasoning, where no instruction can talk its way past it. This is the same reason remote MCP with proper authorization changes the threat model so sharply, a shift we traced through 14 MCP CVEs back to one design choice.

Designing for this means a few habits. Scope tokens to tasks, not to agents. Prefer many narrow audiences over one broad one, because a narrow audience is a narrow context surface. And put the scoping decisions somewhere you can audit them, which is exactly what Enterprise-Managed Authorization centralizes by moving those decisions into the identity provider and emitting a single audit log.

What this means for context engineering

Authorization has quietly become part of the context delivery infrastructure, alongside the transport and tool-loading work the 2026 MCP roadmap lays out. The model never chooses its own scope. A human or a policy decides, before the agent runs, which audiences its tokens carry, and that decision sets the outer bound on every context the agent can build for the rest of the session. Tool selection, retrieval ranking, and compression all operate inside a box whose walls were drawn by the authorization layer.

Wire treats that box as the unit of the product: each context container is an isolated, permissioned environment, and an agent’s MCP access is scoped per container, so a token issued for one customer’s container has no audience for any other and cannot retrieve across the boundary. That per-container scoping is described on the agent products page. The point is general, though, and it holds for any system: if you want an agent’s context to stay narrow and current, scope its tokens like you mean it, because the token scope is the context.

The teams that internalize this stop reaching for authorization only when a security review forces them to. They reach for it first, as the cheapest and most enforceable way to decide what an agent is even capable of seeing.

Sources: Enterprise-Managed Authorization · MCP Authorization specification · RFC 8707 Resource Indicators for OAuth 2.0 · The 2026 MCP Roadmap · Everything your team needs to know about MCP in 2026 (WorkOS)