The team operating the MCP server is accountable for enforcing protected-resource behavior correctly, including metadata discovery, 401 responses, token verification, issuer checks, and audience validation. The authorization server handles login, consent, and token issuance, but it does not replace the server’s responsibility to reject invalid or mis-scoped requests at runtime.
Why This Matters for Security Teams
A remote mcp server that issues and verifies OAuth tokens is not just an integration endpoint. It is a protected resource boundary that must authenticate requests, validate token scope, and reject misuse at runtime. If the server only assumes the authorization server did the hard work, attackers can reuse valid tokens against the wrong audience, exploit weak issuer checks, or trigger actions the server never intended to permit.
This matters because MCP deployments are already showing familiar patterns from prior OAuth incidents: token misuse, exposed secrets, and overly broad trust in upstream identity systems. NHIMG research on the State of MCP Server Security 2025 found that only 18% of mcp server deployments implement any form of access scoping for tool permissions, which means most servers still rely on implicit trust rather than enforceable authorization. That gap is exactly where real-world abuse starts.
Security teams often get this wrong by treating token issuance as the control point and the server as a passive consumer. In practice, many failures only surface after a stolen or mis-scoped token is already being used against production tools.
How It Works in Practice
The accountability split is simple in theory but easy to blur in implementation. The authorization server handles login, consent, and token issuance. The remote MCP server, as the protected resource, must verify that a presented token is authentic, intended for that server, and allowed to perform the requested action. That means checking issuer, audience, expiration, scope, and any tool-specific policy before returning data or executing side effects.
Current guidance from OAuth and security practitioners aligns with the protected-resource model: verification is not optional, and login upstream does not replace authorization downstream. The OAuth server can prove that a user authenticated, but it cannot know whether the MCP server is safe to expose a particular tool or dataset. For that reason, runtime enforcement belongs at the MCP server, supported by explicit metadata discovery, proper 401 responses, and narrow authorization decisions.
In practice, the strongest implementations combine token validation with workload-aware controls. A token alone should not be treated as the identity of the workload or the user intent. Security teams should map the request to a known audience, enforce least privilege on each tool call, and log rejected access attempts for review. This is especially important when the same server is reachable by multiple agents, plugins, or external clients.
- Validate token signature, issuer, audience, and expiry on every request.
- Return 401 for missing or invalid tokens, and 403 for authenticated but unauthorized actions.
- Scope tool access separately from user login and consent.
- Prefer short-lived credentials and automated revocation where possible.
- Test metadata discovery, error handling, and audience checks as part of security validation.
This model is reinforced by incidents such as the Salesloft OAuth token breach and the CoPhish OAuth Token Theft via Copilot Studio, where valid tokens became the attack path rather than the defense. These controls tend to break down when the MCP server trusts token presence more than token context, especially in multi-tenant environments with mixed tool sensitivity.
Common Variations and Edge Cases
Tighter token verification often increases integration overhead, requiring organisations to balance security assurance against client compatibility. That tradeoff becomes more visible when teams support multiple issuers, federated identity providers, or agents that refresh credentials automatically. Best practice is evolving, but there is no universal standard for how much context an MCP server must inspect beyond the core OAuth claims.
Some deployments extend protection with policy-as-code, request-time entitlement checks, or workload identity primitives, but those are layered controls, not substitutes for server-side verification. Others rely on gateway enforcement, which can help with central policy but still leaves the MCP server accountable for rejecting invalid or mis-scoped requests. The same is true for delegated access: consent is useful, but consent is not authorization for every downstream tool operation.
Two edge cases deserve special attention. First, if an MCP server is both a token consumer and a tool executor, teams must keep authentication failure handling separate from business logic so that malformed or replayed tokens cannot trigger partial execution. Second, if the server brokers access to sensitive upstream systems, it should not assume upstream permissions are automatically safe to inherit. The Guide to the Secret Sprawl Challenge and the OWASP Agentic AI Top 10 both reflect the broader pattern: once credentials become reusable across services, the server that accepts them remains on the hook for enforcing the boundary.
Security teams should therefore treat the remote MCP server as the enforcement point, not a passive API behind OAuth. Anything less leaves a gap between identity proof and actual authorization.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Token scope and rotation failures are common NHI risk points. |
| OWASP Agentic AI Top 10 | A1 | Agent tool use depends on runtime authorization, not static trust. |
| CSA MAESTRO | SR-2 | MAESTRO addresses access control for autonomous agent workflows. |
| NIST AI RMF | AI RMF governance fits runtime accountability for agent-driven access. | |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero trust requires explicit verification at each request boundary. |
Enforce short-lived, scoped credentials and verify they match the protected resource on every request.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
