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.
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.
(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)
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!
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...
Access meaning read, modify, delete, etc. Pretty standard definition, unless you know of a different meaning of access I’m not privy to.
Microsoft can certainly request that we perform actions against repositories, as can governments, customers, random people on the street, etc. Whether action is taken in those cases is a question for lawyers to fight over, but we have the engineering guardrails in place to require it to be an intentional, audited action.
I appreciate the spicy question tho, even if misguided!
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.
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.
Disclosing private repos against the owner's intent is a much more immediate and significant business risk than violating the license of open source code.
Nothing is beneath Altman, maybe, but Satya isn’t that dumb. MSFT cares about OAI but giving access to private data and trade secrets voluntarily would be catastrophic for them.
Doesn’t feel like the type of mistake Satya would make.
The AI systems ingest tons of copyrighted data and that is stealing/theft(or so we peasants were told). It’s not like they don’t know they are doing. It looks like MSFT doesnt care that much either.
How did book publishers figure out ai stole from them? Can people use a similar way to figure out if their private repos have become part of the training corpus?
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
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?
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?
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.
> 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.
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.
I'd be happier if that gist had been actually written by a human. As it is, I have very little way of verifying, until someone else can confirm the findings, that the AI tool that produced that report didn't hallucinate part or all of it. It might all be accurate, for all I know, the point is that I'm having a hard time trusting an AI-generated report until it's been verified.
Does anyone know if there's anyone else who has reproduced these findings for themselves yet?
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 monitor 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.
bwrap by itself will probably be sufficient against most adversaries as assuming proper config it would require committing to using a linux kernel 0day to escalate privs.
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.
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…
Give enough usage, you can reconstruct an entire codebase via tool calls alone, and it'll be entirely undetectable because it's all done server side. Whatever grok's doing is just more blatant, but using opencode or whatever doesn't create a meaningful security boundary. It's like the meme of using cheetos as a lock.
Is the server side open-source too, as gruez brought up in the sibling comment?
Technically they can still do potentially any- and everything undetected there; and for what it’s worth, even with a closed-source client bad behavior would get detected eventually through network inspection.
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.
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.
Yeah this could be boiled down to maybe 2-3 paragraphs with maybe a few code blocks to show what's uploaded. This AI report is just a slog to read through and turned me off after 10s of skimming.
The icing on the cake is that users are ostensibly paying for the privilege. What a business model...
If I had no morals and was running one of these companies I would be stealmaxxing before anyone notices the scale of the grift and regulations start getting in the way.
I'm not saying they are doing this, but that's what the incentives are lined up for.
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.
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.
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.
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.
Your trade secret is already gone the moment you unleashed non local ai agents on your codebase.
This is why I keep a separate repo for important parts that I do not want competitors to get access to, and only use ai on dumb parts which I don't care if get leaked tomorrow.
A) leaking structured fully working complete set of files (full working recipe) that is not relevant to AI queries at all.
B) adhoc random queries, bits and pieces, grep of chunks of random files and local bash post-processing for AI queries at hand. which is hard to use for anyting anyways, and will end up in just corups of trainig data (CommonCrawl quality — meaning, not good). (not full recipe).
Not the same thing. Cloud hosting couldn't get away with stealing your stuff. They would lose all trust, which was far more valuable than any individual piece of content.
But AI is literally all about stealing and reselling content under the protection of "AI did it" and "whoopie, we'll take a slap on the wrist". It's reasonable to assume all of the frontier companies are doing this to the maximum extent they can get away with.
Yeah, I'm not sure the level of trust extended to a company like Amazon or Google will also be extended to one run by Elon Musk, who is notorious for not respecting terms like this.
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.
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.
If I buy one thing and get a worse alternative, I usually call that a scam. $30k for a car, and it feels the need to summarize my location patterns and sell that to adtech agencies without bothering to even notify me? That's a scam. $X for a code generation tool, and it feels the need to ship all my passwords and other sensitive information to a known user-hostile entity? Also a scam. The fact that I can ~clip the antenna~ sandbox the malicious code doesn't make it not a scam; it might be a practical stopgap, but the offenders still basically got away with it.
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 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.
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.
Weird. I have seen it asking the harness to do `find ~ -type f | grep` to try and find my agent configuration .json file when I asked it to add a MCP server. Stupid, but they weren't sending the files back home. This was with older models though. Newer ones are a bit smarter than that.
It still somewhat blows my mind that xAI is allowed to operate in Europe given e.g. GDPR et al. Closest I can come to is Musk is above the law even in the EU given his relationship to Trump.
I verified it statically that the config value is checked and skips the upload code if it is set to true. I don't have a subscription, so it would be cool if someone could verify it statically.
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:
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.
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.
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.
(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)
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!
Microsoft can certainly request that we perform actions against repositories, as can governments, customers, random people on the street, etc. Whether action is taken in those cases is a question for lawyers to fight over, but we have the engineering guardrails in place to require it to be an intentional, audited action.
I appreciate the spicy question tho, even if misguided!
This is not spicy, this is basic infosec.
And since you presumably knew that already (as it is basic infosec) then yes it is spicy, or simply antagonistic.
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.
Maybe that shouldn't be the case, but it is.
Federal Cyber Experts Thought Microsoft’s Cloud Was “a Pile of Shit.” They Approved It Anyway:
https://www.propublica.org/article/microsoft-cloud-fedramp-c...
Doesn’t feel like the type of mistake Satya would make.
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?
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?
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.
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.
...
Does anyone know if there's anyone else who has reproduced these findings for themselves yet?
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 monitor 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.
bwrap by itself will probably be sufficient against most adversaries as assuming proper config it would require committing to using a linux kernel 0day to escalate privs.
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.
Big difference vs xAI, where the sentiment is valid.
we definitely have that level of mental deficiency in this country..
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…
Technically they can still do potentially any- and everything undetected there; and for what it’s worth, even with a closed-source client bad behavior would get detected eventually through network inspection.
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.
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.
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.
If I had no morals and was running one of these companies I would be stealmaxxing before anyone notices the scale of the grift and regulations start getting in the way.
I'm not saying they are doing this, but that's what the incentives are lined up for.
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.
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.
This is why I keep a separate repo for important parts that I do not want competitors to get access to, and only use ai on dumb parts which I don't care if get leaked tomorrow.
A) leaking structured fully working complete set of files (full working recipe) that is not relevant to AI queries at all.
B) adhoc random queries, bits and pieces, grep of chunks of random files and local bash post-processing for AI queries at hand. which is hard to use for anyting anyways, and will end up in just corups of trainig data (CommonCrawl quality — meaning, not good). (not full recipe).
Running any query in Claude or Codex could result in the AI reading/uploading any file in your codebase.
they send home entirety of codebase that they do not even use for user AI queries.
and why use cloud AI for coding? how is this even a question in 2026? if you don't, you can't compete with somone who does use it.
But AI is literally all about stealing and reselling content under the protection of "AI did it" and "whoopie, we'll take a slap on the wrist". It's reasonable to assume all of the frontier companies are doing this to the maximum extent they can get away with.
they are litearlly ingesting and integrating your app/business into theirs.
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.
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'm afraid you have been scammed.
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.
It's not a great state of affairs, but that's where we are.
Choose wisely my friend.
https://electrek.co/2026/07/10/musk-tells-tesla-staff-switch...
This is another reason to use open source harnesses and open weight local models.
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?
elon musk: hello human resources
Have you verified this flag is respected?
If you want easily verifiable evidence, run strings on the Grok Build CLI binary and you will see: