Excessive Permissions in MCP Servers

Excessive permissions in MCP means a server or its token can do far more than the task needs. A tool that only reads a calendar holds a token that can also delete events, send invites and read email. Nothing has gone wrong yet, but any mistake or attack now has a much bigger reach.

Permissions are what turn other MCP risks into real damage. A prompt injection against a read-only tool is a nuisance. The same injection against a tool with admin access is an incident.

This page explains how permissions grow too broad, how to spot it, and the least-privilege model the MCP spec recommends. Sources were checked on 28 October 2026.

What excessive permissions look like

There are three common forms.

1. Broad OAuth scopes. A remote server asks for every scope it might ever need, all at once.
2. Over-powered API keys. A local server is configured with an admin key because it was the easiest to create.
3. Full system access. A local server runs as your user, so it can read every file you can.

The MCP Security Best Practices page describes the first form in its "Scope Minimization" section. Its example is an attacker who steals a token carrying scopes like files:*, db:* and admin:*. Those were granted up front "because the MCP server exposed every scope in scopes_supported and the client requested them all."

Why it matters

The same page lists the risks of broad scopes:

• Expanded blast radius. A stolen broad token "enables unrelated tool/resource access."
• Privilege chaining. An attacker can "immediately invoke high-risk tools without further elevation prompts."
• Harder revocation. Revoking one max-privilege token disrupts every workflow.
• Audit noise. One omnibus scope hides what the user actually meant to do.
• Consent abandonment. Users decline dialogs that list too many scopes.

How permissions creep

OWASP's MCP02 entry focuses on how access grows over time. Temporary or narrow permissions expand "deliberately for convenience or accidentally through configuration drift."

One of its example scenarios is useful for any team. A repository write permission is granted for a test and never revoked. Later, an attacker's crafted pull request is auto-merged by the agent, and CI deploys a malicious dependency.

An illustrative scenario

This example is illustrative. It is not a real incident.

A marketing team connects its AI app to the company's cloud storage so it can read brand guidelines. The setup screen offers "full access" or a long list of individual scopes. Someone picks full access to save time.

Months later, a shared document contains a hidden instruction. The AI follows it and deletes a folder of signed contracts. The read-only job never needed delete rights.

Who is at risk

• Small teams that pick "full access" during setup because it is quicker.
• Developers who use personal admin tokens in local server configs.
• Organizations without a regular review of which AI tools hold which access.
• Servers that publish every possible scope in their metadata.

How to detect it

Ask four questions for each connected server:

1. What scopes or key permissions does it hold? Check the OAuth grant in the third-party account, or the API key's settings.
2. What does it actually use? Compare the granted scopes with the tools you use day to day.
3. When was access last reviewed? OWASP's MCP02 flags scopes and tokens with no enforced expiration as a warning sign.
4. Who or what acted? If logs cannot tell you which agent did what, OWASP treats that as a sign of exposure.

How to reduce the risk

On the server side

The spec recommends "a progressive, least-privilege scope model":

• Start with a minimal initial scope set, such as mcp:tools-basic, for "low-risk discovery/read operations."
• Ask for more only when needed, using targeted WWW-Authenticate scope="..." challenges.
• Accept tokens with fewer scopes than requested.
• Log elevation events, including the scopes requested and granted.

The spec also lists common mistakes to avoid:

On the client side

• Begin with baseline scopes and accept step-up prompts when a task needs more.
• Prefer read-only connections where the vendor offers them.
• Run local servers with limited file and network access. Our page on sandboxing local MCP servers explains how.

At the organization level

OWASP's MCP02 mitigations include least privilege by design, expiry-based and just-in-time access, per-agent identity, and automated entitlement reviews. In practice:

• Give each agent or integration its own identity and credentials.
• Set expiry dates on API keys and tokens.
• Review AI tool access quarterly, and after staff changes.

What the MCP spec says

The authorization specification says servers "SHOULD include a scope parameter" in their WWW-Authenticate challenge. It says this follows "the principle of least privilege and preventing clients from requesting excessive permissions."

It also defines a step-up flow. When a token lacks a needed scope, the server should respond with HTTP 403 and error="insufficient_scope". The client then asks the user for the extra scope.

One nuance is worth knowing. If a server's first challenge carries no scope, the spec tells clients to request all scopes in scopes_supported. That is why servers should keep that list minimal. For the OAuth basics, see MCP authentication and OAuth. For wider governance, see MCP for IT leaders.

Next step

Make a list of every AI tool connection and the access it holds, then cut anything unused. Our MCP readiness audit does this review and recommends the minimum scopes for each workflow. More guides are in the MCP Security Center.

Frequently asked questions