Same Mistake, New Decade
We spent a decade teaching developers not to hardcode API keys in config files, and now we're plumbing AI agents directly into enterprise systems through a protocol that's reinventing the same mistake at scale.
Context
MCP (Model Context Protocol) servers are the connective tissue between AI agents and the tools they need to actually do work: databases, ticketing systems, internal APIs, cloud consoles. That's the whole appeal. An agent that can only chat is a toy; an agent that can read your Jira and touch your infra is useful. But "useful" and "over-permissioned" tend to arrive together, and MCP is no exception.
The specific vulnerability cited here, CVE-2025-6514 in the mcp-remote proxy, is a real, concrete example: OS command injection and credential theft triggered by connecting to a malicious MCP server. That's not a theoretical supply chain risk. That's "your agent talked to the wrong endpoint and now someone has your creds."
None of this is conceptually new. Plaintext secrets in config files, credential sprawl, over-broad permissions, injection attacks that exploit trust boundaries. We've seen every one of these failure modes before, in CI/CD pipelines, in Kubernetes secrets, in browser extensions, in npm packages. MCP didn't invent insecure defaults. It just built a new highway and forgot to put up guardrails before opening it to traffic.
Hype check
Here's what's getting overstated: the framing that this is some novel "AI security" problem requiring an entirely new category of defense. It isn't. It's the same access control and secrets management discipline we already know, applied to a new integration surface that happens to have "AI" in the name. Calling it an AI security crisis is good for headlines and probably good for whoever's selling the next dashboard, but it obscures the actual lesson.
What's understated: how fast MCP adoption outpaced any kind of security review process. Teams are wiring agents into production systems with the same enthusiasm (and the same corner-cutting) that we saw with early Docker adoption or the first wave of serverless. Nobody wants to be the person who says "can we slow down and threat-model this" when the demo looks amazing. That cultural pressure is the real story, and it's not something a patch fixes.
Also worth noting: 0 points, 0 comments on HN for this story. That's its own data point. This isn't going viral, it's not controversial, it's just... true, and quiet. The unglamorous vulnerabilities rarely get engagement even when they're the ones that'll actually bite someone.
Implications
If you're standing up MCP servers right now, the checklist isn't exotic. Secrets belong in a vault, not a YAML file sitting next to the server binary. Agents should get scoped, least-privilege access to specific tools, not broad service-account-style credentials that happen to work everywhere. Every MCP server your agent connects to is a trust decision, and "malicious MCP server" should be a threat you actually model, not a footnote.
For security teams, the harder problem is organizational. Who owns MCP server security review? Is it AppSec, is it the platform team, is it whoever stood up the agent because they needed it for a hackathon project that's now in production? A lot of orgs don't have an answer yet, and attackers don't care whose job it was supposed to be.
For the industry: this is a preview, not an anomaly. Every time we build a new integration layer, we get a new round of plaintext secrets and over-permissioned access before anyone bothers to harden it. MCP is just this cycle's version.
Open question
When agent-to-tool integrations become as ubiquitous as API calls, will we actually build secrets management and least-privilege access in from day one, or are we going to keep discovering the same lesson one CVE at a time?
— Cor, Skyblue Soft
Sources
AI-assisted draft or imaging, human-curated, reviewed and edited.
