Because token validation only answers whether a credential is acceptable, not whether the request belongs in this session. MCP servers often expose tools that can reach production data or infrastructure, so the decision has to consider device trust, location, time, and session state. Without that context, valid access can still be unsafe.
Why token validation is not enough for MCP servers
token validation proves that a credential is real and not expired, but it does not prove the request is safe in the current context. MCP servers can expose tools with broad blast radius, so authorisation has to consider the session, the caller’s role, the target tool, and environmental signals before allowing an action.
For the protocol side of that model, the Model Context Protocol authorization specification treats servers as OAuth resource servers, which is the right starting point for audience-bound access rather than blind token acceptance. That matters because a valid token can still be the wrong token for the specific tool, resource, or interaction path.
What context-aware authorisation adds to the decision
Context-aware authorisation adds the question, “should this request be allowed here, now, and for this tool?” That can include device trust, location, time of day, session age, recent step-up, request purpose, and whether the tool invocation matches the user’s current task. The decision becomes risk-sensitive instead of purely credential-sensitive.
For MCP, that is especially important because a single server may front tools that read files, query internal systems, or trigger operational actions. A token says the caller authenticated; context-aware policy says whether this invocation still fits the expected trust boundary and the current session state.
The strongest practical pattern is to separate authentication from authorisation, then make authorisation fine-grained enough to distinguish safe and unsafe actions. The Authorisation Models Guide is useful here because MCP decisions often need more than coarse RBAC. Attribute- and policy-based checks are what let the server ask whether the request is appropriate for this user, this device, and this moment.
MCP servers also need to avoid treating a bearer token as a standing grant to everything behind the gateway. The MCP Security Guide covers the practical model: token passthrough, externalised authorisation, and the need to prevent confused deputy behaviour when a tool can reach privileged downstream systems. In other words, the token is necessary, but the policy decision is what keeps the server from becoming over-trusted.
Why valid access can still be unsafe
Token validation fails as a complete control when the threat is not “is this credential genuine?” but “is this request appropriate right now?” A stolen, replayed, or over-scoped token can pass validation and still be used in a session that no longer reflects the original trust conditions. That is why sender-constraining and audience restriction matter, but they still do not replace context-aware decisions.
For machine-to-machine access, context also helps limit lateral movement and tool abuse. A token that is valid for one resource, one time window, or one delegated task should not automatically authorise access to production data, infrastructure controls, or unrelated tools. The difference between “authenticated” and “allowed” becomes the difference between a contained request and a security incident.
That is also why the broader OAuth model is relevant. The RFC on resource indicators helps bind tokens to the intended audience, and the proof-of-possession standard helps reduce replay of stolen tokens. Those controls strengthen token handling, but MCP servers still need policy checks that understand session context and request intent.
There is also a governance angle: tools often act on behalf of users while touching systems with much higher privilege than the user directly holds. That is exactly the kind of trust gap where simple token acceptance breaks down. The token exchange standard is relevant because delegation and on-behalf-of flows need explicit scoping, not implicit reuse of an original access token.
Risk and Threat Considerations
When MCP servers rely on token validation alone, the main exposure is privilege misuse after authentication. A valid token can be replayed, over-scoped, or used from an unexpected session, which turns a normal request path into a route to production data or operational tooling.
Failure mechanism: The server accepts the credential without checking whether the request matches the current session, device, target tool, or delegation context, so a legitimate token can still authorize an unsafe action.
Impact: Attackers or over-permissive clients can reach tools they should not use, widen blast radius, and trigger data exposure, unauthorized changes, or lateral movement into downstream systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP servers need service-to-service trust checks beyond token validity. |
| AC-6 — Least Privilege | MCP tools should only allow the minimum access needed for the current task. | |
| IA-5 — Authenticator Management | Token handling, expiry, and replay resistance are central to MCP access safety. | |
| Recommendation — Use IA-9 to require contextual authentication and authorization for service calls. Apply AC-6 to constrain each tool and session to minimum necessary privilege. Use IA-5 to manage token lifecycle, scope, and rotation tightly. | ||
| OWASP ASVS | V8 — Authorization | MCP requests need per-action authorization, not just login validation. |
| V10 — OAuth and OIDC | MCP commonly relies on OAuth-style delegated access and audience binding. | |
| Recommendation — Use V8 to enforce authorization checks on each sensitive request. Use V10 to bind tokens to the correct client, audience, and delegation path. | ||
Practitioner Guidance
What to prioritise: Authorise each MCP tool call as a separate decision, not as a one-time login outcome. If the server can reach sensitive systems, require policy inputs that reflect the live session, not just the original token.
What to verify: Confirm that token audience, tool scope, and session context all line up before the request is permitted. If any of those differ, treat the request as a new risk decision rather than a routine continuation.
Common mistake: Teams often harden authentication and assume authorisation is therefore solved. For MCP, that leaves a gap between “who are you?” and “should this tool run now?” that attackers and misconfigured clients can exploit.
Practitioner takeaway: Token validation is a gate, but context-aware authorisation is the control that prevents a legitimate identity from making an unsafe request.
Related resources from NHI Mgmt Group
- Why do MCP workflows need context-aware authorization instead of RBAC alone?
- Why do MCP servers need external authorization servers instead of managing auth themselves?
- What breaks when an MCP server relies on token validation alone?
- What is the difference between token validation and policy-enforced authorization in MCP deployments?