Because they freeze authorisation state at issuance, while roles, projects, and policy expectations keep changing. If the token carries too much logic, it becomes hard to manage and slow to adapt. If it carries too little, the server cannot enforce current least privilege. The practical answer is to re-evaluate permission at the server on every request.
Why static OAuth tokens break down in MCP environments
Static OAuth tokens are attractive because they are easy to issue and easy to pass around, but they only work when the access decision is expected to stay stable. MCP usage is usually the opposite: tools, scopes, servers, and delegated actions can change as the session evolves. That means the token can quickly become stale, overbroad, or too rigid for the server to trust as the sole source of permission.
The core problem is that a token is a snapshot, while MCP permissions behave more like a live policy decision. If the token is made to carry every rule, it becomes brittle and hard to govern. If it carries only coarse authority, the server has to make the current decision itself. That is why re-checking authorization at the server is usually the safer design.
For the protocol context behind that model, RFC 6749: The OAuth 2.0 Authorization Framework defines the grant and token model, while the Model Context Protocol: Authorization specification treats MCP servers as OAuth 2.1 resource servers with audience-bound tokens rather than generic bearer pass-through.
What goes wrong when permission is frozen into the token
Static tokens create a mismatch between authorization time and use time. A user may lose a role, a project may close, a scope may be narrowed, or a tool may become sensitive after the token was issued. If the server keeps trusting the old token without re-evaluating context, the caller can retain access that no longer matches current policy.
This becomes especially awkward when the token is asked to do too much work. You may see bloated scope sets, special-case exceptions, and difficult revocation logic because the access decision has been pushed into a portable credential. That design is convenient for transport, but weak for changing permissions, because revocation and least privilege become delayed rather than immediate.
The practical trade-off is simple: the more authority a token carries on its own, the less adaptable the system becomes. The more the server checks policy at request time, the more current and enforceable the access decision is. In MCP, that live decision is what keeps tool access aligned to the actual request and the current server state.
Why MCP needs request-time authorization rather than static trust
MCP adds another layer of complexity because the same agent or client may talk to multiple servers, tools, and resources with different risk profiles. A single static token cannot reliably express every change in audience, tool sensitivity, or delegation boundary without becoming overcomplicated. That is why MCP authorization guidance emphasises the server as the enforcement point.
Re-evaluating permission on each request allows the server to enforce current least privilege, reject stale authority, and apply resource-specific checks that a generic bearer token cannot safely encode. It also helps limit confused-deputy behaviour, where a broadly trusted token is reused in a context the original policy never intended.
For readers who want the protocol detail, the authorization model in the MCP spec and the OAuth resource and security standards around it are the right reference points, especially when designing audience restriction, delegation, and token handling policies that must survive changing permissions.
Risk and Threat Considerations
Static tokens in a dynamic permission system create a durable attack surface. If a token is stolen, replayed, or accidentally left valid after a role change, the attacker or an over-privileged client may retain access longer than the current policy would allow. The risk grows when tokens are reused across tools, environments, or delegated workflows.
Failure mechanism: The server treats a token as a standing authorization grant instead of re-checking current policy, so stale scope or audience assumptions keep working after the real permissions have changed.
Impact: Excessive access can persist, revocation loses effectiveness, and compromised or misused tokens can reach tools or data that should now be denied.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity 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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Static tokens need lifecycle limits and revocation to avoid stale access. |
| AC-6 — Least Privilege | MCP permissions must stay narrowly scoped as roles and tool access change. | |
| AC-3 — Access Enforcement | The server must enforce current authorization, not just trust the token. | |
| Recommendation — Set token TTLs, rotation, and revocation rules so stale authorization cannot persist. Re-evaluate effective privilege on each request and deny excess access by default. Enforce access at the resource server and verify permission before every action. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Bearer token misuse and replay are core OAuth token risks in API-style access. |
| API5 — Broken Function Level Authorization | MCP tools require action-level checks beyond token possession. | |
| API10 — Unsafe Consumption of APIs | Clients that consume MCP-like APIs unsafely may overtrust static bearer tokens. | |
| Recommendation — Harden token handling so stolen or stale bearer tokens cannot be reused. Check function-level authorization on each tool invocation, not just at login. Treat upstream tokens as insufficient and validate downstream authorization independently. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Machine tokens commonly accumulate excess authority when permissions drift. |
| NHI-07 — Long-Lived Secrets | Static OAuth tokens behave like long-lived secrets when policy changes over time. | |
| NHI-09 — NHI Reuse | Reused tokens across tools or servers widen blast radius when permissions differ. | |
| Recommendation — Scope non-human credentials to current need and remove unused access promptly. Prefer short-lived secrets and explicit renewal paths over permanent bearer tokens. Avoid reusing one token across multiple services or trust boundaries. | ||
Practitioner Guidance
What to verify: Confirm that the server can make an authorization decision on every request using current policy, not only the claims embedded in the token. If the design cannot explain how revoked, narrowed, or relocated access is blocked immediately, the model is too static.
Decision rule: Use short-lived credentials or narrow tokens for transport, but treat the server as the source of truth for authorization. If a permission change must take effect now, do not rely on token expiry as the control that enforces it.
What good looks like: The token identifies the caller and the intended audience, while the server still checks whether the caller may perform the specific action on the specific resource at that moment.
Practitioner takeaway: Static tokens can authenticate a session, but they should not be trusted to preserve permission correctness in a system where roles, tools, and policy move independently of token lifetime.