MCP server security: how to set tool permissions and decide trust

Secure an MCP server by deciding three things up front: which tools exist, who may call each one, and what happens when the model is wrong. Start with a short allowlist of read-only tools, require human approval for anything that changes state, scope tokens narrowly, and treat every server you did not write as untrusted.

The Model Context Protocol lets an assistant call tools on a server. That is the point, and it is also the risk. This explainer follows the MCP specification's own security guidance and OWASP's excessive agency entry. It stays defensive.

What does the MCP spec say about tools and trust?

The tools section of the 2025-06-18 specification says there SHOULD always be a human in the loop with the ability to deny tool invocations. It also says clients should consider tool annotations untrusted unless they come from trusted servers. In plain terms: a tool's own description is a claim made by the server, so a hostile server can describe a dangerous tool as harmless.

The separate security guidance page lists specific attack classes. Four matter most for day-to-day permission design:

• Confused deputy. A proxy MCP server that talks to a third-party API can be tricked into getting authorization codes without proper user consent, when static client IDs, dynamic client registration and consent cookies combine badly.
• Token passthrough. A server accepts a client's token and forwards it downstream without checking it was issued for that server. The spec forbids this. It lets callers bypass controls like rate limits and muddies the audit trail.
• Scope inflation. If a server advertises every scope and the client requests them all, one leaked token opens everything. The spec recommends minimal scopes.
• Local server compromise. A local server runs on the user's machine with access to the system. A malicious startup command in a client configuration, a tampered server binary, or an insecure server left running on localhost are the cases the spec describes.

How should you design tool permissions?

Think in tiers, and apply the tiers per tool rather than per server.

1. Read-only tools on by default. Listing and fetching data. Safe to approve in bulk.
2. State-changing tools off by default. Creating tickets, starting scans, editing records. Turn them on deliberately, for named use cases.
3. Irreversible or high-impact tools gated by a person. Deleting data, moving money, running shell commands, touching credentials. Require approval for every call.

OWASP's excessive agency entry gives the reasons: excessive functionality (tools the task does not need), excessive permissions (a database tool that can write when it only needs to read) and excessive autonomy (high-impact actions with no confirmation). Its fixes are the same: minimize extensions, minimize what each can do, run them with the user's own permissions, and require approval for high-impact actions.

What does this look like in a real product?

Safeguard's hosted MCP server follows this tiering. Its docs say a new workspace starts with six read-only tools, such as listing projects and listing vulnerabilities, and every other tool ships disabled until a tenant administrator turns it on. Each tool has its own feature flag, and a call to a tool that is not enabled is rejected. If tool resolution fails, the server falls back to the small default set instead of widening access. The server is hosted, so there is no local package to run, and the docs warn to treat any package claiming to be the Safeguard MCP server as untrusted.

For servers you build or front yourself, Safeguard's docs describe Guard, which evaluates MCP tool calls against a policy that resolves to allow, deny or monitor, either inside your process or as a proxy. Guard is in early access, so confirm availability before planning around it.

Open the MCP guardrail demo in its own page.

Where do these controls fall short?

Allowlists cannot tell a good call from a bad call to an allowed tool. A read-only tool can still return sensitive data, and returned text can carry injected instructions into the model. Approval prompts also wear out, so reserve them for calls that matter. Finally, the spec's guidance covers the protocol, not the server's own code: a server with an injection bug is still vulnerable.

What to do

1. Inventory the MCP servers your team uses, including local ones in editor configs.
2. For each server, list tools and mark read-only, state-changing or high-impact.
3. Enable the read-only set first and add others one at a time with a reason.
4. Require human approval for high-impact tools. Do not auto-approve in shared environments.
5. Check that each server validates tokens issued for itself and never passes client tokens downstream.
6. Review local server startup commands before running them, the way you would review an install script.
7. Log tool calls with caller, tool and arguments, and review them.

Quick check

Sources

• MCP specification, security guidance page
• MCP specification, Authorization
• MCP specification, Tools
• OWASP LLM06:2025 Excessive Agency
• Safeguard MCP tool availability and gating
• Safeguard Guard SDK

Last reviewed: 18 October 2026.