FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
79% Positive
Analyzed from 2201 words in the discussion.
Trending Topics
#code#access#grok#read#secrets#files#agent#through#codebase#github
Discussion (69 Comments)Read Original on HackerNews
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.
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
1. Can only read the working project directory, with .git read-only and sensitive directories hidden (mounted as empty directories).
2. Have an isolated network namespace; they can only access the internet through an HTTP proxy hosted on a Unix socket, can only access specific LLM provider hostnames, and exclude the tool's own hostname.
For example, with Crush, I will let it access *.openrouter.ai (LLM providers) but not *.charm.land (Crush's domain for auto-updating the LLM list).
This makes me feel much more comfortable enabling "yolo" mode and letting the tools do everything.
for bonus points you can uplift the bwrap container into an actual sandbox by invoking gvisor (`runsc ... do ...`) from inside it, or a virtual machine like muvm. I'm really fond of this pattern because you can trust bwrap to set up the environment, then you just need a sandbox tool to lock it down. note that bwrap by itself isn't really a sandbox, whatever is running inside it has a lot of kernel surface to attack (which can be somewhat mitigated by compiling strict seccomp filters and passing them to bwrap).
bwrap by itself will probably be sufficient against most adversaries as 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
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…
Big difference vs xAI, where the sentiment is valid.
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.
Nonetheless, this is disturbing.
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.
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.
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.
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.
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: