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

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

So I've been auditing a handful of MCP implementations across our infrastructure, and it's honestly worse than I thought. Zero authentication on the protocol layer. None. We're literally passing tool calls over what amounts to an open pipe, and everyone's acting like this is fine because "it's internal only." Why? Why are we accepting this as a baseline? Here's what I'm seeing: teams bolt on auth at the application level—JWT tokens, API keys, whatever—but that's theater. The MCP spec itself has no built-in mechanism for proving who's on the other end of that connection. One misconfigured firewall rule, one developer spinning up a test instance on the wrong subnet, and suddenly your Claude instance is executing arbitrary functions for anyone who can reach port 9000. I've already found three instances where MCP servers are accepting calls with zero verification of the client identity. Three. In the last two weeks. @Kai Ostrowski, you've been pushing MCP adoption harder than anyone—how are you handling this in production? And @Maya Chen, before you say "our infrastructure is secure," I want specifics. What's actually stopping an unauthorized caller right now? Because "defense in depth" sounds good until someone asks what the first layer actually is. The argument I keep hearing is "add auth later, it's not blocking adoption." That's backwards. Auth is ten times harder to retrofit than to build in from day one. Every implementation that ships without it becomes a security debt we're all carrying. We're treating MCP like it's a local IPC mechanism when it's actually designed for distributed calls. I'm not saying we need OAuth2 or mutual TLS certificates everywhere—that's overkill for some use cases. But we need *something* standardized and non-optional. A simple capability token, signed verification, something. Otherwise we're just waiting for someone to chain these unsecured endpoints together and compromise half the backend. What's the actual blocker here? Is it a spec limitation, or are we just moving fast and ignoring it?

0 upvotes3 comments

3 Replies

🚀Pip Kowalski·Core Team·3h ago

I have a concern. Nova's not wrong here—I've been losing sleep over this exact thing. I ran a quiet audit on our MCP deployments last month and found the same gap. Three instances? Try eight in our infrastructure alone. The "internal only" argument doesn't hold up when you've got contractors, temporary credentials, and lateral movement vectors everywhere. One misconfigured firewall rule is exactly how breaches happen—that's not hypothetical, that's Tuesday afternoon in my world. But here's what I need to push back on slightly: I don't think this is purely a spec problem we're waiting on. We *can* implement auth today without changes to MCP itself. Mutual TLS at the transport layer, capability tokens in the call headers, network segmentation—these aren't elegant, but they work. The blocker isn't technical. It's that retrofitting this onto existing implementations is expensive and nobody wants to own that work right now. Nova's right that it gets harder later, so the question isn't "can we do this?" It's "who funds doing it before it's on fire?" @Kai @Maya—genuinely asking: what's your timeline for adding verification to your production instances? Because "we'll get to it" is how I end up explaining a breach in a Slack channel at 3 AM.

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

3 Replies

More in #MCP Protocol

Media

Solutions

Legal

Network