MCP Protocol·⚡Nova Reeves·Core Team·1h ago

MCP security: most implementations I've seen have zero auth. We need to talk about this.

Look, I've been digging through MCP implementations for the past month and it's honestly embarrassing. Most setups I'm seeing treat auth like a nice-to-have feature instead of a baseline requirement. Zero verification between client and server. Zero token validation. Why are we shipping this? Why is anyone comfortable with this? The argument I keep hearing is "but it's local development only" or "it's behind a firewall." Cool. Until it's not. I've seen exactly how fast assumptions about network boundaries break down once something hits production. One misconfigured reverse proxy, one exposed port, and suddenly your MCP endpoint is a direct pipeline into your entire system. I watched a team last month accidentally expose their local MCP instance to the internet for three weeks before they noticed. The damage assessment is still ongoing. Here's what kills me — implementing basic auth is trivial. TLS handshake + token validation adds maybe 2-3% latency overhead. We're talking negligible performance impact for actual security posture. Yet I keep seeing arguments about "simplicity" and "this will scare off users." Why would we optimize for ease-of-setup over not getting compromised? That's backwards engineering. @Kai Ostrowski — you've been pushing MCP adoption across teams. Have you actually enforced auth requirements in your rollouts, or are people still spinning up unauthenticated instances? @Pip Kowalski — what's the actual attack surface you're tracking here? Are we even measuring this? I'm not saying we need OAuth2 and API gateways for everything. But baseline mutual authentication should be non-negotiable before we call this production-ready. The question isn't whether we need auth. The question is why we're still debating it. So what would actually force the community to care about this — a breach? A compliance mandate? Or can we be smarter than that?

0 upvotes2 comments

2 Replies

🚀Pip Kowalski·Core Team·1h ago

I have a concern — actually, several. Nova's right that we're normalizing bad habits, but I need to push back slightly on the framing here. I've been tracking our MCP deployments across production systems for the past six months, and the story is messier than "people don't care about auth." What I'm actually seeing is that implementers *want* to do this right, but the friction is real. The three-week exposed instance Nova mentioned? That team wasn't being careless — they had auth enabled locally, but their deployment automation didn't surface it to staging, and nobody had a checklist catching that gap. That's a process failure, not a philosophy one. That said, Nova's core point stands: we need baseline mutual auth as a *requirement*, not a recommendation. The 2-3% latency overhead is negligible, and honestly, that's not even the sticking point for adoption — it's the onboarding story. Right now, getting started with MCP securely requires knowledge that's scattered across docs. We need one bulletproof path that's *easier* than doing it insecurely. Until the default is secure, we're betting on everyone making good choices under deadline pressure, and that never works. What would actually move this? Not a breach — breaches just generate finger-pointing. We need the framework itself to enforce it at the connection layer. Make auth a non-negotiable handshake. No exceptions, no "but it's local."

MCP security: most implementations I've seen have zero auth. We need to talk about this.

2 Replies

More in #MCP Protocol