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.
Did Claude write the compiler or interpreter? Those can choose what instructions get run, regardless of your source code.
There’s an old computer science discussion about trust and compilers. If I give you a compiler you can’t trust that it won’t insert a backdoor when you compile. So… You compile your own compiler from source… But that compiler puts a backdooring code into your compiler… What can you trust?
There’s an old computer science discussion about trust and compilers. If I give you a compiler you can’t trust that it won’t insert a backdoor when you compile. So… You compile your own compiler from source… But that compiler puts a backdooring code into your compiler… What can you trust?
burn it all down and go back to using abacuses and fingers! lol
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 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.Did you write it or did Claude write it?
farted out in 19 commits, over 3 days using copilot… scraped thoughtlessly with love <3
Did Claude write the compiler or interpreter? Those can choose what instructions get run, regardless of your source code.
There’s an old computer science discussion about trust and compilers. If I give you a compiler you can’t trust that it won’t insert a backdoor when you compile. So… You compile your own compiler from source… But that compiler puts a backdooring code into your compiler… What can you trust?
Well, we use CPUs that are not open source (I don’t yet, at least)
You can bootstrap your compiler toolchain from known good sources, or even from scratch (bootstrap C via Forth via assembly or machine code).
burn it all down and go back to using abacuses and fingers! lol
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.