Server-side authorisation is better because it can evaluate current identity, live policy, and resource context at the moment of use. Token-only control freezes permission at issuance time, which is too static for multi-user systems where access needs to change as roles and organisational rules change.
Why Server-Side Authorization Matters for MCP
Model Context Protocol makes it easy for an AI client to request tools and data, but that convenience also makes token-only control too brittle for real operations. A bearer token can prove that something was authorised at issuance time; it cannot prove that the same access should still exist after a role change, a policy update, or a task shift. That gap is exactly where MCP risk grows, especially in environments with many users, many tools, and fast-changing permissions. The OWASP OWASP Top 10 for Agentic Applications 2026 and NHI guidance from NHI Management Group both point toward runtime enforcement, not static trust. In practice, the issue often becomes visible only after a token has been reused in a context its issuer never intended, rather than during access design.
NHIMG research shows how quickly secrets and access paths drift out of control: the State of MCP Server Security 2025 found that only 18% of mcp server deployments implement any form of access scoping for tool permissions. That is a strong signal that static token models are still being used where server-side policy checks are needed.
How It Works in Practice
Server-side authorization moves the decision point to the MCP server, where current identity, live policy, request intent, and resource context can all be evaluated together. That means access is not decided once at token issuance and then assumed forever. Instead, each tool call can be checked against the user’s current role, the agent’s current task, the target resource, and any environmental constraints such as tenant boundaries, data sensitivity, or approval state.
For MCP, this usually means the server validates more than the bearer token. A practical pattern is:
- Authenticate the caller and bind the request to a current workload or user identity.
- Evaluate policy at request time, not only at login or token minting.
- Apply least privilege to individual tools and parameters, not just to the whole session.
- Log the decision context so reviewers can see why access was granted or denied.
This approach aligns with runtime enforcement models described in the OWASP Agentic AI Top 10 and with the operational reality highlighted in NHI Management Group’s Guide to the Secret Sprawl Challenge, where long-lived credentials and broad access create hidden exposure. In a mature setup, the token becomes only one input to the decision, not the decision itself. This is especially important when an MCP server serves multiple teams or supports downstream actions that can change state, trigger workflows, or access regulated data. These controls tend to break down when legacy apps require opaque upstream tokens that cannot be re-evaluated server-side because the server lacks the context needed to make a fresh decision.
Common Variations and Edge Cases
Tighter server-side authorization often increases implementation overhead, requiring organisations to balance stronger control against protocol complexity and latency. That tradeoff is real, especially in early MCP deployments where teams want fast integration more than fine-grained governance. Current guidance suggests that token-only control may still be acceptable for low-risk, read-only tools, but best practice is evolving toward contextual checks as soon as tools can modify state, disclose sensitive data, or span multiple users.
Edge cases matter. Some MCP deployments use short-lived tokens and assume that TTL alone solves the problem, but expiry does not stop misuse inside the validity window. Others rely on upstream identity providers without mapping the request to the actual resource being touched, which leaves blind spots when a user’s role changes mid-session. The most common failure pattern is over-trusting a token that was minted for convenience but never designed to reflect current business intent. NHIMG’s State of MCP Server Security 2025 and incident patterns such as the Salesloft OAuth token breach both show why stolen or over-broad tokens are especially dangerous when servers do not re-check context. For server-side authorization to be effective, it must be paired with explicit tool scoping, strong audit logging, and policy that can change without reissuing every credential.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Token-only control fails when agent actions exceed intended scope. |
| CSA MAESTRO | MAESTRO emphasises contextual controls for agentic tool execution. | |
| NIST AI RMF | GOVERN | AI RMF governance supports decision accountability for dynamic AI access. |
Bind MCP authorisation to task context, tool scope, and continuous policy evaluation.
