Your MCP Agents Are Over-Privileged. Here's How to Fix It.

#llm #ai #devops #security

Your MCP agent can send emails, query your database, read files, create tickets, and push to GitHub — all from a single session token that nobody has reviewed since the day you set it up.

That's not a security posture. That's a trust problem waiting to become an incident.

Least privilege means the agent gets access to what it needs and nothing else. Not the full capabilities of the MCP server it connects to. Not every tool the server exposes. Just the ones required for the job.

Most MCP deployments do the opposite. Agents get configured with broad OAuth scopes and API tokens that grant access to entire systems because it's faster to set up, and nobody gets around to narrowing the scope once things are working. The agent either has access or it doesn't. There's no middle ground — until something goes wrong.

An Astrix Security analysis of 5,200+ open-source MCP servers found that over half rely on insecure long-lived static secrets like API keys and personal access tokens, while fewer than 9% use modern authentication like OAuth. And among those that do authenticate, it's almost always a single broad token gating the entire toolset. That's not access control. That's one key that opens every room in the building.

Why Over-Privileged Agents Are the Default

The incentives are all wrong at setup time.

When you're connecting an agent to an MCP server, the path of least resistance is maximum scope. Most OAuth flows ask what level of access to grant. Most teams click "full access" because they're not sure what the agent will need yet, and scoping down means more configuration work they'll do later. They don't do it later.

MCP server documentation often reinforces this. Early examples and quickstarts default to a single token with access to the entire toolset — it works, so teams copy the pattern. And since nothing breaks, there's no signal that something's wrong.

What you end up with is scope creep at the agent layer. One agent can write to your database. Another can send emails to external addresses. A third has read access to your entire file system. Each one was configured that way for a legitimate reason. But together? That's a massive blast radius if any single one gets compromised, makes a bad decision, or processes a malicious instruction embedded in a tool response.

The confused deputy problem in AI is real. Atlassian's MCP server had a flaw where attackers could embed malicious instructions in support tickets, exploiting internal users' privileged access when they processed those tickets with AI tools. Asana's MCP integration exposed cross-tenant data — project names, task descriptions, and metadata from separate organizations — for over a month after launch. These weren't sophisticated supply chain attacks. They were the predictable result of agents running with more access than they needed, and nobody checking closely enough who they were acting on behalf of.

What the Blast Radius Actually Looks Like

"Blast radius" sounds abstract until you walk through what actually happens.

Your email agent, in a compromised session, can send messages as you — to anyone, saying anything. Your file system agent can pull documents from directories it has no business touching. Your GitHub agent can push to branches that aren't its concern.

And none of this requires a sophisticated attacker. One malicious instruction embedded in a document the agent retrieves — content injection via a tool response — is enough. The agent can't tell the difference between your instructions and instructions that arrived in a retrieved file. Both hit its context window. Both shape what happens next.

The rug pull attack is one version of this: the external tool changes after approval. But over-privilege is an internal version of the same problem. You don't need an attacker to update a tool definition if the agent already has permission to do everything with the tools you've given it.

Least privilege is the structural limit on how bad it can get. It doesn't prevent the compromised session. It determines what the compromised session can actually do.

How to Apply Least Privilege at the MCP Layer

Three changes that actually move the needle:

Per-agent OAuth scopes instead of shared tokens. Your support agent doesn't need write access to your production database. Your scheduling agent doesn't need access to your file system. Give each agent its own OAuth scope, scoped to its actual function. Don't let them all share one token that happens to work. This is the same lesson cloud teams learned the hard way with IAM roles — never give a service account "Administrator" when "ReadOnly on specific resources" is what the job requires.

Tool allowlisting at the policy layer. Your MCP server exposes twenty tools. Your agent needs four. So define which four it's allowed to call. Not which tools are available — which ones that specific agent is cleared to invoke. There's a difference between what the server offers (capability) and what the agent is allowed to request (governance). You need both. Most deployments only have the first.

Ephemeral, task-scoped tokens for high-risk operations. Anything that can write, delete, send, or trigger downstream effects should run on a short-lived token scoped to that specific task. The token is valid for this invocation. When the task completes, it's gone. You can't do this everywhere — not every MCP integration supports it — but for the highest-risk tools in your stack, it's worth it. A compromised session where the token already expired is a completely different incident than one where a persistent credential is still live.

