MCP Authorization and OAuth: What the Spec Delegates to You

Start with the incident file, not the protocol.

The Model Context Protocol Blog says MCP has adopted OAuth 2.1 as the foundation for its authorization framework. That matters, because OAuth is a mature answer to the wrong half of some governance questions. The Model Context Protocol announced a new specification release with SDKs on 28 July 2026. The compliance problem starts when a valid connection is treated as proof that a payment release, record deletion, or credit-limit change was authorised.

MCP Authorization OAuth at the Transport Layer

The clean reading is the least dramatic one. MCP authorization OAuth work gives clients and servers a standard way to discover an authorization server, obtain a token, and present that token to an MCP server. That is important plumbing. It is not, by itself, an answer to who approved one agent action at one moment.

The Model Context Protocol provides authorization capabilities at the transport level,

— Authorization - Model Context Protocol, 30 August 2026

That sentence should slow down the design review. Transport-level authorization is not meaningless. It can stop an unrecognised client from reaching a server, and it can force the client through a recognised authorization flow. But it is still not the same thing as a policy decision on whether the agent may delete a customer record after a complaint has been opened.

The Model Context Protocol authorization page published on 30 August 2026 says MCP clients must use OAuth 2.0 Protected Resource Metadata for authorization server discovery. The same page says authorization servers and MCP clients should support OAuth Client ID Metadata Documents. It also says authorization servers and MCP clients may support OAuth 2.0 Dynamic Client Registration. Those are discovery and registration mechanics. They say how parties find and describe one another. They do not prove that the disputed invoice write-off was allowed under finance policy.

The MCP Apps authorization page is more operational. It says MCP Apps can protect tools behind OAuth-based authorization, as defined in the MCP specification. It also describes per-server authorization as the whole MCP server requiring authorization at connection time. That is a useful pattern if the question is whether a client may connect at all. It is a weaker pattern if the question is whether the same client may read a ticket, then change its status, then issue a refund.

This is where teams lose the thread. A token becomes a proxy for a judgement it did not make. The token may show that a client came through the expected route. It may show that the server was the intended audience. It may even carry useful context. It still does not, without a separate decision record, show why the action was allowed.

If the distinction feels pedantic, keep Identity Is Not Authorization Is Not Evidence beside the MCP work. The same separation applies here. Identity is who is acting. Authorization is what the actor may do. Evidence is what remains when the incident ticket, audit sample, or customer dispute arrives.

The MCP Authorization Server Boundary

The authorization server has a defined place in the MCP model. The Model Context Protocol authorization page published on 30 August 2026 says the authorization server is responsible for interacting with the user if necessary and issuing access tokens for use at the MCP server. That is an allocation of responsibility. It is not a full governance system.

The authorization server is responsible for interacting with the user (if necessary) and issuing access tokens for use at the MCP server.

— Authorization - Model Context Protocol, 30 August 2026

Read that sentence narrowly. It says the authorization server issues access tokens for use at the MCP server. It does not say the authorization server knows your approval matrix for refunds, your break-glass procedure for support staff, or the reason a legal hold blocks one record from being edited. Those may be built around it. They are not delivered merely by naming an authorization server.

The tutorial published by Model Context Protocol on 2 August 2026 uses a locally-running Keycloak authorization server in its example. The same tutorial says the sample server does token introspection through Keycloak to make sure the token received from the client is valid. It also says not to implement token validation or authorization logic by yourself. That advice is sensible. It also has a limit.

Do not implement token validation or authorization logic by yourself .

— Understanding Authorization in MCP - Model Context Protocol, 2 August 2026

The limit is not a criticism of OAuth. A standard authorization server can be the right place to issue and validate tokens. It can also be the wrong place to encode every business condition that matters at the moment an agent acts. A collections agent changing a payment plan is not the same decision as a support agent reading the plan. A server-level token cannot be assumed to answer both.

The draft Model Context Protocol authorization page published on 30 August 2026 says the implementation details of the authorization server are beyond the scope of that draft. Because that page is a draft, it should not be treated as settled final guidance. The architectural point is narrower: a specification can define the contract around authorization without carrying every business control inside the process.

The Model Context Protocol Blog published Enterprise-Managed Authorization on 18 June 2026, describing it as stable and as enabling organisations to centrally provision MCP server access through their identity provider. The same post says the standard MCP authorization model was designed to be user-scoped and bound to the client. That is a meaningful field development. It reduces connection friction and centralises server access. It still should not be mistaken for an audit answer about a single destructive action.

A fair objection is that many organisations already put policy into identity and access platforms. Some do it well. The objection does not defeat the evidence question. If policy is evaluated elsewhere, the record still has to survive elsewhere. A dashboard green light during the flow is not the same as an artefact that can be produced later.

The MCP Authorization Token Question

