[July 2026 edition]

The Responsibilities MCP Separates, Part 2 — Separating Identity from Permission to Data

Published: Jul 30, 2026
Reading time: ~6 min

Part 1, “Moving Protocol State Out of the Session,” covered how MCP v2026-07-28 separates protocol state from a connection and makes business state available through explicit handles.

Sending the next request that Instance A handled to Instance B does not by itself establish that B may give its requester access to business data. A request arriving at any instance needs two decisions: who sent it, and whether that subject is allowed to operate on the requested data.

MCP uses OAuth as its authentication and authorization foundation

This responsibility cannot be carried in an MCP session as before, because requests can arrive at any instance. MCP v2026-07-28 Authorization uses OAuth to establish the subject and issue and validate access tokens. MCP does not define its own login method or token format; it applies OAuth roles to MCP communication.

The agent, as an OAuth Client, obtains an access token and presents it to the MCP server.
The protected MCP server, as an OAuth Resource Server, receives the token and validates its validity and intended audience.
The Authorization Server issues the access token to the agent.

The agent discovers the authorization information required by the protected MCP server and obtains an access token from the Authorization Server. It then attaches the token to each MCP request. A Gateway validates the token to establish the requester, and the instance that receives the call checks whether that subject is allowed to operate on the target data. Authentication and authorization are separate layers here.

The authentication layer establishes the subject making the request. It validates the presented credential and stops a request that cannot be established at the router.
The authorization layer decides whether the established subject may operate on the requested business data. It compares the target record, tenant, and operation, and allows only permitted requests to reach the database.

For an HTTP-protected MCP server, the agent attaches an access token to each request like this:

POST /mcp HTTP/1.1
Authorization: Bearer <access-token>
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: customer.search
Content-Type: application/json

Authorization: Bearer <access-token> is the HTTP form for presenting an OAuth access token. OAuth 2.0 Bearer Token Usage (RFC 6750) specifies that form. The router or Gateway checks that the received token is valid and was issued for this MCP server. An invalid or expired token receives 401 and does not pass through. MCP Authorization specification

This check is authentication. In the animation, the yellow Gateway asks whether the subject making the request can be established. After it passes, the authorization information derived from the token—the subject, tenant, and scopes—travels to the instance that will access the data.

Mcp-Session-Id was the earlier protocol’s clue to which connection a request continued; it was not a credential proving a user, tenant, or permission. Mcp-Method and _meta are not credentials either. In particular, _meta.io.modelcontextprotocol/clientInfo is a self-reported name and version for client software.

Use one token-validation model across every instance

A Bearer access token is a credential presented by its holder. OAuth does not fix the format of an access token, so the Gateway or each instance validates it according to the chosen model.

Two common validation models are:

JWT access token: carries signed claims such as iss, aud, exp, sub, and scopes. Each instance can validate it with the Authorization Server’s public keys without a network lookup.
Opaque token: is a random value whose meaning is not exposed to the agent or instance. The instance or Gateway calls the Authorization Server’s introspection endpoint to establish its validity, subject, and scopes.

JWTs are convenient for validation across distributed instances; opaque tokens make central revocation and permission changes easier to reflect. In both cases, the agent does not decide by reading the token. The Resource Server validates it using the configured method. JWT Access Token Profile (RFC 9068) / OAuth Token Introspection (RFC 7662)

With a JWT, validate the issuer (iss), target resource (aud), expiry (exp), signature, and scopes needed for the operation. Do not accept an ID Token in place of an Access Token.

Check permission before reaching business data

Handles from Part 1—such as basket_id, task_id, and a conversation ID—are keys for business state in a database or cache. Immediately before reading or writing data, the instance compares the subject, tenant, and scopes derived from the token with the target record’s owner, tenant, and operation policy.

For example, suppose Instance A returned basket_id: "bsk_42" and the next request arrives at Instance B. B checks the owner, tenant, and operation policy for bsk_42 and reads or writes state only when they match. If the required scope is absent or the target belongs to another tenant, B returns 403 here.

request:  basket_id = bsk_42
token:    subject = user_123, tenant = acme, scope = basket:write
record:   owner = user_123, tenant = acme
result:   allow

That comparison is the part of the animation where the blue and purple authorization information reaches the database. The authentication Gateway establishes the requester; the business service decides whether that requester may operate on the target data. An implementation that returns data from a handle alone turns IDs leaked in logs, URLs, or errors into an authorization bypass.

OAuth and MCP server topology

An organization’s IdP or OAuth platform—the Authorization Server—runs outside MCP. It authenticates the agent, gathers consent, issues access tokens, and handles revocation. The agent presents the token it receives there to the MCP server. Adding Instances A, B, and C behind a load balancer does not change that: the agent presents a token issued by the shared identity platform.

Each MCP instance acts as an OAuth Resource Server and validates the issued token. With a JWT, it obtains the Authorization Server’s public keys and validates iss, aud, exp, signature, and scopes. With an opaque token, it calls the Authorization Server’s introspection endpoint to establish validity, subject, and scopes. The MCP instance uses the external identity platform rather than hosting OAuth itself.

A topology may validate the token first at a Gateway and then pass the request to an MCP instance. The MCP instance or business service then compares basket_id or task_id with the subject, tenant, and scopes derived from the token before permitting the operation on the target data.

A Bearer token is accepted from whoever possesses it. HTTPS, keeping tokens out of URLs, never logging a raw token, short lifetimes, and safe renewal are therefore prerequisites. The MCP specification also prohibits including an access token in a URI query string.

What is separated is responsibility, not the connection

MCP v2026-07-28 has not removed state. It places protocol state in each request, business state in explicit persistent data, and authentication and authorization in access tokens and server-side policy.

Those boundaries let a router send a single received request to any instance without consulting connection history. The instance can still access state, while independently deciding whether the requester is permitted to perform the operation. The cloud-operational change is not the disappearance of sessions by itself; it is the ability to treat state and permission as separate responsibilities.