Absolutely not. That would be an absurd violation. If you have Copilot enabled then they can use your interaction data for training but you can turn that off as well
GitHub Copilot engineer here working on identity, safety, and privacy - no, even Microsoft doesn’t have access to all GitHub repos.
As years have passed since the acquisition “company” delineations have blurred a bit, but Microsoft employees still need to go through a separate onboarding process to access any GitHub company resources (internal repositories, telemetry, documentation, etc.), and then we have an additional layer of entitlements to gate and audit access to any sensitive data, including user data.
Very few employees within GitHub proper even have access to view private repositories, and in the rare cases where that’s done for legal or safety reasons the repository owner is notified.
There are currently no OpenAI employees with access to GitHub systems, so there’s about 4 layers of protection in place to prevent private repositories access. We do genuinely take user data protection and privacy seriously.
How do you define "access" here? Microsoft has demonstrated that it can delete any GitHub repo at will. Maybe there's some shell entity between corporate "Microsoft" and "GitHub" that's doing the dirty deeds without attribution...
Prove that I work at GitHub? Username + LinkedIn can show (not prove) that easily.
Prove that we have an entitlements system which regulates and audits access? I could point you to https://github.com/entitlements, but it’s all private repositories so that won’t prove much either.
Prove that there are no OpenAI employees with access to GitHub systems? Not sure how I’d do that without dumping (what you would still need to trust me is) the entirety of our org chart/HR system, which I’m not willing to do because I do enjoy being employed and am not exactly obfuscating my identity here.
Prove that HN has a strong anti-Microsoft bias? Well that one is pretty easy actually, you’re helping prove it yourself!
Let’s be real, we now live in a post-truth world. Nothing can truly be proven or disproven outside of formal logic and mathematics. You can either believe what I’m saying as good faith insider knowledge sharing (which is unfortunately rare nowadays) or you can not. Makes no difference to me.
That is my point! The fact that there are a lot of people that will believe what you are stating without a reasonably proof is what makes me sad and worry about the future. That kind of statements you are doing are enough to put in company webpage and term of service and thats it. Any attempt to repeat them as if they are true makes:
1) The messenger looks good in the eyes of stupid and innocent people.
2) The messenger looks stupid in the eyes of people that have reasonable doubts about company statements that are agains their own interest.
This is a nice answer to the question "how is GitHub preventing rogue employees at Microsoft from stealing my private repositories?". Like, it's good to know I'm covered if Microsoft accidentally hires a North Korean spy or something.
But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.
Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.
I’m one of the people directly responsible for ensuring that those terms are properly enforced. Presently I’m arguably the person for Copilot data specifically.
Current talk of the town in the data retention space is around AI safety. There’s been a recent slew of blog posts and academic papers around how LLM harms can manifest over multiple agentic turns, from individually innocuous requests. Identifying this inherently necessitates user data retention which we do everything possible to avoid (not even meaning data sharing as is alluded to in this thread, I mean literally persisting prompts and completions anywhere outside of ephemeral memory). I’ve been the one advocating for having the storage of any data retained for safety and security purposes to be as heavily access controlled and audited as is possible.
Also, if AI safety is a space that is interesting to you, we’re hiring! Manager, developer, and applied science roles, or we can figure out the HR shenanigans if you don’t fit any of those archetypes. If interested shoot me an email at taywrobel@github.com!
> Very few employees within GitHub proper even have access to view private repositories
so we're just discussing what business Microsoft likes more at any moment. and you didn't provide a list of allowed use cases (is Ai training one?). making your huge answer(s) empty and not contributing one yota. sorry.
i feel your job exist to uphold the illusion and you will not see it any other way.
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.
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?
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.
It almost certainly already is, at least in some jurisdictions for some forms of data. GDPR, HIPAA, CCPA, biometric privacy, et cetera almost certainly will find claws into this behaviour.
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.
Doesn't matter if it was maliciously stealing literally all contents and secret keys, or if this was merely something vibe-coded that accidentally slipped past QA, the behaviour documented here would get a human developer not only fired but also prosecuted (stealing all the keys and all the code?!), unlikely to get further work, and if not naturalised or a citizen of the country they were in then deported; while the parent company employing a person who acted like Grok is reported to be acting here is likely facing privacy regulator investigations, consent orders, fines, etc.
Sure shouldn't use any software that behaves like this for, e.g. classified work at the Pentagon. If the Pentagon is using this for internal secret planning, like they're boasting they are, this is waaaaay into the "potential catastrophe" (for the US) territory:
Snowden was selective about what he leaked, and still had security people calling for him to get the death penalty.
(meme format aside, this is one for "when people tell you who they are, believe them", along with a demonstration of why "only hurting the right people" is a very dangerous value)
One reason to want to upload the entire codebase is that it allows them to have the model inspect the codebase during "thinking" without going back to the client to do real tool calls.
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.
more like it allows them to steal your trade secrets, app designs, internal business knowledge, or even just replicate whatever code/app/tool/process you had.
what was your private code, becomes their code now.
I think it’s so people can “remote control” from their phones even if their computer is offline, via a container somewhere. Then they can get back to local dev, syncing the changes from their GCP bucket.
Seems reasonably useful to me - not give-Elon-my-entire-repo useful, but useful. The fact that they made it something you can’t opt out of and wasn’t disclosed at all really reinforces that they shouldn’t be trusted with it.
If a harness wants to upload the whole codebase in one batch, it should explicitly inform the user about it. Instead of exfiltrating the data without consent.
It’s funny how you’re always policing me and not the thousands of other people that are posting much worse things.
I’d be happy if there was a version where I can just see links, comments and add posts to favourites. That’s all I need really.
It always feels like the mods are against you, and it always feels like others are doing worse. These are fixtures of internet forum psychology and you are far from the only one who feels that way.
If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. You can help by flagging it or emailing us at hn@ycombinator.com.
Still, other people breaking the site guidelines doesn't make it ok for you to also break them, and pointing the finger at others, as if you needn't correct your own behavior, is unhelpful.
If you've gotten multiple moderation responses, the likeliest reason is that you've broken the site guidelines multiple times. Btw, it's nothing personal—we don't know anything about you—and the answer to your "it's funny" is that it's simply random.
I'm sure it's true that other people have done the same or worse and not gotten the same replies, because that's how randomness works. We do our best within the quantity limits of what we're physically able to read and respond to.
using them in VSCode all the time for months now. Qwen from Alibaba Cloud, Deepseek from deepseek.com. none of them upload entirety of codebase or even attempt to.
in fact, opposite. Chinese AI seem to post-process heaviliy locally.
they are always using head / tail, grep, sed, and do as much as they can locally and extrac meaningful data and send home (AI inference chunks). only what is really needed.
it is actually hard to force Chinese AI modesl to read full files, they really do not want to see them. even 400 lines files, is usally hit first for first line, first 50 lines. and at most 200 lines chunk reads, and give up at one or two reads.
For me, them allowing API usage on coding plans so we can use any harness, and returning the full unabridged reasoning back are how they earned my trust.
I verified it statically that the config value is checked and skips the upload code. I don't have a subscription, so it would be cool if someone could verify it statically.
This is one of the reasons why native proprietary coding agent runners like claude-code, codex, grok-build etc are so dangerous for privacy… you just don’t know what “secret sauce” they’ll add in the next update…
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…
That's a major problem in its own right. Yes, not updating an XP SP1 RCE immediately is dangerous, but in the last couple decades I've seen far more damage inflicted from automatic updates than what I think the lack of them would have caused.
> however, the tradeoff is that it will never perform as well as it does in their native agent runners
There's no reason to assume that. The recent Databricks benchmark in fact showed the exact opposite - that using Pi vs native agent both outperformed native agents in terms of task success, and did so cheaper due to using less tokens.
since github. or you truly believed your code was private in private repos? I never understood that belief of a label on a button.
since jira-cloud, or you truly believed your processes were private?
leaks are assured, but centralisation amplifies impact. no one cares if your self-hosted something gets owned _because_ it does not affect anyone else.
At this stage passwords are irrelevant. You already moved your data out. This is all there is to it: either you control access, or you don't and then all bets are off.
It is common knowledge that any ai tool will upload whatever it has access to.
So why the drama? It did what it was designed to do and what you consented to by using it.
If you don't want your foot sawn off learn maybe something about tool safety.
Grok Build has had impressive performance in a couple of my projects. And fast. So this revelation has been very disappointing...
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 know why anyone would use Grok Build when they could use Cursor, with access to both Grok-4.5 and Composer-2.5-Fast and astonishingly cheap prices, and easy access to Opus if you need it.
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 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.
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. you can also run multiple agents each invisible to the others.
for bonus points you can uplift the bwrap container into an actual sandbox by invoking gvisor (`runsc ... do ...`) from inside it, or a virtual machine like muvm. I'm really fond of this pattern because you can trust bwrap to set up the environment, then you just need a sandbox tool to lock it down. note that bwrap by itself isn't really a sandbox, whatever is running inside it has a lot of kernel surface to attack (which can be somewhat mitigated by compiling strict seccomp filters and passing them to bwrap).
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/<appname>). 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.
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.
> I mount the Unix socket into the sandbox and bridge it to localhost with socat
I was experimenting with network sandboxing and found a solution that doesn't require an agent inside a sandbox. You can create listening socket on localhost inside the sandbox, send it over the Unix socket to the supervisor outside and close the Unix socket. The supervisor outside now has a listening socket that accepts connections from inside. No socat needed.
My setup was more complicated though, I wanted transparent proxying (intercepting every TCP/UDP connection without having to specify a proxy) and I spent 2 nights fighting with lack of documentation on netfilter. For TCP I ended up with creating a listening socket with IP_TRANSPARENT options and tproxy'ing all traffic into it using nftables. It was easy part. The difficult part was to figure out how to intercept UDP datagrams and send replies with correct sender address. I ended up creating IP_TRANSPARENT listening UDP socket to receive datagrams, and raw IP socket to send replies with forged source address (because single UDP socket doesn't allow sending datagrams from arbitrary port number).
ChatGPT was pretty much useless, probably due to lack of documentation and I had to experiment myself.
I still do not have the supervisor done though, that would decide whether to allow or block a connection. I have the following idea: whenever the target makes a DNS request, I reply with a new IP address like 10.x.x.x. So I can have a map which maps every IP address to a domain, and when a program connects to an IP, I can figure out which domain it is and decide whether allow or block it. This is necessary because there might be multiple IPs for a domain, they can change in time, so it is better to have a persistent mapping, to protect from DNS rebinding attacks.
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
+1 for bubblewrap, unsharing everything and then adding back everything your agent needs saves the trouble of updating a docker image and allows you to give selective access to local tooling. I actually go as far as to run nearly every. single. application. in bwrap that doesn't come with native sandboxing. I share credential authentication via sockets, had to build custom schemas for k8s and docker since they still don't have a way to do remote attestation...
It still somewhat blows my mind that xAI is somehow allowed to operate per European law. Closest I can come to is Musk is above the law even in the EU given his relationship to Trump.
Claude gets its own UNIX account on my dev machine. I would never trust it not to read .ssh or other sensitive private information in my home directory or elsewhere.
In view of this, I should probably go further and bubblewrap it to further 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.
Isn't it assumed that the AI agent is allowed to read your files in the directory you launch the harness? Most agents read your code on the first prompt, including any secrets you have there, which you shouldn't have. Also the .env file is for local environment, and shouldn't contain any actual secrets. AI agents should be isolated from any actual secrets, because they can't be trusted to follow instructions.
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.
> Isn't it assumed that the AI agent is allowed to read your files in the directory you launch the harness?
Yes. There's very little story here. Maybe Grok is being like 10% more aggressive than other providers in how they assemble context (more likely: it was faster to ship this way), but any provider has the ability to do the same thing, and will happily do it if it helps improve results. Authors acknowledge this openly, but it's buried:
> "Cloud AI tools send context; this is normal." True, and conceded: any cloud coding agent must send code to its server to act on it. The novel deltas here are (a) a secrets file (e.g. .env) is transmitted unredacted, (b) the content is persisted to a named GCS bucket, not just processed transiently, and (c) the upload mechanism is not surfaced in the CLI's setup materials (§7) and on by default.
This is the entire controversial portion of the finding, in a single paragraph.
As far as the .env thing goes, you shouldn't be putting unencrypted .env files in the accessible path of any LLM. If you do, you're asking for trouble. It would obviously be better if Grok identified secrets and ignored them, but this is not a behavior you should rely on.
this is bad... but just for chuckles, i asked grok cli to check disclosure and look through the binary and logs to see which config would stop it from doing that. no idea if it truly works, but here it is:
> The "Improve the model" toggle makes no difference — ON or OFF, the whole repo is uploaded the same way.
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.
147 comments
[ 2.3 ms ] story [ 64.6 ms ] threadHoly 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.
As years have passed since the acquisition “company” delineations have blurred a bit, but Microsoft employees still need to go through a separate onboarding process to access any GitHub company resources (internal repositories, telemetry, documentation, etc.), and then we have an additional layer of entitlements to gate and audit access to any sensitive data, including user data.
Very few employees within GitHub proper even have access to view private repositories, and in the rare cases where that’s done for legal or safety reasons the repository owner is notified.
There are currently no OpenAI employees with access to GitHub systems, so there’s about 4 layers of protection in place to prevent private repositories access. We do genuinely take user data protection and privacy seriously.
Prove that I work at GitHub? Username + LinkedIn can show (not prove) that easily.
Prove that we have an entitlements system which regulates and audits access? I could point you to https://github.com/entitlements, but it’s all private repositories so that won’t prove much either.
Prove that there are no OpenAI employees with access to GitHub systems? Not sure how I’d do that without dumping (what you would still need to trust me is) the entirety of our org chart/HR system, which I’m not willing to do because I do enjoy being employed and am not exactly obfuscating my identity here.
Prove that HN has a strong anti-Microsoft bias? Well that one is pretty easy actually, you’re helping prove it yourself!
Let’s be real, we now live in a post-truth world. Nothing can truly be proven or disproven outside of formal logic and mathematics. You can either believe what I’m saying as good faith insider knowledge sharing (which is unfortunately rare nowadays) or you can not. Makes no difference to me.
But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.
Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.
Current talk of the town in the data retention space is around AI safety. There’s been a recent slew of blog posts and academic papers around how LLM harms can manifest over multiple agentic turns, from individually innocuous requests. Identifying this inherently necessitates user data retention which we do everything possible to avoid (not even meaning data sharing as is alluded to in this thread, I mean literally persisting prompts and completions anywhere outside of ephemeral memory). I’ve been the one advocating for having the storage of any data retained for safety and security purposes to be as heavily access controlled and audited as is possible.
Also, if AI safety is a space that is interesting to you, we’re hiring! Manager, developer, and applied science roles, or we can figure out the HR shenanigans if you don’t fit any of those archetypes. If interested shoot me an email at taywrobel@github.com!
so we're just discussing what business Microsoft likes more at any moment. and you didn't provide a list of allowed use cases (is Ai training one?). making your huge answer(s) empty and not contributing one yota. sorry.
i feel your job exist to uphold the illusion and you will not see it any other way.
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
Why would you let a markdown linter access your ssh keys?
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/
It almost certainly already is, at least in some jurisdictions for some forms of data. GDPR, HIPAA, CCPA, biometric privacy, et cetera almost certainly will find claws into this behaviour.
Doesn't matter if it was maliciously stealing literally all contents and secret keys, or if this was merely something vibe-coded that accidentally slipped past QA, the behaviour documented here would get a human developer not only fired but also prosecuted (stealing all the keys and all the code?!), unlikely to get further work, and if not naturalised or a citizen of the country they were in then deported; while the parent company employing a person who acted like Grok is reported to be acting here is likely facing privacy regulator investigations, consent orders, fines, etc.
Sure shouldn't use any software that behaves like this for, e.g. classified work at the Pentagon. If the Pentagon is using this for internal secret planning, like they're boasting they are, this is waaaaay into the "potential catastrophe" (for the US) territory:
Snowden was selective about what he leaked, and still had security people calling for him to get the death penalty.
> look inside
> it does evil things to you too
(meme format aside, this is one for "when people tell you who they are, believe them", along with a demonstration of why "only hurting the right people" is a very dangerous value)
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.
what was your private code, becomes their code now.
will this endup in their "everything app"?
guess you do not need to build "everything" yourself, when you can steal it.
Big difference vs xAI, where the sentiment is valid.
we definitely have that level of mental deficiency in this country..
> People just submitted it. I don't know why. They 'trust me'. Dumb f..ks.
- Zuckerberg circa 2004, in case anyone is out of the loop
https://news.ycombinator.com/newsguidelines.html
Edit: I suppose I'd better add that this is not a defense of $THAT_GUY - just an attempted defense of HN comment quality.
Edit 2: Could you please stop posting unsubstantive comments and flamebait generally? It's not what this site is for, and destroys what it is for.
For example, we ban accounts that post things like https://news.ycombinator.com/item?id=48878096 and your account history unfortunately has quite a bit of this. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. You can help by flagging it or emailing us at hn@ycombinator.com.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Still, other people breaking the site guidelines doesn't make it ok for you to also break them, and pointing the finger at others, as if you needn't correct your own behavior, is unhelpful.
If you've gotten multiple moderation responses, the likeliest reason is that you've broken the site guidelines multiple times. Btw, it's nothing personal—we don't know anything about you—and the answer to your "it's funny" is that it's simply random.
I'm sure it's true that other people have done the same or worse and not gotten the same replies, because that's how randomness works. We do our best within the quantity limits of what we're physically able to read and respond to.
in fact, opposite. Chinese AI seem to post-process heaviliy locally.
they are always using head / tail, grep, sed, and do as much as they can locally and extrac meaningful data and send home (AI inference chunks). only what is really needed.
it is actually hard to force Chinese AI modesl to read full files, they really do not want to see them. even 400 lines files, is usally hit first for first line, first 50 lines. and at most 200 lines chunk reads, and give up at one or two reads.
How do you know? Did you do an analysis like OP did?
Have you verified this flag is respected?
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…
That's a major problem in its own right. Yes, not updating an XP SP1 RCE immediately is dangerous, but in the last couple decades I've seen far more damage inflicted from automatic updates than what I think the lack of them would have caused.
There's no reason to assume that. The recent Databricks benchmark in fact showed the exact opposite - that using Pi vs native agent both outperformed native agents in terms of task success, and did so cheaper due to using less tokens.
It's not a great state of affairs, but that's where we are.
Choose wisely my friend.
Nonetheless, this is disturbing.
This has to be the most successful mass surveillance campaign of all time
since jira-cloud, or you truly believed your processes were private?
leaks are assured, but centralisation amplifies impact. no one cares if your self-hosted something gets owned _because_ it does not affect anyone else.
...
It is common knowledge that any ai tool will upload whatever it has access to.
So why the drama? It did what it was designed to do and what you consented to by using it.
If you don't want your foot sawn off learn maybe something about tool safety.
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 find Deepseek to be a great compromise between cost and performance. Anthropic and OpenAI are simply too expensive at this point.
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 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.
for bonus points you can uplift the bwrap container into an actual sandbox by invoking gvisor (`runsc ... do ...`) from inside it, or a virtual machine like muvm. I'm really fond of this pattern because you can trust bwrap to set up the environment, then you just need a sandbox tool to lock it down. note that bwrap by itself isn't really a sandbox, whatever is running inside it has a lot of kernel surface to attack (which can be somewhat mitigated by compiling strict seccomp filters and passing them to bwrap).
The gvisor layering looks promising though. I'll take a look and see if it would be useful.
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.
I was experimenting with network sandboxing and found a solution that doesn't require an agent inside a sandbox. You can create listening socket on localhost inside the sandbox, send it over the Unix socket to the supervisor outside and close the Unix socket. The supervisor outside now has a listening socket that accepts connections from inside. No socat needed.
My setup was more complicated though, I wanted transparent proxying (intercepting every TCP/UDP connection without having to specify a proxy) and I spent 2 nights fighting with lack of documentation on netfilter. For TCP I ended up with creating a listening socket with IP_TRANSPARENT options and tproxy'ing all traffic into it using nftables. It was easy part. The difficult part was to figure out how to intercept UDP datagrams and send replies with correct sender address. I ended up creating IP_TRANSPARENT listening UDP socket to receive datagrams, and raw IP socket to send replies with forged source address (because single UDP socket doesn't allow sending datagrams from arbitrary port number).
ChatGPT was pretty much useless, probably due to lack of documentation and I had to experiment myself.
I still do not have the supervisor done though, that would decide whether to allow or block a connection. I have the following idea: whenever the target makes a DNS request, I reply with a new IP address like 10.x.x.x. So I can have a map which maps every IP address to a domain, and when a program connects to an IP, I can figure out which domain it is and decide whether allow or block it. This is necessary because there might be multiple IPs for a domain, they can change in time, so it is better to have a persistent mapping, to protect from DNS rebinding attacks.
https://github.com/GreyhavenHQ/greywall
In view of this, I should probably go further and bubblewrap it to further 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.
Apple Intelligence does along with any PII, which makes it harder to code for.
https://electrek.co/2026/07/10/musk-tells-tesla-staff-switch...
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.
Yes. There's very little story here. Maybe Grok is being like 10% more aggressive than other providers in how they assemble context (more likely: it was faster to ship this way), but any provider has the ability to do the same thing, and will happily do it if it helps improve results. Authors acknowledge this openly, but it's buried:
> "Cloud AI tools send context; this is normal." True, and conceded: any cloud coding agent must send code to its server to act on it. The novel deltas here are (a) a secrets file (e.g. .env) is transmitted unredacted, (b) the content is persisted to a named GCS bucket, not just processed transiently, and (c) the upload mechanism is not surfaced in the CLI's setup materials (§7) and on by default.
This is the entire controversial portion of the finding, in a single paragraph.
As far as the .env thing goes, you shouldn't be putting unencrypted .env files in the accessible path of any LLM. If you do, you're asking for trouble. It would obviously be better if Grok identified secrets and ignored them, but this is not a behavior you should rely on.
The only reason to do this is so that Musk has clean training data for his next model. Project setup, popular libraries, CI workflows, etc.
``` Config after fix (~/.grok/config.toml)
[harness] disable_codebase_upload = true
[telemetry] trace_upload = false
[features] telemetry = false ```
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.