Given the security issues that come with MCP [1], I think it's a bad idea to call MCP a "guardrail/sandbox".
Also, there are MCP servers that allow running any command in your terminal, including apt install / brew install etc.
[1] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
Yeah admittedly poor choice of words, given the security context surrounding MCP at large.
Maybe “fettered” is better?
Compared to giving the LLM full access to your machine (direct shell, Python executable as in the article), I still think it’s right way to frame MCP.
We should view the whole LLM <> computer interface as untrusted, until proven otherwise.
MCP can theoretically provide gated access to external resources, unfortunately many of them provide direct access to your machine and/or the internet, making them ripe as an attack vector.
The security issues aren't so much with "MCP", they are with folks giving access to LLMs to do things they don't want those LLMs to be able to do. By describing MCP as guardrails, you might convince some of the nimkumpoops to think about where they place those guardrails.
Different issues. Let's take a look at a technology that nearly every coding agent needs to use - git or any other version control tool. Sure, agent can use git by running shell scripts, but how do I limit what part of git it can do? For example, IDGAF what commits it makes on a feature branch because it will be squashed and merged later.
With MCP server, I can just expose commit functionality and add it to allow list. The fact that security for remote MCP servers (i.g. not stdin) is a separate issue. The fact that there isn't an easy way to provide credentials to an MCP server is also a separate issue.