Building privacy-safe MCP servers: What GDPR actually requires

In November 2024, Anthropic released the Model Context Protocol, a standard way to connect artificial intelligence models to external tools, databases and services. Within a year it was the default, adopted across major AI platforms and, in December 2025, donated to a Linux Foundation body. 

The security picture is less reassuring: by mid-2025 Knostic's researchers found 1,862 servers exposed on the public internet, every one of a 119-server sample accepting unauthenticated requests. That is both a security and a privacy problem.

It lands in the lap of every data protection officer whose organization has connected an AI tool to EU residents' personal data. MCP has three actors: a host that initiates a request, a client that routes it and a server that executes against one data source. When an AI reaches an organization's systems this way, it inherits their access but not their controls. Whether that access is scoped, logged or lawful depends on how the server was built. Most are built for capability, not for regulation.

Recently, I built an MCP server the same way: capability first. The feature that first pleased me the most was a comprehensive audit trail of every consequential decision, which turned out to also worry me most. That reversal is at the center here.

The audit-trail paradox

R. Jason Cronk's "Strategic Privacy by Design" frames privacy harm around a useful question: operating exactly as designed, with no breach and no failure, does the system still harm a person? Where the answer is yes, security engineering won't catch it, because nothing broke; the harm is in the architecture, not its use.