The token question deserves a direct answer. The MCP tutorial says the access token is what the client uses to authenticate requests to the MCP server. The Model Context Protocol authorization page published on 30 August 2026 says an MCP server must follow OAuth 2.1 guidelines to validate inbound tokens. The same page says MCP servers must validate that tokens presented to them were specifically issued for their use.

That is the proper burden of the MCP authorization token. It should be valid. It should be meant for the server receiving it. It should not be casually accepted from somewhere else. The Model Context Protocol authorization page for the earlier specification says MCP clients must not send tokens to the MCP server other than ones issued by the MCP server’s authorization server.

The MCP tutorial makes the audience point in plainer language. It says token verification helps the MCP server confirm that the token was meant for it rather than for another API. That is exactly the kind of control engineers should want. It blocks a class of confused-token failures. It still does not tell a reviewer why the agent was allowed to change the credit limit from one value to another.

There is a pattern here. The token can authenticate a request. The server can validate the token. The authorization server can issue the token. The client can discover the right authorization server. None of those steps, alone, says the action was permitted under the rule that mattered.

That sentence is not an argument against OAuth. It is an argument against over-claiming OAuth. If the sensitive event is “read customer profile”, server-level access may be enough for some systems. If the sensitive event is “delete profile”, “release payment”, or “change refund destination”, the permission should be evaluated at the point of action and preserved as evidence.

The Who Authorizes an MCP Tool Call? analysis treats that tool-call moment as the unit of control. That is the right unit when the agent is about to touch something that matters. The token establishes a necessary part of the path. The permission decision decides whether the path may be used now.

The MCP Apps authorization page says that regardless of the approach, OAuth discovery metadata and token verification are needed. It also says MCP servers must validate that tokens were issued specifically for them. Needed is not complete. A compliance owner should treat token verification as one control in the chain, not as the evidence artefact for the whole chain.

What this means if you have to produce evidence

The evidence problem is not solved by proving that the token existed. It is solved by proving that the right authority permitted the right action under the right policy at the time. That record has to be intelligible to someone who was not in the runtime path. Otherwise the answer collapses into “the server accepted it”, which is an operational fact, not a governance one.

Crelis’s GREENLIGHT knowledge base states the distinction bluntly: MCP can authorize an individual tool call and can pause mid-call for a human decision, but it cannot record which policy permitted the action or keep that record after the call returns. That is a Crelis claim about the evidence gap, and it should be read as such. It is not a statement from the Model Context Protocol maintainers. It is the position Crelis builds around.

The operational consequence is simple. If your MCP server protects the route to tools with OAuth, keep doing that. If your server validates tokens, keep doing that too. But do not let those controls become the only record of authority for actions that later need to be defended.

There is another reasonable objection. Some organisations may decide that ordinary logs are enough. For low-risk reads, they may be. For a changed bank detail, a deleted record, or an administrative action on a customer account, ordinary logs usually answer the wrong question. They show an event happened. They often do not show the permission basis that made the event legitimate.

This is where runtime authorization differs from runtime security. Runtime security asks whether something looks dangerous, abusive, or anomalous. Runtime authorization asks whether this actor may perform this action under the policy that governs it. Both can block harm. Only the second is naturally framed around authority.

Evidence adds the last requirement. The decision must not merely occur. It must leave a tamper-evident record that identifies the action, the actor, the policy basis, and the outcome. If any one of those is absent, the record may still be useful for debugging. It will be weaker when challenged.

Practical Steps for MCP Teams

1. Separate connection from action. Treat MCP authorization OAuth as the control that governs access to the MCP server, then write a separate control for actions such as payment release, record deletion, permission change, and credit-limit update.
2. Map the authorization server boundary. Record which system issues tokens, which system validates them, and which system decides whether the requested business action is allowed; the Model Context Protocol specification assigns token issuance to the authorization server.
3. Validate the token for the server. Keep the MCP requirement that servers validate tokens presented to them were specifically issued for their use.
4. Do not hide policy inside a token assumption. If a token proves the client can reach the server, do not let that become evidence that the client could take every action exposed by that server.
5. Record the permission decision at action time. For each sensitive tool call, preserve the requested action, the subject, the policy basis, the result, and any human approval that changed the result.
6. Test before blocking. Use a non-blocking proof period where proposed decisions are recorded and compared with actual outcomes; shadow mode is the safer way to find policy gaps before enforcement begins.
7. Keep the MCP material in one place. Put the specification work, tool-call analysis, and operational decisions beside the Model Context Protocol topic page, so the team reviewing the control is not reconstructing the design from incident notes.

Crelis puts the permission step in front of agent actions and records the outcome as evidence; GREENLIGHT is the runtime path for that decision, and the product demonstration starts from the places where agents touch money, customers, records, or infrastructure. OAuth remains necessary. It is not the evidence layer.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Who Authorizes an MCP Tool Call? — the companion piece on the tool-call decision.
• Identity Is Not Authorization Is Not Evidence — the basic separation behind the argument.
• Runtime Authorization vs Runtime Security — the distinction between threat detection and permission.
• Model Context Protocol.