Why MCP security is about permissions overhaul

Why MCP Security is About Permissions Overhaul

Anthropic's Model Context Protocol (MCP) went into production in late 2024. It spread rapidly after that. Since then, thousands of MCP servers have been created. Microsoft, Google, and OpenAI embraced it. The Linux Foundation took over protocol maintenance. Today, MCP is considered critical infrastructure. It sits between an AI agent and the tools and data it interacts with. Most teams implemented it the same way they implement any other integration standard. People installed it and trusted the defaults.

The Problem is in the Permissions

The understanding that emerged in 2026 is that the problem wasn't in the infrastructure. The problem is in the permissions below this infrastructure. This matters because it changes how people approach MCP security problems. A patch solves a specific problem on a particular server. The permission change requires asking a complicated question. "Why did that particular server require access to something it never needed to be there?"

The Root Cause of MCP Security Issues

According to the SANS 2026 Identity Threats Survey, which surveyed more than 500 security experts, 76 percent of businesses noted an increase in non-human identities. 74 percent of businesses use AI systems that rely on standing credentials to work independently. This same survey revealed that none of the protection measures, such as approval processes, sandboxing, or logging, is used by more than 40 percent of businesses. Look past the individual disclosures, and the same root cause keeps showing up.

Patterns in MCP Security Issues

In May 2025, an attacker used prompt injection against the GitHub MCP server to pull private repository data, not because the server had a bug in the traditional sense, but because the personal access token behind it was scoped far wider than the task required. Days later, a logic flaw in an Asana MCP integration allowed cross-tenant access because the permission layer never enforced the isolation boundary between customers. Security researchers now group it under a couple of recognizable patterns: tool poisoning, where a server's own tool description carries hidden instructions, and the confused deputy problem, where an agent inherits more trust than the task in front of it requires.

Compartmentalizing Access

The solution that keeps coming up isn't a better scanner, but compartmentalizing access. GitHub's Engineering Blog suggests the following:

• Every instance must have its own secrets for the specific task.
• All requests must be limited to the acting user.
• Authorization must be based on action rather than assumed after user authentication.
• Replace fixed, permanent tokens with dynamic, temporary credentials generated on the fly.

Integrating MCP: Considerations

Some things to consider while integrating any MCP:

• What can this credential reach now, rather than the scope for which it was intended?
• Is authorization granted on a per-site, per-repository, or per-Workspace basis, or all or nothing?
• Does the AI agent inherit the person's existing credentials, or create entirely new credentials that bypass those permissions?
• Does logging assign accountability for what the agent does in the same way it does for a human?
• Do changes from the agent go straight into production, or do they pass through a reviewable process like draft, branch, and approval queue first?

Identity Comes Before Access

Before you can talk about what an agent is allowed to do, you have to answer a harder question: what is an agent, identity-wise? Right now the honest answer for most of the industry is "a human's OAuth token wearing a trenchcoat." The agent doesn't have its own identity. It inherits the scope, the blast radius, and often the literal credential of whoever spun it up. That's a problem the moment agents stop being ephemeral.

The Teams Who Get It Right

The teams who get this right will be the teams who stopped viewing scope, identity, and lifetime as three separate evaluations, and began treating them as a single setting. Right now, nearly all components of the technology stack don't know how to ask that question, much less answer it. The teams who get this right will not be the ones who developed a more efficient scanning tool. Rather, they will be the teams who stopped viewing scope, identity, and lifetime as three separate evaluations that occur once per agent instance, and began treating them as a single setting that must be evaluated each time the agent's function or existence changes.