"It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads"
Holy cow!!!! I mean I kinda expected Elon would do something like this to try to catch-up.. but this is extremely concerning.
This is precisely the reason, even though their pricing is competitive and grok-4.5 is actually good enough, I chose not to go with them.
Frannky 24 minutes ago [-]
I was hesitant to try the free trial exactly because I haven't found any info about what data was required to share...
faangguyindia 3 hours ago [-]
Does OpenAI also have access to all github repos via partnership with microsoft?
taywrobel 2 hours ago [-]
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.
anonymousiam 1 hours ago [-]
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...
taywrobel 1 hours ago [-]
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!
agustechbro 38 minutes ago [-]
Can you prove what you are saying, you have to, if not, you are talking to us like we are idiots.
taywrobel 20 minutes ago [-]
Prove which part?
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.
jpollock 3 hours ago [-]
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.
processunknown 2 hours ago [-]
It wouldnt be _that_ surprising since they committed widespread copyright violations building the models, plus the recent Apple IP theft...
creato 27 minutes ago [-]
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.
Maybe that shouldn't be the case, but it is.
t_gamer_kle 3 hours ago [-]
They were caught stealing Apple trade secrets, dude. Nothing is beneath them.
tyre 3 hours ago [-]
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.
theplumber 1 hours ago [-]
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.
gorgonian 3 hours ago [-]
I could see there being different rules for enterprise accounts.
culi 3 hours ago [-]
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
2 hours ago [-]
ashishb 3 hours ago [-]
There is a reason I run all such CLIs inside a sandbox [1] giving limited directory access.
Imagine if the CLI pulled your SSH keys or other sensitive information by mistake?
Programmers do make such mistakes all the time.
I don't want to count on whether "uploading all files it can access" is intentional or a mistake.
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?
exitb 2 hours ago [-]
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.
ashishb 1 hours ago [-]
And I run most of them inside sandbox now.
Why would you let a markdown linter access your ssh keys?
beepbooptheory 2 hours ago [-]
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?
ashishb 3 minutes ago [-]
> But in this particular case isn't the problem that it's sending everything in the sandbox?
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?
oseityphelysiol 15 minutes ago [-]
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.
culi 3 hours ago [-]
> It transmits the contents of files it reads — including a .env secrets file — to xAI, verbatim and unredacted.
This has to be the most successful mass surveillance campaign of all time
hansvm 1 hours ago [-]
Downloading the SSN/tax/etc data from the entire US wasn't bad either.
phaseleza 3 hours ago [-]
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.
teravor 2 hours ago [-]
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.
timr 2 hours ago [-]
What's your mechanism for doing this?
goos 43 minutes ago [-]
> 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.
looksjjhg 3 hours ago [-]
Do people really trust that guy or any service he owns?! Actually never mind I forgot there’s always fools in this world
jimmydoe 3 hours ago [-]
there are 2.7 m starlink subscribers in US, I don't think they are fools.
Catloafdev 2 hours ago [-]
Those are people without a better option.
Big difference vs xAI, where the sentiment is valid.
looksjjhg 2 hours ago [-]
Sure bud … carry on
ahofmann 35 minutes ago [-]
There is a German proverb, that goes roughly like this: "eating shit is good for you, billions of flys can't be wrong!"
gitgud 3 hours ago [-]
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…
gruez 3 hours ago [-]
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.
rohansood15 3 hours ago [-]
I agree with you, but Codex is open source.
msdz 27 minutes ago [-]
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.
maxloh 2 hours ago [-]
Yeah. Not the Desktop App though.
zuzululu 1 hours ago [-]
its an electron app you an inspect it
hansvm 1 hours ago [-]
> the next update
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.
_davide_ 1 hours ago [-]
I'm using my own agent, but i can't risk blocking the company account with it.....
jimmydoe 3 hours ago [-]
last time I checked, codex is still open source w Apache-2.0 license
Karmakosmik 30 minutes ago [-]
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?
dannyw 7 minutes ago [-]
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.
outloudvi 37 minutes ago [-]
May I put some contents against GCP's AUP in my repo, wait for Grok Build to upload them, and report the bucket to Google?
j_bum 3 hours ago [-]
I wish a human would’ve written the overview.
Nonetheless, this is disturbing.
eternauta3k 5 minutes ago [-]
Or even just that a human had iterated a bit more with the LLM to improve the style.
gruez 3 hours ago [-]
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.
5701652400 3 hours ago [-]
will this endup in their "macrohard" (automate any business) project?
will this endup in their "everything app"?
guess you do not need to build "everything" yourself, when you can steal it.
avaer 3 hours ago [-]
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.
5701652400 3 hours ago [-]
exactly. looks like this is what they doing
websap 51 minutes ago [-]
How do these findings compare to Codex, Claude code, and cursor
charcircuit 47 minutes ago [-]
Cursor is the closest as it uploads your entire source code to build a search index.
EdwardDiego 20 minutes ago [-]
Oh and they just shipped Grok in Cursor. Yay.
Geee 2 hours ago [-]
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.
timr 2 hours ago [-]
> 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.
edg5000 2 hours ago [-]
Even if it's uploaded once, it's still being ran through inference. It saves a bit of HTTP traffic I suppose.
2 hours ago [-]
jeffnash 12 minutes ago [-]
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.
dimgl 3 hours ago [-]
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.
rvz 3 hours ago [-]
But you also have handed over your secrets, dotfiles and API keys alongside with your source code to xAI.
I'm afraid you have been scammed.
dimgl 3 hours ago [-]
A bit hyperbolic, no? A majority of code is now written through Claude and similar services.
Catloafdev 2 hours ago [-]
How is it hyperbolic when it's literally the subject of the post? Did you not read the OP?
dimgl 2 hours ago [-]
The "scam" part is the hyperbolic part
hansvm 1 hours ago [-]
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.
jstanley 3 hours ago [-]
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.
5701652400 3 hours ago [-]
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.
Gagarin1917 3 hours ago [-]
If you’re worried about this why are you using a third party AI in the first place?
Running any query in Claude or Codex could result in the AI reading/uploading any file in your codebase.
5701652400 3 hours ago [-]
key point: Grok is not even using the files they upload.
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.
3 hours ago [-]
faangguyindia 3 hours ago [-]
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.
5701652400 3 hours ago [-]
there is difference between:
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).
jstanley 3 hours ago [-]
Possibly, but people were worried about this with cloud hosting when it first came out, and it turned out to be a total nonissue.
avaer 3 hours ago [-]
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.
5701652400 3 hours ago [-]
they are literally going after "creating everything app" and "everything business" (macrohard).
they are litearlly ingesting and integrating your app/business into theirs.
SR2Z 3 hours ago [-]
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.
drnick1 2 hours ago [-]
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.
dd8601fn 2 hours ago [-]
Claude reads secrets all the time. It just also tells me when secrets enter context and reminds me that they should be rotated later.
fareesh 4 minutes ago [-]
sam altman: aww you're sweet
elon musk: hello human resources
jacobgold 3 hours ago [-]
With all the coding agent options, you're choosing to trust your computer, code, and business to whichever harness, model, and provider you pick.
It's not a great state of affairs, but that's where we are.
Choose wisely my friend.
treexs 2 hours ago [-]
To be fair, most coding agent cli's by the labs do this and are opt in by default, it's just this does too
edg5000 2 hours ago [-]
None of them upload the whole repo, which is what this link claims it does. That's unheard of.
5701652400 3 hours ago [-]
haha so they just stealing entire codebases?
luciana1u 2 hours ago [-]
the Grok Build CLI phoning home with your code is just xAI's way of making sure someone, somewhere, is actually reading your pull requests
thejazzman 2 hours ago [-]
So xAI now has a "legal" copy of all of Tesla's code? Convenient.
This is another reason to use open source harnesses and open weight local models.
rescbr 3 hours ago [-]
Now, where are the people afraid of the Chinese AI companies, who claim they are going to copy their very precious code...?
5701652400 3 hours ago [-]
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.
tredre3 3 hours ago [-]
> none of them upload entirety of codebase or even attempt to.
How do you know? Did you do an analysis like OP did?
5701652400 1 hours ago [-]
no analysis. only based what I see in VSCode tool calls.
rescbr 3 hours ago [-]
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.
5701652400 1 hours ago [-]
same here. API access + low price is why I am using Chinese models
sroerick 3 hours ago [-]
The second I opened Deepseek, it had my harness scan my entire home dir. Not sure what's worse here.
rescbr 3 hours ago [-]
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.
higginsniggins 3 hours ago [-]
Friendly reminder: since Musk now owns Cursor, there are a bunch of really good open-source alternatives you can use.
JumpCrisscross 2 hours ago [-]
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.
supriyo-biswas 60 minutes ago [-]
Mostly like enforcement is slow and I’m not even sure if someone has sent in a complaint.
3 hours ago [-]
charcircuit 3 hours ago [-]
The simplest way to disable uploading your repo is disabling it in the config.
[harness]
disable_codebase_upload=true
JumpCrisscross 2 hours ago [-]
> simplest way to disable uploading your repo is disabling it in the config
Have you verified this flag is respected?
charcircuit 1 hours ago [-]
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.
culi 3 hours ago [-]
This is completely made up. The Grok Build CLI reference lists no such thing. Whatever LLM you asked probably hallucinated this.
charcircuit 3 hours ago [-]
>completely made up
If you want easily verifiable evidence, run strings on the Grok Build CLI binary and you will see:
Codebase upload skipped: disabled by config (harness.disable_codebase_upload=true)
hippich 1 hours ago [-]
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.
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.
Maybe that shouldn't be the case, but it is.
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?
This has to be the most successful mass surveillance campaign of all time
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.
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.
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…
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.
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.
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.
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.
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).
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.
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.
elon musk: hello human resources
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?
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: