FRESH
Hacker News
Hacker News Hacker News1. 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 exclude the tool's own hostname.
For example, with Crush, I will let it access *.openrouter.ai (LLM providers) but not *.charm.land (Crush's domain for auto-updating the LLM list).
This makes me feel much more comfortable enabling "yolo" mode and letting the tools do everything.
```
export GROK_TELEMETRY_TRACE_UPLOAD=0
export GROK_TELEMETRY_ENABLED=0
# or config file with [telemetry] trace_upload = false, [harness] disable_codebase_upload = true
```
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.
Suddenly they became aware that the AI agents are not actually running on their computers. AI agents are just uploading the shit on some servers for how long they want and in exchange of that you pay them and get some work done.
I am surprised through that nobody is asking if the agents are GDRP compliant or if they are even legal considering they are trained with illegal/copyrighted content or if you are liable for theft because now you own, publish and sell illegal content generated by agents….
Enough ranting…instead of this stuff people should just admit that after social media, AI is the new frontier towards a kind of zero privacy, at least until you can have local AI/if ever.
It’s much safer to use something like opencode and use models via their API… however, the tradeoff is that it will never perform as well as it does in their native agent runners…
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.
If you adjust your expectations, I think it's be better to upload the code to their servers instead of sending it through context over and over again.
Nonetheless, this is disturbing.
will this endup in their "everything app"?
guess you do not need to build "everything" yourself, when you can steal it.
It's not a great state of affairs, but that's where we are.
Choose wisely my friend.
I will say, a majority of the code I'm writing now is fully through an online LLM. If a company wanted to reconstruct a project I'm working on, they could just replay all of the tool calls from their logs, if they decide to retain the data (I did this locally once to recover a project that I mistakenly clobbered in Git).
Still, this is a big overstep IMO. At the very least, they should make it clear in their terms of service and privacy policy, and not hidden through legalese. Not all usage of Grok Build will be through their enterprise plan which offers ZDR.
I don’t understand why anyone would be surprised that they’re also stealing code from their users. Pay attention to what people like Musk do to those under their power. He will do the same to you in a heartbeat.
Oh wow that's real bad. I'm assuming most AI shops' own harnesses do something similar when you opt in for their data collection, but them doing it even if you turn it off is diabolical.
It's not a really great reason, because what's the downside of going back to the client? But that's the best reason I can think of.
Does anyone know if there's anyone else who has reproduced these findings for themselves yet?
Well yeah, obviously, that's pretty much intended behaviour. The LLM can't determine that there are secrets in your file before reading them.
The real issue here is that you're giving an LLM access to a file with plain-text secrets and then surprised that it reads that file.
The fact that the whole repo is automatically uploaded is crazy though, especially for multi-gigabyte repositories. This could take a long time on some connections, and seems generally pointless — unless there's some ulterior motive for uploading all this data.
If it does, I’m not sure what to recommend. Even Anthropic and OpenAI might be training on your code anyways. See: Alex Karp.
This has to be the most successful mass surveillance campaign of all time
In view of this, I should probably go further and bubblewrap it to restrict /etc, /proc and other things it legitimately does not need to do its job. I already do that for programs such as Steam (and games therein) to mitigate the possibility that they may spy on me.
-All disputes to be dealt with by arbitration
-You agree to not have a trial by Jury
If you go with an Elon company, you kinda have to expect ruthlessness
This is another reason to use open source harnesses and open weight local models.
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.
[harness]
disable_codebase_upload=truehttps://electrek.co/2026/07/10/musk-tells-tesla-staff-switch...
Why do you continue to give these companies all your secrets, env vars, source code and data? That is effectively a data breach by this form of malware.
If you had data that was never meant to be uploaded or shared by a third party, consider that a security incident.
When I see a report like that I just assume it's a low-effort AI slop and stop reading immediately. Why would I read it since I can do the same with my agent and with that understand it better? Or if I'm really lazy then just copy paste this report and ask for a summary or have a discussion.
elon musk: hello human resources
it's like purposefully running into a brick wall and giving yourself a concussion. you have to be a dumbass to do it.
Config after fix (~/.grok/config.toml)
[harness]
disable_codebase_upload = true
[telemetry]
trace_upload = false
[features]
telemetry = falseGrok 4.5 is so fast, it's great. And only $10/month subscription. It's slightly less censored as well.