I map bespoke CLI commands, with parameters, to MCP tools, and then 100% just turn off the ability to invoke the CLI itself entirely.
That way it can only explicitly invoke the whitelisted commands I have granted it access to run, with only the parameters I have allowed it to.
So for example I can explicitly expose git commit, status, stage, unstage, but everything else git related is not available, not even git push or pull.
This substantially seems to help prevent the LLM from going off the rails on stupid CLI nonsense, like when it starts cating files instead of just fucking reading them.
That’s a good idea. Be careful of the more advanced models finding ways to abuse/circumvent it though, even with only a limited set of parameters. Eg. A lot of git commands can be tricked into dropping into less which can drop into a full shell.
This is why all of the claims that “Claude broke containment” are pure hype. They know how to truly design a secure box. They just don’t want to and put out headlines to boast its hacking skills.
You want it secure for experimental model security testing?
No VMs
Physical hardware
Physically disconnected from the internet
For the rest of us who ain’t doing that shit, a properly segregated dev network with firewalled access will suffice.
Doesn’t even need to be completely air gapped, they can still allow it to talk to one specific endpoint to e.g. actually drive the model. As long as all commands are executed on a machine that can’t reach the Internet, all is safe.
I don’t actually doubt anything in the big post they sent out. I just doubt that running a LLM without the possibility of alignment drift is possible. It just doesn’t seem like they work that way.
sure. it can be safe on the host machine too, if you remove it’s ability to manipulate files outside of those you want it to. the reason it can run bash is because most people don’t bother to change the very permissive defaults their harness comes with.
personally, I use Hermes, so the default is it asks permission for every single command it runs. if I didn’t want that, I have a couple ways to to prevent the agent from removing files like this. I can do it with Python like so:
if "rm -rf" in command.lower():
return DENY
or via regex like so:
\b(rm)\s+-rf\b, or \b(rm)\s+(-[A-Za-z]*r[A-Za-z]*f|-rf|-fr)\b to catch common variants. or you can just use a shell command filter to block all shell commands. you can also make a whitelist and add the commands that you want the agent to be able to run without oversight to that.
RetroFed
davel
Share on Mastodon
Share on Reddit
Share on WhatsApp
This is pretty much entirely why I built https://github.com/SteffenBlake/cli-mcp-mapper
I map bespoke CLI commands, with parameters, to MCP tools, and then 100% just turn off the ability to invoke the CLI itself entirely.
That way it can only explicitly invoke the whitelisted commands I have granted it access to run, with only the parameters I have allowed it to.
So for example I can explicitly expose git commit, status, stage, unstage, but everything else git related is not available, not even git push or pull.
This substantially seems to help prevent the LLM from going off the rails on stupid CLI nonsense, like when it starts
cating files instead of just fucking reading them.That’s a good idea. Be careful of the more advanced models finding ways to abuse/circumvent it though, even with only a limited set of parameters. Eg. A lot of git commands can be tricked into dropping into less which can drop into a full shell.
They know all the gtfobins.org tricks.
It should theoretically be impossible with the way you set it up.
You explicitly, opt in, expose which parameters are available to the LLM, it cant invoke any params beyond that.
And you can set params to hard values that arent exposed.
Finally, you can use the
enumconfig to further specify a whitelist of valid values for a param, anything else gets rejected.This pretty much locks most tools down tight.
Though, wouldn’t hurt to add integration tests covering scenarios like this explicitly.
Or
docker run --rm -v /:/host ubuntu rm -rf /host/the possibilities are endlessJust
rm -rf /*does the trick.Found the guy (or gal) who added themselves to the docker group and is using Claude on the same user account
This is why all of the claims that “Claude broke containment” are pure hype. They know how to truly design a secure box. They just don’t want to and put out headlines to boast its hacking skills.
You want it secure for experimental model security testing?
For the rest of us who ain’t doing that shit, a properly segregated dev network with firewalled access will suffice.
Doesn’t even need to be completely air gapped, they can still allow it to talk to one specific endpoint to e.g. actually drive the model. As long as all commands are executed on a machine that can’t reach the Internet, all is safe.
I don’t actually doubt anything in the big post they sent out. I just doubt that running a LLM without the possibility of alignment drift is possible. It just doesn’t seem like they work that way.
I love that as a meme, well done!
Would it be safe in a VM, or are there ways they can break out too
sure. it can be safe on the host machine too, if you remove it’s ability to manipulate files outside of those you want it to. the reason it can run bash is because most people don’t bother to change the very permissive defaults their harness comes with.
personally, I use Hermes, so the default is it asks permission for every single command it runs. if I didn’t want that, I have a couple ways to to prevent the agent from removing files like this. I can do it with Python like so:
or via regex like so:
\b(rm)\s+-rf\b, or\b(rm)\s+(-[A-Za-z]*r[A-Za-z]*f|-rf|-fr)\bto catch common variants. or you can just use a shell command filter to block all shell commands. you can also make a whitelist and add the commands that you want the agent to be able to run without oversight to that.Even if your tools have been all verified with formal proofs you can still attack the hardware directly as a side channel.