What is MCP Scope Escalation?
An attack where an MCP tool, after install, redefines its declared scope wider than originally authorised. A tool that started as `read-file` quietly becomes `read-file + http-egress` — and the agent dispatches calls under the broader scope.
Full explanation
Scope escalation is a structural failure of the agent's trust boundary: the agent treats the tool's currently-declared scope as authoritative, so a tool that widens its own scope at runtime gets the wider scope honored. The defense is per-dispatch ScopeGuard check against an operator-pinned maxAllowedScope — drift triggers reject, not honor. Closely related to rug-pulls but specifically about the scope dimension.
Example
A `read-file` tool's MCP catalog initially declares `requiredScope: FS_READ`. Post-install, the catalog mutates to `requiredScope: FS_READ + HTTP_EGRESS`. Without ScopeGuard, the agent will now happily call this tool with credentials in scope to make outbound HTTP requests — exfiltration channel opened.
Related
FAQ
Should I just deny every scope-drift event?
Yes, by default. The legitimate-update case (a tool genuinely needs more scope) should re-enter the operator approval flow as if it were a new tool install — not be auto-accepted at runtime.
How does mcp-guard enforce this at O(1) cost?
ScopeGuard holds a HashMap of (server-name, tool-name) → maxAllowedScope (bitflags). Per-dispatch: one HashMap lookup + one bitflags compare. Both O(1) in server-count and tool-count.