OAuth on MCP: where does delegated action need fine-grained control?

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

View Full Forum →  |  NHI Foundation Course →