The MCP specification describes an authorization flow for HTTP-based transport. This answers how a client obtains and presents access to a protected MCP resource. It does not make every tool call to that resource appropriate for every task.
01 / Read the source
What the primary material says
The specification uses OAuth-related discovery and resource indicators; servers must validate tokens intended for them. Tools are separately exposed by MCP servers. A token’s audience, scopes and validity are necessary checks, but an enterprise payment or infrastructure action also has a target, parameter values, business purpose and effect that the transport protocol cannot approve on behalf of an organization.
MCP also supports deployments where the HTTP authorization flow is not the relevant boundary, such as local integrations. A statement about remote OAuth does not automatically apply to every MCP host/server pairing. Tool annotations and descriptions can change and should not be treated as authoritative policy. The exact applicable specification version belongs in any implementation guide.
02 / Architectural consequence
Where the trust boundary changes
An invoice agent with a valid MCP token may call read_invoice and release_payment through one server. The first can be in scope while the second exceeds the delegated task. If a server uses its own broad downstream credential, the gap is even sharper: the enterprise API sees the server, not necessarily the child agent or human whose task caused the call.
Two decisions in one tool flow
First the remote MCP resource must validate the client’s token and intended audience. Then the tool invocation needs a decision about the named tool, normalized arguments and current principal/task. Those decisions can occur in different components. A gateway may centralize the first and some of the second, while the downstream payment or cloud service has the final effect. Architects should draw each component and mark where an alternate route could bypass inspection. The MCP specification’s OAuth flow is not defective because it leaves business authorization to implementers; the error is treating a transport token as proof of every business action.
03 / ProofGrid analysis
Authority beyond the credential
The useful boundary is a per-call PEP at the server, gateway or executor that sees tool name, normalized arguments, caller and task. The final protected system must not have an unchecked alternate route. ProofGrid’s approach is to make the origin and narrowing of authority reviewable at that point; ProofGrid enforces this authority boundary without claiming to be the MCP gateway.
04 / A testable next step
What a security architect can do
Test wrong-audience tokens, broad token scopes, changes of target within one tool, and a direct path around any gateway. Correlate the protocol authentication event with the tool decision and observed downstream effect.
Does the server validate resource indicators and token audience? Which component knows the user and agent task? Can it inspect beneficiary and amount, or only the tool name? Does the downstream API accept a broad server credential over another route? A useful evaluation demonstrates one valid token and one denied tool effect, then verifies no bypass succeeds.
Primary sources
Read the documents
Durable references