If you're running multi-tenant: this gets harder. When one MCP server serves agents acting on behalf of multiple users, you need tenant isolation at the tool invocation layer. An agent acting for User A cannot be allowed to invoke tools in ways that touch User B's data — even if the tool itself doesn't enforce that boundary. Build it into the policy configuration. Validate it at runtime. Don't assume the tool's own access control will handle it. The Asana incident was exactly this kind of failure.

The Registry Problem Nobody Talks About

There's a deeper problem behind all of this: most teams have no idea which agents have access to what.

Once you have more than a handful of agents, tracking the full picture — which agents exist, which MCP servers they connect to, what tokens they hold, what scopes those tokens actually grant — gets out of hand fast. A developer connects a new agent to an existing MCP server and inherits its token scope. Someone rotates a credential and doesn't update the docs. An MCP server adds a new tool category and nobody re-evaluates whether existing agents should have access.

You need an agent registry — a governed record of what agents exist, which tools they're permitted to use, and under what constraints. You can't narrow scope you can't see. You can't audit access you haven't documented. Before any of the above works, you need to know what each agent is currently allowed to do.

This is what separates a deployment that has thought about security from one that has thought about shipping.

How Waxell handles this: Waxell's Registry provides a versioned, governed record of every agent, its permitted tool set, and the policies under which it operates. Tool allowlisting at the policy layer defines which tools each agent can call — not just what the MCP server offers, but what that specific agent is cleared to request. Signal & Domain controls what data flows through tool call boundaries, which constrains what over-privileged access could actually reach. When a tool definition changes server-side, the registry detects the mismatch and blocks execution — so privilege drift from silent tool updates surfaces before it runs. Sign up →

Frequently Asked Questions

What is least privilege in the context of MCP agents?
Least privilege for MCP agents means each agent is granted only the tool access, OAuth scopes, and data permissions required for its specific function — not the full capabilities of the MCP server it connects to. In practice, this means separate OAuth credentials per agent type rather than shared tokens, explicit tool allowlisting at the governance layer, and defined constraints on what each agent can read, write, or trigger. The goal is to minimize blast radius: if an agent is compromised or makes an unexpected decision, what it can actually do is bounded by its assigned permissions, not by everything the server happens to support.

Why do most MCP agents end up over-privileged?
Because the path of least resistance at setup time is maximum scope. Most OAuth flows default to full access, MCP quickstarts use single shared tokens, and teams plan to narrow permissions later and don't. There's no immediate failure signal when an agent has more permissions than it needs — the problem is invisible until something goes wrong. The incentive structure favors getting things working fast over getting them scoped correctly, and in most organizations, nobody reviews MCP token scopes after initial configuration.

What is the confused deputy problem in MCP?
The confused deputy problem occurs when an MCP server executes actions with its own permissions rather than the permissions of the user or agent on whose behalf it's acting. If the MCP server has broader access than the user should have, a legitimate request can escalate into unauthorized data access — the server becomes a "confused deputy" acting on behalf of the attacker while believing it's serving the legitimate user. This is why MCP server permissions and the calling agent's scoped permissions both need to be validated at the tool invocation layer, not just at the authentication layer.

How do I apply least privilege to MCP tool access?
Three steps: first, issue separate OAuth credentials per agent type, scoped to only the permissions that agent actually requires. Second, define an explicit tool allowlist for each agent at the governance layer — not just what the server offers, but what that agent is cleared to request. Third, for any tool that can write, delete, send, or trigger downstream effects, consider short-lived task-scoped tokens that expire after use. As a baseline, document every agent and its effective permissions before making changes — you can't scope down access you haven't inventoried.

What's the real risk if my MCP agents are over-privileged?
The risk is blast radius from a compromised session. An agent with write access to your email system can send messages to any address. One with file system access can read from directories outside its concern. One with GitHub push permissions can commit to branches it has no business touching. None of this requires a sophisticated external attack — a single malicious instruction embedded in a tool response is often sufficient to trigger the behavior, because the agent processes content from its context window without distinguishing between your instructions and content that arrived via a tool call. Least privilege determines the outer boundary of what's possible in that scenario.

Is least privilege different for multi-tenant MCP deployments?
Yes, significantly. When one MCP server serves agents acting on behalf of multiple users, least privilege must enforce tenant isolation at the tool invocation layer — not just agent-type access control. An agent acting for User A must not be able to invoke tools in ways that expose or affect User B's data, even if the MCP server doesn't enforce that boundary internally. This requires explicit per-tenant scoping in the governance layer and runtime validation of which tenant context the agent is operating under. Most standard MCP setups don't include this by default.