OAuth Scope Misbinding in MCP
Agent AutonomyDescription
MCP 1.0 added OAuth 2.1 but the mapping between MCP tool capabilities and OAuth scopes is implementer-defined. Common bug: server requests a coarse scope (e.g. `repo` on GitHub) and exposes 20 tools, all of which inherit that scope. No mechanism exists in the spec to require per-tool scope. Result: tool that "reads issues" has the same authority as one that "deletes repos." Distinct from ZYR-AU-006 (Privilege Creep) by mechanism — Privilege Creep is silent expansion over time; this is a configuration-time vacuum.
GitHub MCP server requests `repo` scope. Among its 22 tools, 18 only need `public_repo` or read-only; 4 actually need `repo`. All 22 inherit `repo` because there is no per-tool scope mechanism. A TPA-D in any of the 22 tool descriptions can pivot the full scope.
Red-team evaluations of autonomous AI agents such as AutoGPT-class systems and tool-augmented LLMs have repeatedly demonstrated that agents invoke external tools and act on unvalidated outputs, including in security research published by Anthropic, DeepMind, and academic groups; however, a large-scale confirmed production incident specifically attributable to agentic tool invocation without output validation is not yet documented.
Primary mitigations
- Per-tool OAuth scope declaration enforced by client
- deny-by-default on coarse-scoped tools
- scope-narrowing proxy in front of MCP server
- explicit OAuth scope decoration in MCP server manifest
Detection signals
Single OAuth scope used across > 3 tools on a server; tool capabilities that obviously exceed declared scope (e.g. write tool with read-only scope); audit log of scope-to-tool ratios per server