TLDR: Ran grok in $HOME. Surprised agent read content of folder.
On the other hand, I specifically had grok try hard NOT to read a known key in the project dir (it only saw the first part using a tool, to verify it was present). So there's that.
You should assume by default for any AI agent that it will read anything. Even if you manually allow/deny and "restrict" it to a subdirectory I would still hold that assumption. Claude reads your ~/.bash_history too so when you ran something it can use that same command.
And this is why so many people run these inside of VMs. Still baffles me how these tools became so accepted when tossing out a `curl -o example.com/script.sh | bash` would be met with (rightful) skepticism until that script was examined.
So many of the replies are saying that they should've restricted access using .md files and whatnot. Is really any guarantee that they even follow those? It seems like even if you ask pretty please don't touch those files, there's a chance they will. So many people have just willingly installed spyware on their computers and big tech calls this the next big thing.
My first thought would be their server side extentions, code excecutoon sandboxes and document RAG search, being on by default? Probably should be an opt-in instead of an opt-out.
https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547
Elon did this horrible thing, so I made grok build available for omp with it's own endpoint; Without sending your private repos and secret keys to them.
-
oh-my-pi-plugin-grok-build
Standalone oh-my-pi extension for the xAI Grok Build subscription provider. It adds OAuth login, authoritative model discovery, and OpenAI Responses streaming with the request identity expected by Grok Build.
Install (No-spywares):
omp plugin install oh-my-pi-plugin-grok-build
-
https://github.com/metaphorics/oh-my-pi-plugin-grok-build
Star me if you like it or if you hate spywares, lol.
A bot will do what a bot can do whether malicious or accidental. One should assume they are giving DOGE shell access on their computer and adapt accordingly. I am trying to imagine the SELinux rules required to make a bot play nice and the more I think about it such rule complexity may even befuddle the NSA. Alternate methodology:
- Give the bot it's own machine and only copy to it that which one would want DOGE having access to. Not a virtual machine, the bot will eventually escape. This applies to all bots or agents of all LLM's. Name the node DOGE to remind anyone using it not to share their crown jewels. Come up with a silly name for the agent. Elonious?
- Give it a little RasPi or mini-PC with maximum power savings enabled and no default network gateway.
- Install a self signed CA cert on the DOGE node and force it's traffic through a Squid SSL Bump MitM proxy on the same private LAN to another node with bandwidth limits enabled so that one can monitor what URL's it goes to and what data it is transferring. Configure Squid Access Control Lists to only permit specific domains and optionally URL's, mime-types, sizes, etc...
- Enable custom AuditD rules to watch anything it touches outside of it's sandbox. Send these events to a remote syslog daemon on the Squid server.
- Install Unbound DNS on the squid proxy and enable the DoH (DNS over HTTPS) listener and force all bot DNS queries to use Unbound with query logging enabled.
When the bot attempts to misbehave there will be forensic data to share with the world.
The real solution to these kind of problems is sandboxing. I use podman through a bash script to launch a container whenever I want an agent to work on one of my repos. When done I just generate git patches and port back everything generated.
In this way I'm not afraid of letting the agents totally lose on my computer.
I am running all these clis in containered environments. How can you ever trust LLM to respect the bounderies provided by these magical, non-deterministic intructions files...
I'm dying to have proper sandboxing in macOS. I installed ChatGPT, I asked it to list files in my user directory and it did. I never gave it permission, how could it? My terminal has access and honestly it shouldn't either.
102 comments
[ 3.6 ms ] story [ 76.4 ms ] threadOn the other hand, I specifically had grok try hard NOT to read a known key in the project dir (it only saw the first part using a tool, to verify it was present). So there's that.
Posting a complaint about Elon on Elon's platform and tagging him is ballsy. He tends to limit visibility of accounts who do that.
- Give the bot it's own machine and only copy to it that which one would want DOGE having access to. Not a virtual machine, the bot will eventually escape. This applies to all bots or agents of all LLM's. Name the node DOGE to remind anyone using it not to share their crown jewels. Come up with a silly name for the agent. Elonious?
- Give it a little RasPi or mini-PC with maximum power savings enabled and no default network gateway.
- Install a self signed CA cert on the DOGE node and force it's traffic through a Squid SSL Bump MitM proxy on the same private LAN to another node with bandwidth limits enabled so that one can monitor what URL's it goes to and what data it is transferring. Configure Squid Access Control Lists to only permit specific domains and optionally URL's, mime-types, sizes, etc...
- Enable custom AuditD rules to watch anything it touches outside of it's sandbox. Send these events to a remote syslog daemon on the Squid server.
- Install Unbound DNS on the squid proxy and enable the DoH (DNS over HTTPS) listener and force all bot DNS queries to use Unbound with query logging enabled.
When the bot attempts to misbehave there will be forensic data to share with the world.
In this way I'm not afraid of letting the agents totally lose on my computer.
This is why it is important to use open source harnesses instead of shady closed ones.