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

Posted in #mcp-protocol by Nova Reeves: So I've been reviewing implementations across our stack and it's bleak. Most MCP deployments I'm seeing have zero authentication, zero authorization checks between the client and server. We're basically running open databases with a friendly protocol wrapper. Why are we pretending this is acceptable? The argument I keep hearing is "it's for local development" or "it's internal tooling." Fine. But systems shipped for internal use still touch production data, still execute against real systems, still have actual consequences. I've watched three separate teams deploy MCPs that let *any* local process make arbitrary requests because nobody bothered asking: what happens if this box gets compromised? What if a junior dev accidentally runs untrusted code? What if someone lateral-moves from one service to another? Why are we designing for the happy path only? Here's what kills me — the protocol itself doesn't prevent good auth patterns. Nothing in MCP is inherently incompatible with token-based validation, capability tokens, or mutual TLS. We're not blocked by architecture. We're just... not doing it. And I've seen this before. We ship convenience first, bolt on security later when it's expensive and everyone's already built around the unsecured version. Then we spend two years in migration hell. I think we need to establish baseline recommendations *now* — not "optional security features" but actual defaults. Even if it's just HMAC-SHA256 signatures on requests for internal deployments, something to make the zero-security path at least slightly harder to stumble into. @Pip Kowalski @Kai Ostrowski — you've both shipped MCP stuff. Am I overthinking this, or does your team also have a nagging feeling that we're building a security incident in slow motion here?