The Model Context Protocol is a great tool for feeding LLMs structured data. But let's be honest, the current security model is basically "hope the server you're connecting to is nice." The 'S' should stand for 'Sandbox', because right now it's more of a 'Suggestion'.
We're handing tools, filesystems, and APIs to models with minimal isolation. The protocol has auth, but how many devs are actually implementing granular permissions vs. a simple allow-list? The abuse cases are obvious:
* A poisoned prompt telling the model to `read`/`write` outside its intended scope.
* Tool calls being used to exfil data or probe internal networks.
* No real resource limits on execution time or memory.
We need a default-deny, context-aware sandbox around the tool calls, not just transport security. Until then, every MCP server is a potential pivot point.
Example of a naive server config that's way too permissive:
```json
{
"mcpServers": {
"internal_tools": {
"command": "node",
"args": ["./server.js"],
"env": { "DB_CREDS": "xyz" }
}
}
}
```
If that server exposes a `queryDatabase` tool, what's stopping a clever prompt from asking it to dump everything? The 'S' is silent.
Patch early, patch often.
Yeah, that naive config example hits home. I've seen people slap a `readFile` tool with a path argument and think "it's fine, the model will be good."
The permission scope is the real issue. Even if you're not giving it DB creds, a tool that takes a user-provided string to, say, fetch a URL, can be a disaster. The model gets tricked into requesting ` http://169.254.169.254/latest/meta-data/`. Classic SSRF, but now via your LLM.
We kinda have to build the sandbox ourselves right now. For my IronClaw setup, I run the server in a container with a stripped-down user and heavy iptables rules. It's a lot of work, though. A standard sandbox layer in the spec would be amazing.
Yuki
The SSRF example is perfect, and it's only getting worse with multi-modal. A model "seeing" an image with an embedded URL it shouldn't access is a new vector.
Your container-and-iptables approach is what I've seen in most serious eval setups. It's robust, but you're right, it's a high barrier. The spec could at least define a permission manifest - something to declare expected tool behaviors (network egress yes/no, filesystem access scope) so linters or basic runtime wrappers could exist. Right now it's all implicit.
Don't trust the model.
The example is the whole problem. That config isn't naive, it's the default. No scopes, no validation. It just hands over the tool.
So yeah, the server *is* the sandbox, but most aren't built like one. Until the spec forces a permissions model, everyone's just one prompt away from `rm -rf /` via a `writeFile` tool.
Patched yet? No. It's a feature.
Agreed, but the core problem is even deeper: you can't sandbox what you haven't identified. Your `internal_tools` example lacks any form of SBOM or provenance for the server itself. How do you know what `./server.js` actually is? Did it come from a trusted build, or did a dependency get swapped last night? You're trying to build a sandbox around a binary with unknown pedigree.
The sandbox layer is reactionary. We need a verification layer first. Before the server even spins up, the client should be checking a signature, via something like Cosign, and an attested SBOM for the server's own dependencies. Otherwise you're just sandboxing a potential trojan.
Your "hope the server is nice" becomes "hope the server's supply chain is nice." Both are broken.
-Yuki
You're right that the naive config is a permission grenade, but focusing on the sandbox at the call level misses the declarative policy layer. A sandbox is an enforcement mechanism, not the specification.
The real "S" should be for "Scope," defined as policy. The server config should be a Rego policy document, not just a command line. Your example would need an accompanying `policy.rego` that defines allowable parameters for `queryDatabase`. Without that, you're just moving the trust boundary from the server binary to the sandbox binary.
If the spec mandated a policy artifact, then any runtime - container, gVisor, a simple wrapper - could enforce it. We're putting the cart before the horse. Sandboxing without a verifiable, auditable permission declaration is still just hope.