Start with read scopes for the data the question needs, and add anything more only when a task requires it. The MCP security guidance recommends a minimal initial scope and incremental elevation. If a connector asks for admin or wildcard access on first sign-in, decline and ask the vendor why.
What the guidance says
The security best practices page treats scope minimization as its own topic. It warns that poor scope design increases the damage if a token leaks, adds friction, and hides audit detail. Its common mistakes list includes publishing every scope in the supported list, using wildcard or all access scopes, and bundling unrelated privileges to avoid future prompts.
The authorization specification adds the mechanism. A server can answer a request with a 403 and name the scopes needed, and the client can then ask for a higher level through a step-up flow. So broad access up front is not necessary.
A sensible scope ladder for security data
| Level | Example permission | When to grant |
|---|---|---|
| 1 | Read project and finding summaries | Always the starting point |
| 2 | Read full vulnerability details | When triage questions need it |
| 3 | Read sensitive exports | Rarely, for a named task |
| 4 | Create tickets or comments | After a trial of read access |
| 5 | Change policy or dismiss findings | Avoid in chat, keep in the product |
The ladder is an example, not a vendor scheme. Map your connector's real scopes onto it.
Red flags on the consent page
- A single scope that says all or full access.
- Write or admin scopes requested for a read only task.
- Scopes you cannot find explained in the vendor's documentation.
- A scope list that grows after a vendor update with no notice.
What the vendor should provide
- A scope reference with plain descriptions.
- A way to start with read only and elevate later.
- Audit entries that show which scope allowed which action.
- A statement of how the server challenges for more access.
What to do on your side
Decide your starting scopes in writing before the pilot. Give the pilot group only that level. Review the elevation events after two weeks. If people keep asking for the same higher scope, consider whether the ladder needs a new rung, rather than granting everything.
The cost of wide scopes
A leaked token with broad scopes lets an attacker use unrelated tools at once, and revoking it disrupts every workflow that used it. Narrow scopes mean a smaller incident and a faster recovery.
A worked example: designing scopes for a pilot
This is hypothetical. A team wants an assistant to help triage vulnerabilities. They list the jobs: see which projects have open critical findings, read details for one vulnerability, find which version fixes it, and open a ticket.
They map the jobs to scopes. Seeing projects and findings is a summary read. Details for one vulnerability is a deeper read. Finding the fix version is part of that detail. Opening a ticket is a write, in a different system.
They decide on the starting set: summary read and detail read, both limited to two projects. They do not grant the ticket write. After two weeks people are copying finding text into the ticket tool by hand, which is slow but safe. They then trial a ticket scope with approval prompts on, in a sandbox first.
Step by step: write a scope policy
- List every job the assistant should help with.
- For each, name the data it reads and anything it changes.
- Group jobs into levels from low to high risk.
- Set the starting level, and the project limit.
- Define who can approve a move up a level.
- Define the trial for each step up: sandbox, prompts on, a time limit.
- Define how you will review elevation events.
Table: poor scope design versus good
| Poor design | Better design |
|---|---|
| One scope called all | Separate read, write and admin scopes |
| Every scope requested at first sign in | Minimal first request, step up later |
| Scope names that mean nothing | Names that match tools |
| Scopes never reviewed | Quarterly review of grants |
| Elevation silent | Elevation logged with the scopes granted |
What the specification offers servers and clients
Servers can include a scope parameter in the challenge header to say which scopes the current operation needs. Clients should request only what is necessary and, for step up, combine the previous scopes with the new ones so they do not lose earlier permissions. The specification also tells clients to limit retries when an elevation keeps failing.
Reading the vendor's scope list
Ask for it as a table with columns for the scope name, what it allows, the tools that need it and whether it can change data. If the vendor cannot produce that table, the scope model is probably too coarse.
Scope drift
Watch for scopes that appear after a vendor update. A connector that began with a read scope and later asks for a write scope on reconnect deserves a new review, not a click through. Record the date of each grant so you can tell what changed.
Offboarding
When a person changes role, review their grants. Scopes accumulate quietly, and a clean review each quarter removes the ones nobody uses.
Where Safeguard fits
Safeguard's MCP Guardrail supports policy on which tools agents can use, a second layer that does not rely on scope design alone. Start by looking at what read access exposes using the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow the example conversation and list which scopes each step would need.
Quick check
Do read scopes expose sensitive data?
They can. Reads still return findings and asset details, so scope them to the projects needed.
Can a connector ask for more scopes later?
Yes. The specification describes step-up authorization after a 403 that names the scopes needed.
Who should approve a move to a higher scope?
The connector owner together with a security reviewer, with a sandbox trial first.
Sources
Last reviewed: 19 October 2026.
