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.
Relevant read: https://news.ycombinator.com/item?id=48877371
> The practical takeaway for users: your entire codebase leaves (uploaded) your machine unencrypted on each Grok Build invocation, not just files you ask it to read, and no visible setting stops it.
Those ssh keys can be used to access private servers
It also has to be a secure password, people often don't care because it's a local file and generally not exposed to the internet.
The SSH port itself can be limited by IP in firewalls.
Finally, the SSH private key can be encrypted with a password.
Defense in depth is needed. Storing a ssh private key in plain text with no IP restriction is no different to having a password manager store your passwords in plain text on your HD.
Doesn't make uploading the keys that much better. Now is the time for key rotation everywhere. Fast.
If I recall correctly, I did a full system reset before setting it up this way. It's certainly not logged into iCloud etc.
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.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. Give it a little RasPi or mini-PC with maximum power savings enabled. Install a custom CA cert and force it's traffic through a Squid SSL Bump MitM proxy with bandwidth limits enabled so that one can monitor what URL's it goes to and what data it is transferring.
In this way I'm not afraid of letting the agents totally lose on my computer.
Putting it in ALL CAPS!
It's simple sandboxing based solely on unix file permissions. Albeit weak, I find the isolation sufficient. Until I'm shown otherwise it seems like a good compromise given how easy it is.
You can also create iptables rules matching on the user, so this technique is useful for applications where you want to restrict network traffic as well, and don't need stronger or more fine-grained isolation mechanisms.
I don't think the LLM had anything to do with this decision at all. It looks like the Grok tool starts a session by deterministically kicking off a full upload of the user's current repository (and maybe their directory if not version tracked? Not clear if this user had previously run "git init" in their home directory) to Grok's servers.
One possible "innocent" explanation could be that xAI then run vector embedding on every file to help later provide the right context. I don't think thats a worthwhile tradeoff here, especially since other popular coding agents get by just using grep/ripgrep run locally.
You obviously haven't worked anywhere security sensitive.
I'm not talking about whether what Grok did is bad or good, I'm talking about protecting your private key and the servers you connect to.
An unencrypted private key is no different to an unencrypted password manager, and thats a fact. Dont store secrets in plain text.
Do you think a person's private computer is a secure workplace?
If it was security sensitive space there would be no agents running amuck.
I challenge any agent to do worse than an intern with root access.
You can't trust the agent, let alone its harness, to oberve any particular directive you give it, so "md files" provide no meaningful protection for anything important.
But users are broadly reckless and naive and commercial vendors are exploitative and irresponsonsible, so the vendors take advantage of what they can get away with for as long as they can get away with it.
Use a tight sandbox, and join the chorus loudly when others press on vendors to be make user safety an earnest and hard-to-abandon priority.
No, there isn't. I just don't understand how naive (or imbecile) people are. The most valuable thing for these companies is people's data used for training, so giving unrestricted access to a tool from them and believing they will never take advantage of it to gobble up whatever they want from your computer, just because they told you they'll never do that, swearsies, is naive, or incredibly stupid.
Insulate yourself, or better yet, go local whenever possible, and there isn't much you can't do local if you have enough patience.
newaccountman2•53m ago
InsideOutSanta•16m ago
Having said that, this is still absolutely fucked up. People who should have known better also deserve not to be treated like shit. All of us should have known better at some points in our lives and didn't.
fundad•14m ago