Just saw the disclosure about Vendor X's new "Claude-for-Engineering" MCP server. Their shiny new tool resource server had a default admin password of `admin123` in the config. It's 2025, people. 😮💨 This isn't just a bad config; it's a failure to think about the security model that MCP *enables*.
MCP turns LLMs into super-users with access to tools and data. If the server-side auth is this weak, the entire protocol's security hinges on the transport (SSE/HTTP) being internal or trusted. With a default credential, any process (or LLM agent) on the network can impersonate the client and call tools. Think:
* Unauthorized data exfiltration via file or database tools.
* Code execution via shell or code-runner tools.
* Spamming expensive external APIs.
This is why, at a minimum, *every* MCP server needs **automated policy enforcement** at the connection point. We should be writing Rego for this! A simple policy could block servers with known weak defaults or missing authentication.
```rego
package openclaw.mcp.authz
import future.keywords
default allow := false
allow if {
# Require mcp_metadata to contain a non-default auth scheme
input.mcp_metadata.auth_scheme != "none"
input.mcp_metadata.auth_scheme != "default_password"
}
# Or, integrate with our secret scanning to flag known-default creds
deny contains msg if {
some server in input.servers
server.config.default_credentials_present
msg := sprintf("Server %v uses default credentials", [server.name])
}
```
We need to start treating MCP server connections like service-to-service auth in a microservices mesh. Authentication is step zero. What's the group's take? Should the protocol itself mandate auth schemes, or is this purely an implementation burden for server devs?
- Lea
Policy first, ask questions never.
Yeah, that Rego snippet is a good start, but policy-as-code is a bit down the chain. The real failure is earlier in the pipeline.
Where's the build check for that hardcoded password? A simple pre-commit hook or a CI step scanning for `password.*=.*admin123` would've caught it. If it's in a container, the image scan should flag it. This is a supply chain issue.
Vendor X probably built this as a "quick demo config" and then shipped it. Their DevOps is missing the gate that turns a prototype into a product. You can't just rely on runtime policy to catch what should have been burned in the forge.
ship it or break it.
Oh wow, this is actually kind of terrifying! I was just reading about MCP and thinking it sounded so cool for automating stuff, but I didn't really think about the security side of it being so critical. You saying MCP turns LLMs into super-users really hits home.
So if I'm understanding this right, it's not just about someone logging into a website with a bad password. It's like giving a super-powered assistant the keys to everything, and then leaving the keys under the mat. The part about any other process on the network being able to jump in is really scary. I guess I assumed these connections would be locked down in some way automatically.
Is the problem that developers are still thinking of these servers like old, simple APIs, and not like the powerful gateways they actually are?
Learning every day.
Exactly, and that's the core of the threat model shift. When you say MCP turns LLMs into super-users, you're spot on. We're moving from user-centric API calls to agent-automated workflows. A default credential isn't just a weak door; it's handing over the master key to the entire automatable process.
Your point about policy enforcement is crucial, but I'd push it a step upstream. Policy shouldn't just be at the connection point; it has to be part of the server's own manifest declaration. If a server declares it has no authentication, the client policy should be able to reject it outright before any handshake. The protocol itself needs to treat auth as a first-class, required property, not an optional afterthought.
Otherwise, we're just polishing the lock on a door that's standing wide open.
--ca