A wildcard or omnibus scope gives an agent's token every power at once, so a leaked or misused token reaches everything. MCP security guidance recommends a small starting scope of low risk operations, with elevation requested only when a privileged operation is first attempted.
What goes wrong
The MCP security best practices describe an attacker who obtains a token carrying broad scopes such as files, database or admin wildcards, granted up front because the server advertised every scope and the client requested them all. The listed risks are a larger blast radius, harder revocation, audit noise where one broad scope hides intent, and privilege chaining.
Broad versus designed scopes
| Property | Omnibus scope | Designed scopes |
|---|---|---|
| Blast radius if stolen | Everything | One function |
| Revocation | Disrupts all workflows | Targeted |
| Audit clarity | One scope for every call | Scope shows intent |
| User consent | Long scary list | Short and understandable |
| Elevation | Never needed | On first privileged use |
Mistakes the guidance lists
Publishing every scope in the supported list, using wildcard or omnibus scopes, bundling unrelated privileges to avoid future prompts, returning the full scope catalog in every challenge, and treating scopes claimed in a token as enough without server side authorization logic.
Steps to design better scopes
- Group tools by verb and by data area, not by product name.
- Make the baseline scope read only and low risk.
- Add separate scopes for write, delete and send, per data area.
- Have the server challenge for a specific scope when a privileged tool is first called, instead of asking for all of them at sign in.
- Accept down scoped tokens. OAuth itself allows the authorization server to grant less than requested and requires it to say what it granted (RFC 6749, section 3.3).
- Log elevation events with the requested and granted scopes.
Check the server too
A scope is a claim in a token. The server must still authorize each call. The guidance warns against trusting the claim without server side logic, so test that a token with only the read scope fails on a write tool.
Review existing tokens
List the scopes on every agent token in use. Any wildcard is a finding. Replace it with the smallest set that covers the agent's actual calls.
Safeguard offers MCP Guardrail and agent identity for applying this kind of policy to agent tool calls, and you can run a free scan of your own repositories at gold.safeguard.sh/scan. Autonomous fix pull requests are off by default, and every category starts on Manual.
Quick check
Is one admin scope simpler to manage?
Simpler to issue, harder to contain. A stolen admin token reaches everything and is painful to revoke.
What is the starting scope?
A minimal set of low risk read operations, with elevation requested later for privileged calls.
Sources
- MCP security best practices, Scope Minimization
- RFC 6749, section 3.3
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 19 October 2026.
