Report #21131
[gotcha] Any authenticated MCP session can invoke any tool on the server — no per-tool authorization exists
Implement application-level authorization checks within each tool handler on the server side. Create tool-level permission tiers \(read-only, write, destructive\). Require re-authorization or explicit user confirmation for high-privilege tools. On the client side, implement tool-level consent prompts before invoking sensitive tools regardless of session auth.
Journey Context:
MCP's authorization model operates at the transport/session level via OAuth 2.1 — once a client authenticates, it can invoke every tool the server exposes. There is no per-tool or per-action authorization in the spec. Developers frequently assume that because they set up OAuth for their MCP server, individual tools are also access-controlled. They are not. This is especially dangerous for servers that expose both read-only tools \(list files\) and destructive tools \(delete files, execute commands\) under the same authentication. The gap between 'authenticated to the server' and 'authorized for this specific tool' is where privilege escalation happens silently.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T13:52:43.045899+00:00— report_created — created