Notifications
Clear all
Topic starter
24/06/2026 7:08 pm
TL;DR: OAuth on MCP separates client authentication from tool-level authority, but the 2025-06-18 spec still requires tokens to be issued for the MCP server itself and not passed through to upstream APIs, according to PermitIO. The real governance failure is assuming bearer tokens alone can safely authorize agentic tool calls; they cannot.
NHIMG editorial — based on content published by PermitIO: OAuth on MCP: The Comprehensive Implementation Guide
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams govern delegated tool access in MCP environments?
A: Treat MCP as a protected resource with its own audience-bound tokens, then enforce policy at the tool-call layer.
Q: Why do bearer tokens create risk in MCP if they are reused across systems?
A: Bearer tokens become risky when they are portable across trust boundaries.
Q: What do security teams get wrong about OAuth scopes for AI tools?
A: They often treat scopes as if they were the whole authorization model.
Practitioner guidance
- Bind every MCP token to the correct resource audience Reject any token that was not issued specifically for the MCP server instance receiving the request.
- Enforce per-tool authorization at call time Evaluate tool name, arguments, tenant, user delegation, and runtime context before each tools/call request.
- Keep upstream API credentials inside the server boundary Store or broker GitHub and other upstream tokens on the MCP server side only, and never forward the client token unchanged to the upstream service.
What's in the full article
PermitIO's full article covers the implementation detail this post intentionally leaves at the architectural level:
- Exact OAuth discovery sequence using /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server
- Sample request and response flows for PKCE, dynamic client registration, and bearer token validation
- Concrete examples of how to map OAuth scopes to MCP tool classes without over-granting admin access
- Device authorization flow patterns for CLI-style MCP clients and constrained runtimes
👉 Read PermitIO's implementation guide for OAuth on MCP and delegated access →
OAuth on MCP: where does delegated action need fine-grained control?
Explore further
25/06/2026 4:17 am
OAuth on MCP only works when the MCP server remains a distinct protected resource. The spec’s discovery chain is not cosmetic. It separates the server that receives the request from the upstream systems the server may later call on behalf of the client. That boundary is what prevents token portability from becoming accidental system-wide authority. Practitioners should treat audience binding as the first governance control, not a detail left to implementation convenience.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should be accountable when an MCP server over-authorizes an agent?
A: The organisation operating the MCP server is accountable for the boundary it exposes, even when the agent is acting on a user’s behalf. If the server forwards tokens or accepts the wrong audience, the failure is in governance design, not in the user’s consent flow.
👉 Read our full editorial: OAuth on MCP exposes the boundary between login and delegated action
