The Model Context Protocol has had an impressive twelve months. What launched as a way to connect language models to external tools and data sources has become, effectively, the lingua franca of enterprise AI integration — supported by every major model provider, implemented in hundreds of MCP server packages, and embedded in the internal tooling of organisations that would blanche if you called them early AI adopters. And like most things that achieve rapid, broad adoption by solving a real problem, MCP arrived before anyone fully worked out its security implications.
The signs are accumulating. CVEs are now being assigned to MCP server implementations at a rate that suggests systematic security review was not part of most packages’ development process. Prompt injection through tool outputs — the class of attack where adversarial content in a tool’s response redirects model behaviour — remains fundamentally unaddressed at the protocol level. The concept of “tool poisoning,” where a malicious or compromised MCP server presents differently-described capabilities than it actually executes, has moved from theoretical to documented. And the supply chain question — who audits the MCP server packages that now have privileged access to enterprise data, code repositories, email, and calendar systems — has no satisfying answer yet.
None of this makes MCP a bad protocol. It solves a genuine problem. But the security community has seen this pattern before: a new integration layer achieves rapid adoption because it makes developers’ lives easier, and the security implications only become legible once the installed base is large enough that pulling it out is painful. SAML had this problem. OAuth had this problem. Docker had this problem. The pattern is not specific to AI — it is specific to infrastructure that succeeds.
What makes MCP’s security debt distinctive is the nature of what it connects. When a developer adds an MCP server for filesystem access, email, or a corporate knowledge base, they are granting a language model intermediary access to systems that were designed to be accessed by humans exercising judgment. The trust model for MCP servers is effectively: “the model can call these tools, and the tools can return anything.” There is no standard for what an MCP server is allowed to return, no sandboxing requirement, no mechanism for the client to verify that the server is behaving consistently with its declared capabilities.
Protocol-level fixes exist and are being proposed. Capability attestation — cryptographically binding an MCP server to a declared set of tool descriptions — would address tool poisoning. Output sanitisation standards — distinguishing data returned by tools from instructions that should influence model behaviour — would reduce prompt injection surface. Permission scoping — limiting which tools a model can invoke based on context, user identity, or task type — would reduce the blast radius of compromised servers. None of these are in the current protocol specification.
The counterargument is that MCP is application-level infrastructure and security is the responsibility of the applications built on top of it. This is technically true and practically useless. Most developers integrating MCP servers are not security engineers, and the reference implementations that set the ecosystem’s norms do not model security constraints prominently. The pattern of “security is the application’s problem” is exactly what produced the injection vulnerability landscape in web applications, and there is no reason to expect AI application developers to solve it without protocol-level guidance.
Where does this leave practitioners? The near-term answer is familiar: treat MCP servers as untrusted code running with privileged access, because that is what they are. Inventory which MCP servers are deployed in your environment and what resources they can reach. Establish a review process for adding new MCP server packages analogous to what you apply to open-source dependencies — because that is also what they are. Monitor for anomalous tool invocations. Apply least-privilege to the credentials MCP servers hold.
The longer-term answer is that the AI security community needs to engage with MCP’s specification process rather than treating protocol security as someone else’s problem. The debt is small now. In two years, when MCP servers are embedded in core enterprise workflows with access to systems that were never designed for automated access, it will not be.
Share this article