MCP Tool Permissions: How to Apply Least Privilege to Your Agent's Tools

A lot of MCP setups end up with the same shape: someone installs a server, the client lists every tool it exposes, and the agent can call all of them with whatever token was pasted into the config. The server did nothing wrong. The permissions were simply never designed.

This piece is about that design, after install. If you have not decided whether a server deserves to be connected at all, start with how to vet an MCP server and come back. Here the question is narrower: of the tools you have connected, what should each one be allowed to do, with which credentials, and who says yes before it acts?

Why permissions matter more than detection

An agent decides which tool to call from text it reads, and some of that text is untrusted. I covered how that goes wrong in MCP prompt injection and the lethal trifecta, so I will not repeat it here. The short version for this article: you cannot guarantee the model will never be steered, so you cap what a steered model can reach. Permissions set the blast radius.

OWASP names this risk directly. LLM06:2025 Excessive Agency traces damaging agent actions to three root causes: excessive functionality, excessive permissions and excessive autonomy. Each step below targets one of them.

Where permissions live in an MCP setup

There is no single permission switch. Access is decided in four places, and least privilege means tightening each one:

1. The client config. Which servers are connected and which of their tools are enabled for the agent.
2. The server's credentials. The token or OAuth grant the server uses against the real system (GitHub, a database, a ticket tracker). The tool can do whatever that credential can do.
3. The host. Filesystem paths, network egress and environment variables the server process can touch.
4. A policy layer (optional). A gateway or proxy that sees every call and can allow, deny or hold it for approval.

The MCP spec itself keeps the protocol neutral here. The authorization specification is optional, and it applies to HTTP transports; stdio servers are expected to take credentials from the environment instead. So for a lot of local setups, "permissions" means the token in an environment variable plus whatever the client lets the agent call.

Step 1: Grade before you grant

Know the tool surface before you scope it. Look the server up in the MCP server directory, or run it through the Andrax MCP scanner, which grades against its own published rubric (mcpgrade-1.4.0, 39 checks). The grade tells you where the risk is: no auth, broad tools, shaky transport. It does not stop anything by itself. Hold that thought for Step 6.

Step 2: Default-deny tool allowlists

Enable only the tools the task needs. If the agent triages issues, it needs read and comment tools, not delete-repository or change-settings. OWASP's first mitigation for excessive agency is exactly this: minimize the extensions an agent may call, and minimize what each one does.

Two habits make the allowlist hold up over time:

