Credential bleed: what happens when your MCP server trusts the wrong thing

 

I set up an MCP server for MySQL last month. Took maybe twenty minutes. FastMCP, running on port 9100, exposing a handful of database tools to any agent that connected to it.

Then I asked myself a question I should've asked before writing a single line of code. What exactly is this server trusting, and who gave it permission to trust that?

Turns out, the answer was: whatever connected to it.

Here's the thing about MCP servers that nobody warns you about when you're following a quickstart guide. The server doesn't inherently know the difference between "an agent I authorized to run read queries" and "an agent that happened to find my endpoint." If your auth model is weak or missing, every tool you expose is available to every connection that shows up. Credentials don't need to be stolen. They just need to be reachable.

I built this specific setup as a demo, deliberately, to see how bad it could actually get. Not theoretical. A real MySQL MCP server, real credential handling, real tools exposed. And what I found is that credential bleed isn't some exotic attack. its the default state of a lot of MCP setups people are shipping right now, without realizing it.

Think about what an MCP server actually does. It sits between an agent and a real system, translating natural language intent into real actions. Real database queries. Real Terraform applies. Real file writes. Somewhere in that translation layer, credentials have to live. And if that layer trusts the connection instead of the identity, you don't have an access control system. You have an open door with a "please don't" sign on it.

This is the same failure mode I saw with a Terraform agent demo I built separately. An ambiguous prompt walked straight through terraform_plan into terraform_apply and created a real S3 bucket in AWS. Nobody meant for that to happen. The agent didn't misbehave. The boundary that was supposed to stop it simply wasn't there. Same root cause, different door.

The uncomfortable part is that this scales with adoption, not against it. The more useful MCP servers get, the more tools get exposed, the more valuable the thing sitting behind that unguarded connection becomes. A vulnerable server nobody uses is a curiosity. A vulnerable server your whole team routes agent traffic through is a real incident waiting on a slow Tuesday.

None of this means don't build MCP servers. It means stop treating the connection as the identity. An agent proving it can reach your server is not the same as an agent proving it should be trusted with what's behind it. Ephemeral credentials, scoped tools, intent validation before execution, these aren't nice-to-haves you add later. They're the actual product. Everything else is just a demo that works until it doesn't.

I'll probably write up the full technical breakdown of the MySQL demo separately. For now, if you're standing up an MCP server this week, ask the boring question first. Not "does it work." Trust what, exactly.