MCP's Real Security Crisis: Why Permissions Matter More Than Patches

Anthropic launched its Model Context Protocol into production during late 2024, and adoption accelerated rapidly. Thousands of MCP servers now exist in the wild. Major technology firms including Microsoft, Google, and OpenAI have adopted it. The Linux Foundation assumed responsibility for maintaining the protocol. MCP now functions as critical infrastructure, sitting between AI agents and the tools and data those agents interact with. Most organizations deployed it using standard integration practices, accepting default configurations without modification.

By 2026, a clearer picture emerged: the actual threat wasn't located in the infrastructure layer itself. Instead, the vulnerability existed in the permission structures underneath. This distinction fundamentally changes how teams should approach MCP security. A software patch addresses a specific flaw in a particular server. A permissions overhaul demands asking difficult questions about why any given server needed access it never actually used.

The understanding that emerged in 2026 is that the problem wasn't in the infrastructure. The problem is in the permissions below this infrastructure.

The SANS 2026 Identity Threats Survey, which gathered responses from over 500 security professionals, documented that 76 percent of organizations experienced growth in non-human identities. Seventy-four percent of businesses operate AI systems that depend on standing credentials for autonomous operation. The same research showed that fewer than 40 percent of businesses employ protective measures including approval workflows, sandboxing, or audit trails.

Examining multiple security incidents reveals a consistent pattern. In May 2025, an attacker exploited prompt injection techniques targeting the GitHub MCP server to extract confidential repository information. The underlying cause wasn't a conventional software defect but rather a personal access token with permissions far exceeding what the task demanded. Shortly after, a logic error in an Asana MCP integration enabled unauthorized cross-tenant access because the permission layer failed to maintain customer isolation boundaries.

Security specialists now recognize these incidents as variations of two established attack vectors: tool poisoning, in which a server's tool description embeds covert instructions, and the confused deputy problem, where an agent gains more authority than its assigned task warrants.

What a permissions redesign actually asks you to check

The emerging consensus points toward compartmentalized access rather than improved detection tools. GitHub's Engineering Blog, which addresses secure remote MCP server development, recommends that each instance maintain its own secrets tailored to specific tasks, all requests remain scoped to the acting user, and authorization decisions rest on the action being performed rather than automatic approval following user authentication. Organizations should replace persistent, fixed tokens with temporary credentials generated dynamically as needed.

Replace fixed, permanent tokens with dynamic, temporary credentials generated on the fly.

This tiered approach has demonstrated effectiveness. At Webflow, MCP integrations receive the same security treatment applied to other third-party services that access customer information.

Each credential provisioned for an AI agent likely made sense when initially created. The difficult decision isn't whether that access was justified originally. Rather, it's determining whether it remains justified now—and most teams lack processes for making this determination. No review occurs until an incident forces the issue.

Organizations should evaluate these factors when integrating any MCP:

• What resources can this credential currently access, compared to its intended scope? Access permissions tend to expand over time, and no scheduled review will occur unless something fails.
• Does authorization operate at granular levels such as per-site, per-repository, or per-workspace, or does it function on an all-or-nothing basis? Integrations offering only organization-wide access warrant skepticism. If an integration lacks connection-time scope controls, that represents a critical finding.
• Does the AI agent inherit the human user's existing credentials, or does it generate entirely separate credentials that circumvent established permissions? The latter scenario allows a GitHub personal access token to possess greater repository access than the authorizing user.
• Does logging establish accountability for agent actions equivalent to human actions? If agent activities remain invisible or unattributable, incident response begins without foundational information.
• Do agent-initiated changes proceed directly to production, or do they flow through reviewable stages including draft, branch, and approval queues? This simply extends existing security practices for human access to a newer category of entity.

Identity comes before access

Determining what an agent may do requires first answering a more fundamental question: what constitutes an agent's identity? For most of the industry today, the truthful response is that agents function as human OAuth tokens in disguise. Agents lack independent identity. They borrow the scope, the potential damage radius, and frequently the actual credential of whoever initiated them.

Right now the honest answer for most of the industry is 'a human's OAuth token wearing a trenchcoat.'

This arrangement becomes problematic once agents transition from temporary to persistent. Current agents typically exist for minutes or hours: a task begins, the agent executes, it terminates. This pattern is changing. Future agents will operate for weeks or months, and entities with such extended lifespans require their own identity rather than borrowed credentials, with permissions that tighten rather than expand as the agent's lifespan increases.

Consider the distinction between a contractor hired for a single afternoon versus a contingent worker embedded in systems for an entire quarter. An afternoon contractor wouldn't receive a permanent access badge, and a quarter-long agent shouldn't receive the same access as a five-minute script.

OAuth wasn't designed for this scenario, and the limitation extends beyond missing features—it represents a structural incompatibility rooted in user experience design. The consent model assumes a human reviews a scope dialog and makes an informed decision. In practice, users skip reading scope lists and click approve. This already-fragile assumption disintegrates entirely when no human reviews anything.

The base specification contains no mechanism for designating "this client is an agent" or "this grant will run for six months," only server-determined expiration set after the fact. Several IETF drafts are beginning to outline potential solutions: linking token lifetime to actual task lifecycle and assigning agents stable identities separate from the human who invoked them. These remain early proposals rather than established standards.

The industry lacks consensus on where to draw the line between "short-lived task with broader access" and "long-lived agent with restricted access." Webflow's security team is actively exploring this question and exchanging insights with industry peers rather than claiming to have resolved it. However, the framing itself carries significance: agent lifespan should function as a primary input to permission models, not a secondary consideration.

Permissions aren't a checkbox at provisioning

A permissions overhaul, protocol revision, and identity framework represent three interconnected layers addressing the same underlying issue. For each layer to remain effective, the others must also function properly.

Creating a credential with appropriate scope on day one means nothing if nobody ever validates that the credential remains appropriate. Similarly, developing a new protocol that finally separates agents from their human originators provides minimal benefit if integrations continue defaulting to standing, all-or-nothing access. Neither approach resolves the core question both must address: what an agent may do should reflect how long it will exist.

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.

Currently, nearly all technology stack components lack the capability to pose this question, let alone answer it. Organizations that successfully navigate this challenge won't be those that built superior scanning capabilities. Rather, they will be organizations that abandoned treating scope, identity, and lifetime as three distinct evaluations occurring once per agent instance, and instead began treating them as an integrated setting requiring reassessment whenever the agent's function or existence changes.

Source: The New Stack