When Anthropic's Model Context Protocol reached production in late 2024, adoption accelerated rapidly. Thousands of MCP servers emerged as Microsoft, Google, and OpenAI integrated the technology, with the Linux Foundation assuming stewardship of the protocol. Today, MCP functions as critical infrastructure, mediating between AI agents and the tools and data they access. Most organizations deployed it using standard integration practices, accepting default configurations without deeper scrutiny.
By 2026, a clearer picture emerged: the vulnerability wasn't architectural. 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 distinction fundamentally shifts how teams approach MCP security. Patching addresses isolated flaws on specific servers, whereas permission redesign demands asking uncomfortable questions about why particular servers need access they may never actually use.
The SANS 2026 Identity Threats Survey, encompassing responses from over 500 security professionals, documented the scale of the challenge. Seventy-six percent of organizations reported growth in non-human identities, while 74 percent operate AI systems dependent on standing credentials for autonomous operation. Yet protection mechanisms—approval workflows, sandboxing, audit trails—see adoption in fewer than 40 percent of businesses.
Examining specific incidents reveals recurring patterns. In May 2025, an attacker exploited prompt injection against the GitHub MCP server to exfiltrate private repository data. The root cause wasn't a traditional software defect; rather, the personal access token possessed far broader permissions than the integration's actual requirements. Shortly after, a logic error in an Asana MCP connector enabled cross-tenant access because permission boundaries between customers lacked enforcement.
Security researchers now categorize these failures under established threat models: tool poisoning, where server tool descriptions embed covert instructions, and the confused deputy problem, where an agent operates with more authority than its assigned task warrants.
What a permissions redesign actually asks you to check
The emerging consensus points toward compartmentalization rather than advanced detection tools. GitHub's Engineering Blog, addressing secure remote MCP server development, recommends that each instance maintain isolated secrets for its specific function, all requests remain scoped to the acting user, and authorization decisions derive from action-based rules rather than post-authentication assumptions. Replace fixed, permanent tokens with dynamic, temporary credentials generated on the fly.
This layered approach has proven effective. At Webflow, MCP integrations receive the same scrutiny applied to third-party components with customer data access. When teams initially provision credentials for AI agents, the decision typically appears sound. The harder question—whether that access remains appropriate—rarely receives scheduled review until an incident forces reconsideration.
Several critical dimensions warrant evaluation during any MCP integration:
- Compare current credential reach against intended scope; access boundaries tend to expand without scheduled reassessment until failures occur.
- Determine whether authorization operates at granular levels (per-site, per-repository, per-workspace) or applies organization-wide; integrations offering only all-or-nothing access warrant skepticism, and those lacking connection-time scope controls represent a finding rather than a minor detail.
- Establish whether the AI agent inherits existing user credentials or generates entirely new ones that circumvent established permissions; the latter scenario allows a GitHub personal access token to access repositories beyond what the authorizing user can reach.
- Verify that logging attributes agent actions with the same accountability applied to human activities; invisible or unattributable agent behavior leaves incident response starting from zero.
- Confirm whether agent changes proceed directly to production or flow through reviewable stages like drafts, branches, and approval queues; this extends existing human access control discipline to newer entity types.
Identity comes before access
Establishing 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 honest response is a human's OAuth token wearing a trenchcoat. Agents lack independent identity; they assume the scope, blast radius, and frequently the literal credentials of whoever initiated them.
This arrangement functions adequately while agents remain ephemeral. Current agents typically operate for minutes or hours—task initiation, execution, termination. This pattern is shifting. Agents operating for weeks or months will require their own identities, not borrowed ones, with permissions that tighten rather than expand as lifespan increases.
The distinction parallels contractor engagement models: an afternoon contractor wouldn't receive a permanent badge, and a quarter-long agent shouldn't inherit the same access as a five-minute script.
OAuth's design predates this requirement. The mismatch runs deeper than missing features; it reflects structural incompatibility rooted in user experience assumptions. The consent model assumes a human reviews a scope dialog and makes an informed decision. Reality diverges sharply: users rarely read scope lists before clicking allow. This already-fragile assumption collapses entirely when no human reviews anything.
The base specification lacks concepts like "this client is an agent" or "this grant runs for six months," relying instead on server-imposed expiration. Early IETF drafts sketch potential solutions: binding token lifetime to actual task lifecycle and assigning agents stable identities distinct from their human initiators. These remain preliminary proposals rather than deployed standards.
The industry lacks consensus on where boundaries fall between "short-lived task with broader access" and "long-lived agent with restricted permissions." Webflow's security team actively explores this question and exchanges insights with industry peers rather than claiming resolution. The framing itself matters: treat agent lifespan as a primary input to permission models, not a secondary consideration.
Permissions aren't a checkbox at provisioning
Permission redesign, protocol evolution, and identity models address three distinct layers of the same underlying problem. Each layer's effectiveness depends on the others remaining effective.
Creating correctly scoped credentials on day one yields no benefit if nobody verifies their continued validity. Similarly, developing a protocol that finally distinguishes agents from their human originators accomplishes little if integrations continue defaulting to standing, all-or-nothing access. Neither approach resolves the foundational question: what an agent may do should correlate with how long it will exist.
Currently, nearly all technology stack components lack the capability to pose this question, let alone answer it. 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. Success belongs not to organizations that build more efficient scanning tools, but to those treating scope, identity, and lifetime not as three independent decisions made once per agent, but as a unified configuration requiring reassessment whenever agent function or existence changes.