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

171–180 of 251 posts

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

#171

Post by kordlessagain »

exitb wrote: post #71
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

What’s described here isn’t connected to the agentic/AI nature of the software at all. Every single program you run as a regular user could potentially do this.

Open source project are unlikely to do this, however.

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

#172

Post by kordlessagain »

Mitigation for use:

  ```
  export GROK_TELEMETRY_TRACE_UPLOAD=0
  export GROK_TELEMETRY_ENABLED=0
  # or config file with [telemetry] trace_upload = false, [harness] disable_codebase_upload = true  
  ```
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.

I've built Nemesis8 (n8) for blast radius control and monitoring these sorts of things, from containers: https://github.com/deepbluedynamics/nemesis8

I've added the mitigation above to the image build for Grok Build instances. There is a lot of telemetry already turned on in n8 containers, so will investigate further.

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

#173

Post by kordlessagain »

whateveracct wrote: post #114
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's straight up data exfiltration and should be illegal

I'm not arguing for what they are doing, but if you use a coding agent to do work on a project, eventually it will have most of the code anyway. Granted, this is very conveniently placed for pickup and ingestion.

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

#175

Post by cowpig »

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?

This is an option:

https://github.com/GreyhavenHQ/greywall

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

#177

Post by ashishb »

qup wrote: post #142
ashishb wrote: post #79

Earlier quoted context omitted.

And I run most of them inside sandbox now. Why would you let a markdown linter access your ssh keys?

Because I'm confident nothing will happen if it does

> Because I'm confident nothing will happen if it does

Well, best of luck.

1. Amazon has shipped backdoored packages - https://aws.amazon.com/security/security-bulletins/AWS-2025-... 2. Scanners like Trivy have been compromised - https://socket.dev/blog/trivy-under-attack-again-github-acti... 3. Redhat is shipping backdoored FOSS packages - https://access.redhat.com/security/vulnerabilities/RHSB-2026... 4. Even fake and malicious ESLint packages have been published - https://gbhackers.com/eslint-package-attack/

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

#179

Post by petesergeant »

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?

This achieves much the same thing but using docker, not bubblewrap. `byre develop` drops you into your agent in a sandbox with the current folder mounted. Enabling the firewall or mounting other folders is a few seconds in `byre config` (although you can also switch the firewall on by default). https://github.com/pjlsergeant/byre
Post reply on HN