Grok CLI uploaded the whole home directory to GCS • Hacker News Board

Re: Grok CLI uploaded the whole home directory to GCS

#31

Post by Lwerewolf » Mon, Jul 13, 2026, 2:08 PM UTC

LetsGetTechnicl wrote: post #13

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.

Only guarantee that you can get is the sandbox in which it operates. The model itself is a slot machine and can result in anything, and if its sandbox is nonexistent... here's one possibility.

Re: Grok CLI uploaded the whole home directory to GCS

#32

Post by steve1977 » Mon, Jul 13, 2026, 2:08 PM UTC

dumberquestions wrote: post #10

vorticalbox wrote: post #8

why do people give these LLMs full access to everything and then complain when it does somethign stupid? that is what sandboxes are for.

Other ones aren't this invasive with user data.

Are we sure about that?

Re: Grok CLI uploaded the whole home directory to GCS

#33

Post by ben_w » Mon, Jul 13, 2026, 2:09 PM UTC

throwaway2027 wrote: post #4

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.

Indeed. I use a spare laptop that has no accounts other than (1) the AI themselves, (2) a secondary GitHub account which has "untrusted devices" in the name to emphasise the point.

If I recall correctly, I did a full system reset before setting it up this way. It's certainly not logged into iCloud etc.

Re: Grok CLI uploaded the whole home directory to GCS

#34

Post by Bender » Mon, Jul 13, 2026, 2:10 PM UTC

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.

Re: Grok CLI uploaded the whole home directory to GCS

#35

Post by lobo_tuerto » Mon, Jul 13, 2026, 2:10 PM UTC

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.

Re: Grok CLI uploaded the whole home directory to GCS

#36

Post by hoppp » Mon, Jul 13, 2026, 2:10 PM UTC

steve1977 wrote: post #23

hoppp wrote: post #9

Earlier quoted context omitted.

Much worse, instead of the data gone it's a data leak. Those ssh keys can be used to access private servers

Well, those ssh keys are protected by a strong passphrase, right?

The passphrase is optional, not everyone has it.

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.

Re: Grok CLI uploaded the whole home directory to GCS

#37

Post by ChrisArchitect » Mon, Jul 13, 2026, 2:10 PM UTC

Some more discussion: https://news.ycombinator.com/item?id=48892512

Re: Grok CLI uploaded the whole home directory to GCS

#38

Post by dewey » Mon, Jul 13, 2026, 2:11 PM UTC

docdeek wrote: post #24

dewey wrote: post #17

Earlier quoted context omitted.

When I give my text editor or file browser access to everything I wouldn't expect it to exfiltrate data without asking.

Isn’t a file browser running locally, while Grok is running on someone else’s server?

The point is more that you should not blame the user (why didn't you set up sandbox instead of directly using the tool of big corp) if a tool does something unexpected. If your Dropbox client would suddenly just upload your home directory instead of it's folder you configured you'd also not blame the user that they use Dropbox, you'd blame Dropbox for not doing their job correctly or being user hostile.

Re: Grok CLI uploaded the whole home directory to GCS

#39

Post by stellamariesays » Mon, Jul 13, 2026, 2:12 PM UTC

lobo_tuerto wrote: post #35

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.

[flagged]

Re: Grok CLI uploaded the whole home directory to GCS

#40

Post by hoppp » Mon, Jul 13, 2026, 2:12 PM UTC

crimsonnoodle58 wrote: post #28

hoppp wrote: post #9

Earlier quoted context omitted.

Much worse, instead of the data gone it's a data leak. Those ssh keys can be used to access private servers

SSH keys can be limited by IP in authorized hosts. 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.

All those things are optional.

Doesn't make uploading the keys that much better. Now is the time for key rotation everywhere. Fast.