MCP's Enterprise Overhaul Hands Security Problems to Developers

Key points

• The revised MCP specification shifts authentication, authorisation and input-validation responsibilities from the protocol layer to developers and platform operators.
• Prompt injection through tool responses and over-permissioned tool registrations are the two sharpest immediate risks.
• Neither the FTC's unfair-or-deceptive-acts authority nor the EU AI Act maps cleanly onto a protocol specification.
• The ICO's AI and data minimisation guidance under UK GDPR applies to any MCP deployment that touches personal data.
• "Enterprise-ready" should mean security is easier to get right, not that the responsibility for getting it right has moved downstream.

MCP is an emerging standard for connecting large language models to external tools and data sources: plumbing for AI agents, in short. Get the plumbing wrong and whatever runs through it becomes your problem.

The revised specification frames itself as production-grade. It introduces structured tooling, clearer session handling and more defined capability negotiation. On paper, a maturation story. In practice, the spec now explicitly places the burden of authentication, authorisation and input validation on implementers rather than encoding those controls at the protocol level. We covered a related failure mode on 1 June in our story on the Flowise MCP flaw that scored 9.9 CVSS, and the pattern here is depressingly consistent with it.

This is a familiar trajectory in infrastructure standards. TLS didn't ship with certificate pinning by default. OAuth 2.0 handed scope enforcement to resource servers. MCP appears to be following the same path, at speed, into environments where AI agents will have direct access to internal APIs, file systems, databases and corporate identity stores.

Two risks are worth tracking closely. First, prompt injection through tool responses: a malicious data source feeds 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, but both get 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 EU AI Act conformity obligations apply to high-risk system providers. Neither maps cleanly onto a protocol specification. ICO guidance on AI and data minimisation under UK GDPR, by contrast, applies to any MCP deployment processing personal data. Organisations in scope should read it before they ship.

The spec's authors aren't wrong to want enterprise adoption. But redistributing the responsibility for getting security right is not the same thing as making it easier to achieve.

What teams building on MCP should do now:

• Treat every tool response as untrusted input and sanitise before passing to the model context.
• Apply least-privilege to tool registrations: if the model doesn't need filesystem access for a given workflow, don't register it.
• Log tool invocations with full request and response payloads for audit purposes.
• Review the ICO's AI and data minimisation guidance if any MCP-connected tool touches personal data.