Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What xAI's Grok build CLI sends to xAI: A wire-level analysis

gist.github.com

Post reply on HN
Print view View original

101–110 of 251 posts

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#101

Post by oseityphelysiol »

freakynit wrote: post #4

"It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads" Holy cow!!!! I mean I kinda expected Elon would do something like this to try to catch-up.. but this is extremely concerning. This is precisely the reason, even though their pricing is competitive and grok-4.5 is actually good enough, I chose not to go with them.

It would be extremely naive to assume Elon, or even a real human had a hand in this. The whole analytics pipeline is very likely vibecoded and never reviewed by a human.

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#102

Post by jeffnash »

This is precisely why I run a custom fork of CLIProxyAPI on a private railway server for all my agentic coding. The OG version is indispensable already and has XAI Oauth support, so you can use your subscription to call Grok from any Anthropic OR OpenAI compatible client (Claude Code, Pi, Codex, you name it). To be honest, though, I am bummed, as I do really like the grok build client. The TUI is great in the ways that matter without going out of its way to make it clear that "I'M A MID-LATE 2020s TUI LOOK AT ALL THE NOT USUAL STUFF YOU CAN DO WITH ME".

Grok aside, this has become an increasingly large concern of mine, especially now that I've expanded my usual provider rotation beyond the big 2. Out of arguably reasonable paranoia, I recently bolstered my own personal CLIProxyAPI fork to use an algo similar to gitleaks/betterleaks to, on the fly, scan the incoming (i.e. from my coding agent) stream for any secrets that may have been transmitted from disk, replace them with a unique identifier, send that off to the upstream provider, and then replace the secret (mapped to that identifier in memory, encrypted and with TTL) before sending any response back. That way, if the "secret" is either not really a secret and/or truly is needed in whatever tool call or response, the replacement is seamless to the client but the provider never sees your code.

No, it's not foolproof: it can't prevent some upstream actor from, say, using the on-disk key to your secret in a rogue tool call that uploads it from your device directly to an endpoint of theirs, but the low-hanging fruit like this is, IMO, the equivalent of not leaving all your windows open when you're naked. Virtually no downside or inconvenience to you, gets probably 3-4 9s of cases where someone would be inclined to see something they shouldn't because it's that easy.

The alternative is literally having to approve every read request (is this even a thing now?) and spend the mental energy ensuring that each and every file could not possibly contain a secret. I'd rather just code by hand at that point.

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#103

Post by dannyw »

Karmakosmik wrote: post #95

Isn't that expected? I always assumed the agent owns (at least) the current workspace (whatever dir it's launched in) and so can do whatever it wants in there. If they actually use this try and do things in the backend and saving prompt RTTs and tool calls that would be in my interest, no?

No, there’s the normal messages API which is what’s used to read files and deliver responses.

The author has identified a second endpoint which exfils your whole project folder, into a GCP storage bucket. Anyone who designs large scale distributed systems can tell this is to scoop up training data.

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#104

Post by potamic »

ashishb wrote: post #46
freakynit wrote: post #4

"It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads" Holy cow!!!! I mean I kinda expected Elon would do something like this to try to catch-up.. but this is extremely concerning. This is precisely the reason, even though their pricing is competitive and grok-4.5 is actually good enough, I chose not to go with them.

There is a reason I run all such CLIs inside a sandbox [1] giving limited directory access. Imagine if the CLI pulled your SSH keys or other sensitive information by mistake? Programmers do make such mistakes all the time. I don't want to count on whether "uploading all files it can access" is intentional or a mistake. 1 - https://github.com/ashishb/amazing-sandbox

The readme is confusing. You say it has bubblewrap, but you also have an FAQ saying why not to use bubblewrap? Another FAQ says why not to use sandbox-exec for mac, yet the link for mac goes to sandbox-exec?

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#107

Post by ashishb »

beepbooptheory wrote: post #51
ashishb wrote: post #46

Earlier quoted context omitted.

There is a reason I run all such CLIs inside a sandbox [1] giving limited directory access. Imagine if the CLI pulled your SSH keys or other sensitive information by mistake? Programmers do make such mistakes all the time. I don't want to count on whether "uploading all files it can access" is intentional or a mistake. 1 - https://github.com/ashishb/amazing-sandbox

But in this particular case isn't the problem that it's sending everything in the sandbox? Rather than what it might do in an otherwise un-sandboxed system?

> But in this particular case isn't the problem that it's sending everything in the sandbox?

If a CLI is touching certain files, they are likely to be leaked one way or the other.

Why not reduce the attack surface?

When does someone visit your house? Do they get unfettered access to your bedroom & safe as well?

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#108

Post by MattGaiser »

processunknown wrote: post #57
jpollock wrote: post #17

Earlier quoted context omitted.

It would be _extremely_ surprising if private repos were available via that contract. Corporations wouldn't use GitHub at all if anyone other than those given direct access had read/copy permission.

It wouldnt be _that_ surprising since they committed widespread copyright violations building the models, plus the recent Apple IP theft...

This speaks to OpenAI's approach to things. But it doesn't speak to Microsoft and Microsoft would need to provide the access.

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#109

Post by phaseleza »

teravor wrote: post #68
phaseleza wrote: post #48

I always separate the coding tools from LLM providers, and use bubblewrap to sandbox the coding tools so they: 1. Can only read the working project directory, with .git read-only and sensitive directories hidden (mounted as empty directories). 2. Have an isolated network namespace; they can only access the internet through an HTTP proxy hosted on a Unix socket, can only access specific LLM provider hostnames, and exc…

with bubblewrap it's better to pull a rootfs from dockerhub (eg. debian:unstable) then bootstrap it into a fully fledged distro rootfs living in its own folder. install the AI agents right into it, then create launch scripts that invoke bwrap with the distro rootfs (readonly) and a custom read-write /home/user and run whatever you want inside it - it will not see anything important outside the directory you give it.…

Thanks for the suggestions. I've used debootstrap to build a Debian rootfs for bwrap before, but my threat model is simpler: nothing sensitive lives outside $HOME on my machine. So I just ro-bind the system dirs I need and give the sandbox a tmpfs home (one-shot apps) or a persistent fake home (stateful apps, under ~/.var/app/). This is good enough for my case.

The gvisor layering looks promising though. I'll take a look and see if it would be useful.

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#110

Post by phaseleza »

timr wrote: post #70
phaseleza wrote: post #48

I always separate the coding tools from LLM providers, and use bubblewrap to sandbox the coding tools so they: 1. Can only read the working project directory, with .git read-only and sensitive directories hidden (mounted as empty directories). 2. Have an isolated network namespace; they can only access the internet through an HTTP proxy hosted on a Unix socket, can only access specific LLM provider hostnames, and exc…

What's your mechanism for doing this?

I use bubblewrap to unshare all namespaces (net, pid, ipc, user) and ro-bind necessary system paths like /etc, /lib, create a tmpfs home, mount the project folder under it (writable), then mount tmpfs over sensitive directories inside the project to hide them.

For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to localhost with socat. With the net namespace unshared, the app can't reach the network at all except through this proxy, which only allows LLM providers.

By separating the coding tool from the LLM provider, I feel safer: the coding tool cannot leak anything on its own. It can only talk to the LLM provider, so a real leak would require the provider to be complicit too. And any sensitive files, inside or outside the project, are hidden by the mount namespace, which I suppose is hard to escape.

Post reply on HN