Teams should treat OAuth as the start of the control model, not the end. A valid token proves identity and scope, but it does not prove that a request is safe in the current context. The practical next step is request-by-request authorization with tool-level policy, logging, and contextual checks before the MCP server executes anything.
Why OAuth alone is not enough for MCP apps
OAuth gives the MCP server a credentialed caller, but it does not tell the server whether the specific tool invocation is safe, expected, or appropriate in the current context. In MCP, that matters because the risky decision is often not “who are you?” but “should this tool action happen right now, against this resource, for this user, with these arguments?”
MCP’s authorization layer therefore has to sit on top of OAuth, not collapse into it. Teams need request-level policy that can distinguish benign calls from destructive or privacy-sensitive ones, even when the token is valid and the client is authenticated.
That is why the MCP Security Guide emphasizes the OAuth-based authorisation model, token passthrough risks, and tool poisoning as separate problems rather than a single auth checkbox. The same control gap also shows up in OAuth 2.0 and OpenID Connect Guide for Identity Teams, which explains why scopes and tokens are not a complete substitute for application-side authorization decisions.
Where the control boundary should move
The control boundary shifts from token acceptance to request evaluation. A strong MCP implementation checks the user, the client, the tool, the target resource, the requested action, and any context that changes risk, such as environment, dataset sensitivity, and whether the action is reversible.
That is especially important when an app can act on behalf of a user across multiple tools. A token that is valid for sign-in or API access may still be too broad for a particular tool action, and a generic scope can hide that mismatch until the server enforces finer-grained policy.
For that reason, audience restriction and token-bound resource design matter. The OAuth 2.0 Authorization Framework defines the base model, while Resource Indicators for OAuth 2.0 and OAuth 2.0 Protected Resource Metadata help align tokens with the intended resource server, which is a better fit for MCP-style tool access than a generic bearer token that can roam.
What good MCP security looks like in practice
Good MCP security makes the server the policy enforcement point, not the token validator alone. That means logging each tool call, validating the request context before execution, and refusing high-impact actions unless the policy engine can explain why the call is allowed.
It also means hardening the transport of trust. When stolen or replayed tokens are a realistic failure mode, sender-constrained options reduce the blast radius. The standards for that are well established in RFC 9700: Best Current Practice for OAuth 2.0 Security, OAuth 2.0 Demonstrating Proof of Possession (DPoP), and OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
When the MCP app is really part of a broader agentic workflow, the risk is not only unauthorised access but also tool misuse and privilege abuse. That is why the OWASP Agentic AI Top 10 is relevant here, especially the concerns around identity and privilege abuse, tool misuse, and supply-chain style trust failures.
Risk and Threat Considerations
OAuth creates a strong identity signal, but it also creates an attractive abuse path when teams treat it as sufficient authorization. A valid token can still be replayed, over-scoped, or used to trigger unsafe tool actions if the server does not re-check context and bound the action tightly.
Failure mechanism: The attacker, or even a misbehaving client, uses a legitimate token to invoke a tool in a way the user did not intend, often by exploiting broad scopes, token passthrough, weak audience restriction, or missing request-level policy.
Impact: The result can be data exposure, unauthorized side effects, destructive actions, or delegated abuse that is difficult to detect because the request still appears to come from a valid authenticated session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tool access can be abused when authenticated calls overreach delegated privilege. |
| ASI02 — Tool Misuse | MCP apps expose tool execution paths that can be misused despite valid OAuth. | |
| Recommendation — Enforce tool-level authorization to block identity and privilege abuse in agent-driven calls. Gate each tool invocation by policy before execution and log the decision. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP servers must authorize which functions a token holder may invoke, not just who they are. |
| Recommendation — Apply function-level authorization to every MCP action the server exposes. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | OAuth should be narrowed to the minimum rights each MCP request needs. |
| AU-2 — Event Logging | Request-by-request MCP authorization needs durable logs for review and detection. | |
| Recommendation — Limit each MCP token and tool path to the minimum privileges required. Log each tool decision with subject, action, resource, and policy outcome. | ||
Practitioner Guidance
What to prioritise: Put tool-level authorization and context checks ahead of convenience features. If the tool can read, write, delete, send, or trigger external side effects, it should not execute purely because OAuth succeeded.
What to verify: Confirm that the server enforces action-specific policy, records the decision basis, and rejects requests when the token is valid but the current tool invocation is outside the approved context or resource boundary.
Common mistake: Teams often stop at “the user is logged in” and miss that MCP requires a second decision point at tool execution time. That is where least privilege either holds or fails.
Practitioner takeaway: Treat OAuth as authentication and coarse delegation, then add explicit server-side authorization for every meaningful MCP tool call so that a valid token cannot become automatic permission.