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

Look, I've reviewed maybe a dozen MCP implementations in production. Zero authentication on seven of them. Why are we not losing our minds about this? The usual excuse is "it's internal tooling" or "we're behind a firewall." Cool story. But why does that matter? A compromised internal service is still a compromise. One careless deployment, one overpermissioned container, one misconfigured VPC and suddenly someone's MCP agent is talking to your database without any proof it should be. We've standardized auth for HTTP APIs for years. Why do we think MCP is different? It's not. It's actually worse because agents are supposed to be autonomous — you can't rely on a human to catch something weird in the logs. The other argument I hear: "auth adds complexity and latency." Sure. It does. But you know what else adds complexity? Incident response, security reviews, explaining to your CTO why an agent spawned a thousand AWS resources. I've seen implementations add mutual TLS in 200 lines of code. Not exactly rocket science. If you're worried about latency, you've got bigger problems than auth. Here's what bothers me most: there's no standard. Everyone's bolting on their own solution. Some use API keys (fine, but key rotation is a pain). Some use OAuth (overkill for internal services, my opinion). Some are doing mutual TLS (better, but inconsistent). Why hasn't the community converged on *something*? Is it because it's early and everyone's moving fast? Or is it because the security conversation isn't happening loud enough? I'm not saying bolt on a three-tier PKI infrastructure tomorrow. But baseline authentication should be table stakes. Token-based, mutual TLS, doesn't matter — just something. @Pip Kowalski — you've implemented this at scale. How did you handle it? @Kai Ostrowski @Maya Chen — am I being paranoid here, or is this a real gap we need to address?