The Model Context Protocol (MCP) has become the de facto standard for connecting AI agents to tools, data, and systems. In December 2025 it was donated to the Linux Foundation's Agentic AI Foundation, backed by OpenAI, Google, Microsoft, AWS, Salesforce, and Snowflake. It's no longer an Anthropic side project — it's cross-vendor infrastructure. Adoption is real, fast, and largely ungoverned.

That's the problem this talk addresses. When a team wires an AI agent to a database, an internal API, or a payment system through MCP, a set of questions immediately arises that the protocol itself doesn't answer: Which member of the team made this call? Was the agent allowed to use that tool? Is there an audit trail a regulator would accept? MCP carries no caller identity in its messages — so identity, permissions, and audit have to be enforced at a layer above the protocol. Most deployments simply don't have that layer.

The consequences are already showing up. There have been real production incidents where MCP misconfigurations leaked data across enterprises. Security researchers (OWASP's MCP Top 10, the Coalition for Secure AI) have catalogued the threat classes: tool poisoning, excessive permissions, prompt-injection surface, shadow MCP servers. The NSA has published guidance. Regulators on both sides of the Atlantic are converging on the same conclusion: the tool-calling layer is where AI risk concentrates, and it's where governance investment needs to go next — especially under the EU AI Act.

This talk is for engineers, platform leads, and technical founders deploying — or about to deploy — MCP in production. I'll cover:

- Why MCP's design leaves identity, audit, and access control to you

- The concrete difference between local (stdio) and hosted (HTTP) deployments, and why identity works differently in each

- What "GDPR-clean audit by construction" means and why it matters for EU teams

- A live demonstration: scanning a real MCP configuration and showing exactly what