MCP's Enterprise Overhaul Hands Security Problems to Developers
A major revision to the Model Context Protocol repositions itself as enterprise-ready — then quietly offloads the hard security work onto the teams building on top of it.
The Model Context Protocol just got a significant overhaul aimed at enterprise adoption. The catch: the specification's authors have shifted critical security responsibilities away from the protocol layer and onto developers and platform operators.
That is not a small thing.
MCP, for those not yet tracking it, is an emerging standard for connecting large language models to external tools and data sources. Think of it as plumbing for AI agents. Get the plumbing wrong and whatever runs through it becomes your problem.
The revised specification frames itself as production-grade. It introduces features that enterprise buyers recognise — structured tooling, clearer session handling, more defined capability negotiation. On paper, a maturation story. In practice, the specification now explicitly places the burden of authentication, authorisation, and input validation on implementers rather than encoding those controls at the protocol level.
This is a familiar pattern in infrastructure standards. TLS did not ship with certificate pinning by default. OAuth 2.0 handed scope enforcement to resource servers. The protocol defines the wire format; everyone downstream argues about what 'secure' means. MCP appears to be following the same trajectory, at speed, into environments where AI agents will have direct access to internal APIs, file systems, and databases.
The specific risks worth tracking here fall into two buckets. First, prompt injection through tool responses — a malicious data source feeding instructions back to the LLM via an MCP tool call. Second, over-permissioned tool registrations, where developers expose capabilities the model has no business accessing in a given context. Neither problem is new. Both become considerably worse when the attack surface is 'everything an enterprise AI agent can reach.'
Regulatory positioning is still forming. The FTC has signalled interest in AI system accountability under its unfair-or-deceptive-acts authority, and the EU AI Act imposes conformity obligations on high-risk system providers — but neither framework maps cleanly onto a protocol specification. The ICO has published guidance on AI and data minimisation under UK GDPR that would apply to any MCP deployment processing personal data. Organisations in scope should be reading that before they ship.
The spec's authors are not wrong to want enterprise adoption. But 'enterprise-ready' should mean security is easier to get right, not that responsibility for getting it right has been redistributed.
What teams building on MCP should do now:
- Treat every tool response as untrusted input. Sanitise before passing to the model context.
- Apply least-privilege to tool registrations. If the model does not need filesystem access for a given workflow, do not register it.
- Log tool invocations with full request and response payloads. You will need that audit trail.
- Review the ICO's AI and data minimisation guidance if any MCP-connected tool touches personal data.
