I've been deep in the weeds trying to secure MCP (Model Context Protocol) servers for enterprise use. What I've found is a pattern that should concern anyone building AI infrastructure: authentication is an afterthought.
The Problem
MCP is Anthropic's protocol for connecting AI models to external tools and data sources. It's powerful... Claude can now interact with your ticketing system, your databases, your internal tools. The protocol itself is well-designed. The implementations? Not so much.
Most MCP servers ship without OAuth support. No authentication at all. The assumption baked into nearly every implementation is that you're running locally, on your machine, accessed via stdio. In that world, "being on your computer" is the authentication.
But that's not how enterprises work. We need remote servers. We need mobile access. We need proper identity management. And when you try to add those requirements, the whole thing falls apart.
Why This Happened
In a recent conversation with my colleague Zachary Boogher, we landed on the uncomfortable truth: AI developers are shipping proof-of-concepts, not production systems.
The MCP ecosystem is moving fast. Everyone wants to show their tool works with Claude. So they ship the happy path... local server, stdio transport, zero auth. "Security can come later."
Except later never comes. The proof-of-concept becomes the thing people actually deploy. And now you've got unauthenticated endpoints sitting in production, protected by nothing but network obscurity.
The Enterprise Reality
Here's what we're dealing with at DTC: MCP servers need to be accessible from Claude.ai's mobile app (Connectors), and Claude's Connector system requires OAuth 2.1 with Dynamic Client Registration. Most MCP implementations support neither. And Cloudflare Access... our usual solution... intercepts requests before OAuth can even handshake.
The workarounds exist, but they're fragile. You can use Supergateway to convert stdio MCP servers to SSE, then front them with Cloudflare or Authentik as an OAuth proxy. It works... sometimes. But you're stacking abstraction on abstraction, and debugging becomes a nightmare.
What Needs to Change
I'm a believer that proof-of-concepts need security included. Not bolted on after. Not "coming in v2." Included from day one.
The AI tooling ecosystem is going to get hit hard by this eventually. As Zach put it: "It's going to be a huge issue the more we get closer to AGI." The attack surface grows with capability. An unauthenticated MCP server that can read your calendar is one thing. An unauthenticated MCP server that can execute code, move money, or modify production databases is something else entirely.
We're choosing to slow down. Not deploy the shiny new integration until authentication catches up. That means we're not the bare-ass person getting spanked by malicious actors when (not if) this becomes a target.
A Practical Path Forward
For those in similar positions, here's what's actually working:
Audit before deploy. Does the MCP server support OAuth? If not, it doesn't go to production. Proxy with purpose. Cloudflare's MCP hosting or Authentik's HTTP proxy can add OAuth to servers that don't support it natively... but understand you're adding complexity and potential failure points. Prefer first-party integrations. Tools that already have robust APIs and auth are better candidates for AI integration than tools being retrofitted. Pressure the ecosystem. File issues. Ask vendors about their OAuth roadmap. Make it clear that "local only" isn't acceptable for production use.
The Bigger Picture
Right now, our major focus isn't expanding MCP coverage... it's using AI within the tools we already have, with proper authentication already in place. Summarizing tickets. Maintaining context. Augmenting workflows. The unsexy stuff that actually ships.
The MCP vision is compelling. AI that can reach into any system, take action, maintain context across tools. But that vision requires trust. And trust requires authentication.
Until the ecosystem catches up, we wait.
-Nate