The Model Context Protocol (MCP) was introduced as a single-vendor proposal for a standard way to connect language models to tools, data, and context. Eighteen months later it is the closest thing the AI tooling world has to a cross-vendor integration layer. Every frontier lab ships or supports an MCP client, the major IDEs run MCP servers, and there are thousands of community implementations. The ecosystem has matured faster than most observers predicted, but maturity has introduced a security posture that the original specification did not anticipate.
What Actually Got Adopted
Adoption broke across three tiers through 2025 and early 2026. The first tier was developer tooling. IDE-integrated assistants, code review bots, and local agent frameworks adopted MCP as their default integration layer because the alternative was a per-vendor integration matrix that nobody wanted to maintain. This tier drove the initial network effects.
The second tier was enterprise SaaS. Vendors that previously shipped bespoke plugins for each AI assistant now ship an MCP server and let the client pick. This pattern is visible across observability platforms, ticketing systems, identity providers, and most of the major data warehouses. The enterprise adoption has been quieter than the developer one, but it is the more commercially significant move.
The third tier, which is still underway, is platform consolidation. Cloud providers and agent platforms are embedding MCP into their execution environments, often with managed servers that handle authentication, rate limiting, and logging on behalf of the user. This is where the next round of competition will play out.
The Security Surfaces MCP Opened
MCP did not invent any new attack categories, but it concentrated several existing ones into a protocol surface that is easier to analyze and, unfortunately, easier to attack.
Tool description injection. An MCP server describes its tools to a client. A malicious or compromised server can describe tools in a way that influences model behavior, including convincing the model to call tools in unintended orders or with unintended arguments. This is prompt injection delivered through what the protocol treats as trusted metadata. Several high-quality reports through 2025 demonstrated the attack reliably, and the community has moved, slowly, toward client-side scrutiny of tool descriptions and toward signing conventions for server metadata.
Confused deputy through tool composition. When a model has access to multiple MCP servers simultaneously, outputs from one server can become inputs to another. A low-privilege server returning data that the model passes to a high-privilege server creates a confused deputy pattern. The protocol itself does not prevent this; only the client's orchestration logic can. In practice, orchestration logic varies wildly in quality, and the pattern is still underdetected.
Supply chain of servers. The MCP server ecosystem now includes thousands of community-published servers, many distributed through package registries with minimal review. The same typosquatting, abandoned-maintainer, and dependency confusion risks that plague npm and PyPI now apply here, with the additional complication that a malicious server is in a privileged position relative to the model's entire session. Several published incidents in late 2025 involved compromised servers delivering data exfiltration payloads.
Where the Ecosystem Is Consolidating
A year ago, the canonical MCP deployment was a developer running servers locally with a direct stdio connection to their IDE assistant. That pattern still exists but is no longer dominant. Three patterns have emerged.
Managed server registries. Enterprise platforms now offer curated registries of reviewed MCP servers. Employees can only connect to servers from the registry, and the registry operator signs metadata, tracks versions, and maintains a changelog of behavioral changes. This is analogous to the shift from arbitrary package installation to internal package mirrors, and it is the single most important security improvement in the ecosystem.
Gateway-based connections. Instead of a client connecting to many servers directly, connections are brokered through a gateway that handles authentication, policy enforcement, and logging. The gateway becomes a control plane for AI tool use, and it is increasingly where guardrails, data loss prevention, and audit functionality live.
Scoped credentials. Early MCP deployments often handed broad API tokens to servers that only needed a narrow slice. The emerging practice is to mint short-lived, scope-limited credentials per session, with the gateway enforcing scope against the tool being called. This aligns MCP tool use with the way modern service-to-service authentication works in the rest of the stack.
Protocol Evolution Under Security Pressure
The MCP specification has evolved noticeably under security pressure. Recent drafts include stronger guidance on tool metadata integrity, clearer semantics around consent flows for sensitive operations, and a more precise threat model in the security annex. These are not revolutionary changes, but they represent the protocol's authors acknowledging that the deployment surface is different from the original design assumptions.
A harder conversation, still unresolved, is how to handle the trust relationship between a client and a server that claims to represent a user's identity. The current protocol leaves this largely to implementations. Different clients have different defaults, and the asymmetries create interoperability gaps that attackers can probe. Expect a more opinionated specification here through 2026.
What Defenders Should Be Doing Now
For enterprises already operating MCP at any scale, three things are overdue in most environments. First, inventory the MCP servers in use, including ones installed on developer laptops. If you cannot list them, you cannot secure them. Second, route production MCP traffic through a gateway or at minimum log it centrally; unlogged tool calls are the equivalent of unlogged API traffic, and no modern security program tolerates the latter. Third, apply the same supply chain controls to MCP servers that you apply to other third-party software — review, signing, version pinning, and a process for emergency removal.
For vendors building on MCP, the competitive frontier is no longer "we support MCP." It is "we support MCP with enterprise-grade controls." Buyers are asking for SSO-integrated authentication, fine-grained tool-level audit logs, data residency controls, and the ability to disable servers centrally. Products that cannot answer these questions are losing deals to products that can.
The Direction of Travel
MCP's maturation resembles the maturation of other ubiquitous protocols. It started as a clever technical solution, gained adoption on usability, and is now being retrofitted with the governance and security affordances that enterprise deployment requires. The retrofit is not yet complete, and 2026 will probably bring at least one significant disclosed incident that pushes the specification and the tooling forward. That is the normal cycle for a protocol at this stage of its life.
The more interesting question is what happens when MCP becomes uninteresting — when it is assumed, boring plumbing, and the security conversation moves to what sits on top of it. That is probably eighteen months away. Between now and then, the security posture of every AI-adjacent organization will be shaped by how carefully they manage the MCP layer they almost certainly already depend on.