OAuth on MCP is not the same as authorizing each tool call

A developer argues that OAuth on the Model Context Protocol (MCP) only establishes caller identity and does not by itself authorize individual tool calls, a gap that matters as the 2026-07-28 MCP spec adds issuer validation, the CIMD direction, and Mcp-Method/Mcp-Name headers. The write-up recommends tiering requests by risk — treating read_ticket differently from issue_refund or drop_table — and using an MCP client → gateway → PDP → MCP server pattern with deny-by-default and step-up checks for high-risk operations.

OAuth on MCP answers “who is calling?” It does not, by itself, answer whether a particular tools/call should run. The 2026-07-28 MCP spec tightens auth and routing with issuer validation, the CIMD direction, and Mcp-Method / Mcp-Name headers. Those are useful signals, but authentication is still only one decision: AuthN verifies who is calling; tool-call authorization asks whether this principal may run this tool, on this resource, in this context, right now. That context matters for risk. A read ticket should not necessarily get the same friction as issue refund , and neither should be treated like drop table . Use the method/name headers to help tier the request. A practical pattern is MCP client → gateway → PDP → MCP server , with deny-by-default and step-up checks for high-risk operations. We wrote about the distinction and the practical design in our write-up https://www.permit.io/blog/mcp-auth-vs-tool-call-authorization-2026-07-28 .