Tier an MCP server by what it can do, not by who made it. A server that reads public data is low risk. One that writes to internal systems or reads private data is medium. One that runs shell commands, holds secrets or touches production is high. Each tier gets a different approval path.
The tiering table
| Tier | What it can do | Examples of capability | Approval path |
|---|---|---|---|
| Low | Read public or non-sensitive data, no side effects | Look up documentation, read a public schema | Owner approves, listed in inventory |
| Medium | Read private data or write to a single internal system | Read tickets, create a draft document | Owner plus security review of scopes |
| High | Execute code, access secrets, change production, send messages outside | Run shell commands, deploy, email customers | Security review, human approval on each call, extra logging |
Why capability decides
OWASP's guidance on excessive agency advises avoiding open-ended extensions such as shell or URL fetch in favour of granular ones, and restricting downstream permissions to the minimum, for example read-only database access. A tiering scheme turns that advice into a routing rule. The more open-ended the tool, the higher the tier.
Questions to place a server
- Does any tool run code or shell commands? If yes, high.
- Does it hold or can it read credentials? If yes, high.
- Can it change anything outside the user's own sandbox? If yes, at least medium.
- Does it read data above public classification? If yes, at least medium.
- Does it fetch arbitrary URLs? Raise one tier, since fetched content can carry instructions.
Take the highest answer.
Where it runs matters too
The MCP security guidance warns that local servers run with the privileges of the client and can execute arbitrary commands, so a local server's tier should account for what that user can reach. A remote server shifts the question to authentication and what data leaves your network.
Do not trust labels
Servers can describe tools as safe. The specification says clients must treat tool annotations as untrusted unless they come from trusted servers. Read the tool list yourself and place the server on what the tools can actually do.
Re-tier when tools change
A server can add tools after approval. Check the tool list on each version change and when the server announces a list change. A medium server that adds a shell tool is now high.
Using the tiers
Give each tier a default: low in audit mode, medium with scoped credentials and logging, high only with a named owner and human approval for each call. See the rollout modes guide.
Try it yourself
Click through it at your own pace, or open it full screen.
As you set up, ask which tier the server would fall into and what you would want approved first.
Quick check
Is a popular server automatically lower risk?
No. Popularity says nothing about what the tools can do or how they are maintained.
Who owns the tiering?
Security owns the scheme. Each server owner applies it and security reviews the high tier.
Safeguard includes an MCP Guardrail and asset discovery to help you see and constrain servers, and a free scan covers dependencies.
Sources
- OWASP, LLM06:2025 Excessive Agency
- Model Context Protocol, Security Best Practices
- Model Context Protocol, Tools specification
Last reviewed: 19 October 2026.