• New tools start disabled. Servers can announce that their tool list changed (the spec's listChanged capability). Treat any tool that appears after an update as off until someone reviews it.
• Prefer narrow tools to open-ended ones. OWASP specifically warns against open-ended extensions such as "run a shell command" or "fetch any URL" when a specific tool would do. A write_report_file tool is easier to reason about than a general shell.

Step 3: Narrow the credentials

A tool's real power is its credential. Scope that, not just the tool list.

• One credential per server. Never share a token between servers. If one is compromised or misbehaves, revoking it should not break everything else.
• Read-only where the task allows. OWASP's example is an agent that only needs read access to a products table, enforced by database permissions on the identity it connects with, not by the prompt.
• Small scopes, raised when needed. The MCP security best practices describe a progressive model: start with a minimal scope set, and elevate through a targeted scope challenge only when a privileged operation is first attempted. The same page lists common mistakes worth checking your own setup against: wildcard or omnibus scopes (*, all, full-access), bundling unrelated privileges up front, and treating the scopes claimed in a token as enough without server-side authorization logic.
• Short-lived over long-lived. The authorization spec says authorization servers SHOULD issue short-lived access tokens to reduce the impact of leaked tokens.
• Check the audience on remote servers. The spec requires MCP servers to validate that a token was issued specifically for them, and forbids passing the client's token through to downstream APIs. If a remote server you run accepts any bearer token or forwards it upstream, fix that before tuning anything else.
• Act in the user's context. Where an agent acts for a specific person, OWASP recommends running the downstream call as that user with minimal privileges, for example via OAuth with the minimum scope, rather than through one shared high-privilege service account.

Step 4: Constrain arguments and the environment

An allowed tool can still be called with bad arguments. Limit what it can reach:

• Path allowlists for filesystem tools: one project directory, not the home directory.
• Egress allowlists for anything that makes network calls. The security best practices page says MCP clients SHOULD block private, loopback and link-local IP ranges when fetching OAuth URLs, and that server-side deployments should consider an egress proxy for those requests. The spec scopes this to OAuth; applying the same allowlist to tool traffic is our recommendation, not a spec requirement.
• No production secrets in the agent's environment. If a variable is visible to the server process, assume a tool can read it.
• Sandbox local servers. The best practices page tells clients to run local MCP server commands in a sandbox with minimal default privileges and restricted filesystem and network access, and to show the exact command before a one-click install runs it.

The tools specification puts part of this on the server too: servers MUST validate all tool inputs, implement proper access controls and rate limit tool invocations.

Step 5: Human approval for actions that change things

Writes, deletes, payments, deploys and sending messages should wait for a person. This is not just my preference. The tools specification says there SHOULD always be a human in the loop with the ability to deny tool invocations, and that clients SHOULD prompt for confirmation on sensitive operations and show tool inputs to the user before calling the server. OWASP's excessive-agency guidance says the same thing: require user approval for high-impact actions.

Two details decide whether approval actually protects you:

• Show the full parameters. "Allow send_email?" is not a decision. The recipient, subject and body are.
• Don't trust the tool's own labels. Tools can carry annotations that describe their behaviour, but the spec says clients MUST treat annotations as untrusted unless they come from trusted servers. A tool marked read-only by an unknown server is not proof that it is read-only. Base auto-approve rules on your own review, not the label.

Step 6: Enforce at runtime, and log every decision

Everything above is configuration, and configuration is a promise. A grade finds risk; a gate enforces policy. OWASP calls this complete mediation: authorization happens in a system outside the model, and every request through an extension is checked against policy rather than left to the LLM to decide.

In practice that means something sits on the call path, sees each tool call with its arguments, and allows, denies or holds it for approval. Whatever you use, log each decision: which tool, which arguments, which policy rule, who approved. OWASP lists logging, monitoring and rate limiting as the controls that limit damage when prevention misses, and the MCP best practices recommend logging scope elevation events with correlation IDs.

Least-privilege checklist

Where Guard fits

If you would rather not build the policy layer yourself, that is the part SentinelAgent Guard does. It sits in front of your MCP server and runs 22 controls on every call. Those 22 controls are Guard's runtime rubric (mcpgrade-2.0.0); they are a different thing from the scanner's 39 checks, and the two numbers should never be compared as scores. The free tier runs all 22 controls on one server. See Guard's Free and Pro plans.

Rubric fence: Andrax scanner grades are mcpgrade-1.4.0 (39 checks). SentinelAgent Guard's runtime is mcpgrade-2.0.0 (22 controls). Never equate the two scores.

FAQ

Does MCP have built-in permissions? Not as one feature. The protocol defines optional OAuth-based authorization for HTTP transports, including audience-bound tokens and scope challenges. Which tools an agent may call, and when a human must confirm, is left to the client and your own policy. The tools spec recommends a human in the loop but does not mandate a specific interaction model.

Is a scanner grade enough? No. A grade is a point-in-time view of risk. It does not restrict what the agent does at call time. Use it to decide what to scope, then enforce the scope.

Should I auto-approve read-only tools? Only for tools you have reviewed yourself, from servers you trust. Annotations from an untrusted server are not evidence, and even a genuine read can leak data if the agent can also send it somewhere.

Where should I start if I have a dozen servers connected? List every enabled tool, switch off what no task uses, then split shared tokens into per-server credentials. Those two changes cut the most blast radius for the least effort. For a quick reference afterwards, keep the MCP security cheat sheet open.