Solving the trifecta of security for AI Agents
In 2025, Model Context Protocol (MCP) captured the imagination of the AI engineering community. 2026 will be the year that everyone realises their prototypes need to run in production.
Here's a summary: Over 16,000 MCP servers are now indexed across registries. Monthly SDK downloads across Python and TypeScript have hit 97 million. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) as part of the Linux Foundation, co-founded with OpenAI and Block, with backing from Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP has been called the "USB-C for AI"; a universal standard for connecting agents to tools, data and APIs. It's been adopted by ChatGPT, Cursor, Claude, Gemini, Microsoft Copilot, VS Code and practically every serious AI tool.
By any measure, MCP is an extraordinary success story. I attended MCP Dev Summit Europe last year and a question that kept coming up there continues to come up today in conversations with engineering teams: how do we deploy our MCP servers securely in production?
The Gap Between Built and Deployed
The answer, it turns out, is sobering. Clutch Security's research found that 86% of MCP servers run locally on developer machines. Only 5% run in production environments like CI pipelines, cloud workloads and Kubernetes pods. In a typical 10,000-person organisation, their analysis found that roughly 1,500 employees run an average of two MCP servers each, creating over 3,000 deployments connecting to 115 distinct enterprise services. Nearly all of them are local.
This is the gap between building and deploying. The ecosystem grew 2,200% in 13 months (from three implementations in October 2024 to nearly 7,000 by November 2025) but almost none of that growth was production-grade. The Zuplo State of MCP Report confirms the picture: 58% of MCP servers are simply wrapping existing APIs rather than building new capabilities. A quarter have no authentication at all. And 38% of builders say security concerns are actively blocking increased adoption.
We've seen this pattern before. Building a Docker container in 2014 was easy. Running containers in production at scale took the better part of a decade, an entire ecosystem of orchestration tooling and hard lessons about networking, storage and security. Kubernetes adoption is now mainstream, but even today 76% of adopters say complexity still inhibits them. MCP is at the "building containers" stage; the protocol is right, but the production practices haven't caught up.
The Security Cliff
The majority of MCP servers run in STDIO mode, where the server process runs locally and communicates with a single host application like Claude Desktop or ChatGPT. This is a walled garden: no network exposure, single user, no authentication or authorisation required. It works beautifully for single-player developer productivity.
Production requires something different. Remote deployment means switching to Streamable HTTP transport (the successor to the now-deprecated Server-Sent Events mode), which enables multiple clients to connect to a single MCP server over the network. This is where MCP becomes genuinely valuable: shared infrastructure, horizontal scaling, centralised governance.
But the transition from STDIO to HTTP hits you all at once. You go from zero security surface to suddenly needing OAuth, token management, CORS configuration, TLS, redirect validation, SSRF protection, rate limiting and audit logging. Load testing by Stacklok showed that STDIO fails catastrophically under concurrent load (20 out of 22 requests failed with just 20 simultaneous connections), so there's no option to stay local at scale. You have to cross the cliff.
What waits on the other side is alarming. Astrix's analysis of over 5,200 MCP server implementations found that 88% require credentials to operate, yet 53% rely on static API keys or Personal Access Tokens (PAT) that are long-lived and rarely rotated. Only 8.5% use OAuth. 79% of API keys are passed through simple environment variables. The original sample servers released by Anthropic to showcase MCP used PAT and basic credentials; while those examples were later corrected, the pattern had already taken hold across thousands of community implementations.
The Lethal Trifecta
Simon Willison, who coined the term "prompt injection", describes what he calls the "lethal trifecta" for AI agents: the combination of access to private data, exposure to untrusted content and the ability to communicate externally. When an agent has all three capabilities, an attacker can trivially steal data.
MCP servers are designed to provide all three. That's the whole point. An MCP server connecting an agent to your Apache Kafka infrastructure gives the agent access to private data (your Kafka topics and messages), exposure to untrusted content (whatever is in those messages) and external communication ability (the agent can take actions based on what it reads). There is a fundamental tension when connecting autonomous agents to real systems, so it's down to you to ensure your implementation is built to survive it.
The OWASP MCP Top 10 provides a structured view of the risks: tool poisoning, privilege escalation via scope creep, supply chain attacks, command injection, insufficient authentication and (perhaps most overlooked) the lack of audit and telemetry. 43% of tested MCP implementations contained command injection flaws. 492 servers were found on the open internet with zero authentication.
Why OAuth for MCP Is Genuinely Hard
The November 2025 MCP specification introduced OAuth 2.1-based authorisation for HTTP transports, along with Client ID Metadata Documents (CIMD) as the recommended client registration mechanism. This was a significant step forward; CIMD elegantly solves the scaling problem of Dynamic Client Registration (DCR) by making the `client_id` an HTTPS URL hosting a JSON metadata document rather than a server-minted identifier. Servers fetch and validate metadata on demand rather than maintaining ever-growing registration databases.
But implementing this correctly is genuinely difficult. The spec references OAuth 2.1, RFC 9728 (Protected Resource Metadata), RFC 7591 (Dynamic Client Registration), RFC 8414 (Authorisation Server Metadata) and the CIMD draft. For teams without deep OAuth experience, navigating this maze of standards is daunting.
The harder problem is what the spec doesn't cover. As AuthZed put it bluntly: "The spec handles authentication. Authorisation, the actual permission decisions, is left entirely to implementers". Even teams that implement OAuth correctly still have to answer: which tools can this user call? Which resources can they access? How are tokens scoped? How do you prevent privilege escalation over time?
Get the implementation wrong and the consequences are severe. Cato Networks' research demonstrated two vulnerabilities in Anthropic's own MCP SDK where default-permissive CORS settings (allow_origins="*") and unvalidated redirect URIs enabled silent OAuth token theft. A developer logged into their SSO-backed MCP environment visits a malicious webpage; that page registers a rogue OAuth client, completes the flow and steals the developer's token. The attacker now has the developer's permissions across every connected system: repositories, CI/CD pipelines, code signing and artifact uploads. "Nothing is technically broken", Cato Networks noted. "The SDK operates as designed, but its permissive default configuration transforms convenience into exposure". They compared the potential impact to the infamous SolarWinds incident.
What Enterprise-Grade Actually Looks Like
The path from 5% to mainstream production adoption requires the ecosystem to mature across several dimensions simultaneously. OAuth is necessary but not sufficient. Enterprise-grade MCP demands role-based access controls that scope agent permissions at the tool and resource level, not just the session level. It demands data masking to prevent agents from being exposed to PII and sensitive data that they have no business seeing. It demands audit logging of every agent action, not as an afterthought but as a first-class capability, ensuring the transparency required by regulations like the EU AI Act.
Critically, authorisation decisions need to be deterministic. There's a temptation to solve AI security with more AI, training a model to detect sensitive content or monitor other AI systems for policy violations. But AI is probabilistic by design; a 99.9% accuracy rate still leaves meaningful failures at scale. The answer to "does this agent have permission to access this resource?" must be yes or no, not "probably not".
Observability belongs in this picture too. If you can't trace what an agent did, which tools it called, what data it accessed and what actions it took, you can't govern it. OpenTelemetry and structured telemetry for agentic AI aren't optional extras; they're prerequisites for any organisation that takes production deployment seriously.
The Protocol Is Right; the Ecosystem Needs to Catch Up
The protocol itself is well-designed, vendor-neutral and now stewarded by the Linux Foundation with the weight of the entire AI industry behind it. The gap between MCP's promise and the ecosystem's readiness to deliver on it in production is where the hard work remains.
In the next 12 months, we'll see this gap close rapidly. The teams that move first on production-grade MCP, with proper authentication, fine-grained authorisation, data governance and observability, will set the standard for how autonomous agents interact with enterprise systems. The teams that treat MCP as just another developer tool running on a laptop will be left managing the security debt.
The future of agentic AI depends on getting this right. Building an MCP server is the easy part. Running one in production, securely and at scale, is the engineering challenge ahead of us.
