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...
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!
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.
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.
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.
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?
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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?
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.
This has to be the most successful mass surveillance campaign of all time
Big difference vs xAI, where the sentiment is valid.
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.
Nonetheless, this is disturbing.
``` Config after fix (~/.grok/config.toml)
[harness] disable_codebase_upload = true
[telemetry] trace_upload = false
[features] telemetry = false ```
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.
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 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.
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.
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...
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?
This is another reason to use open source harnesses and open weight local models.
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: