A lot of people are now upset because xai is running a bulk upload instead of a stream upload like oai or Anthropic.
Suddenly they became aware that the AI agents are not actually running on their computers. AI agents are just uploading the shit on some servers for how long they want and in exchange of that you pay them and get some work done.
I am surprised through that nobody is asking if the agents are GDRP compliant or if they are even legal considering they are trained with illegal/copyrighted content or if you are liable for theft because now you own, publish and sell illegal content generated by agents….
Enough ranting…instead of this stuff people should just admit that after social media, AI is the new frontier towards a kind of zero privacy, at least until you can have local AI/if ever.
There’s a hell of a difference between a tool that asks my permission to read a file to make it part of a prompt and a tool that packages up my whole working directory and sends it to Google Cloud Storage.
Who told you that it needs your permission? You are in Disneyland and you are debating why Mickey Mouse is not handing you over a legal agreement with guarantees on the ingredients of the candy you’ve just got from him.
Of course there is. It’s not about the _amount_ of files or how many percent of them. I might have 1000 files that I’m fine having the LLM read and then some that it really shouldn’t. The problem here is plainly uploading your whole directory without prompting for permissions to read them - even if you explicitly set up permissions for read tools.
> even if you explicitly set up permissions for read tools.
Part of problem is that "permissions" here are managed by the tools themselves as if filesystem access control hasn't been invented yet.
Even a half-assed sandbox container would be better than that.
Well, excepting that there's a toggle to turn off 'improving the model' (i.e. don't use my repo for training data) and it still uploads your entire repository, git history, etc., all of which can be fetched locally and fed to the model rather than uploading it to a bulk storage bucket.
Add to that the fact that this also includes env files, which may contain secrets that aren't part of the repo, that don't need to be fed to the model, and that might now be leaked.
Which leads us to the third thing: if this bucket weren't discovered and Grok didn't turn this 'feature' off, imagine the disaster fallout if someone ever managed to get read access to this bucket.
My point is that I believe those toggles are placebo buttons. You are free to believe that they prevent Grok from slurping up your IP, but the most reliable way to prevent that from happening is to prevent Grok from seeing your IP in the first place.
And by the time you figure out that they have, taking them to court is not going to be reliable recourse.
It's funny to remember that the legal definition of something is almost never aligned with how the technology actually works.
Like for instance the legal definition for "encryption at rest" is often wildly different than what a customer thinks that means, what an average SRE think it means, and what a cryptologist thinks it means.
All those regulations like GDPR mean nothing if I can convince a random judge or regulator that an apple is actually an orange.
These technologies are moving so fast that it makes sense why there a lag in understanding and any real attempts at regulating agaists the negative effects.
I don't think there needs to be a lot of understanding that downloading copyrighted content and selling it is illegal under the current law.
The only unclear thing is if the law should be changed or trillion dollar corporations should be liquidated and their executives put in jail(a’la Kim Dotcom). I think we already know the answer.
```
export GROK_TELEMETRY_TRACE_UPLOAD=0
export GROK_TELEMETRY_ENABLED=0
# or config file with [telemetry] trace_upload = false, [harness] disable_codebase_upload = true
```
The practical takeaway for users: your entire codebase leaves (uploaded) your machine unencrypted on each Grok Build invocation, not just files you ask it to read, and no visible setting stops it.
I've added the mitigation above to the image build for Grok Build instances. There is a lot of telemetry already turned on in n8 containers, so will investigate further.
There's many reasons to not use Musk's products, but if you wish to convince people who don't already buy into that description (or worse, who like that description), I would instead focus on the "this endangers your secrets" angle. Business secrets if you're a business, government secrets if you're a government, military secrets if you're military.
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.
+1 for bubblewrap, unsharing everything and then adding back everything your agent needs saves the trouble of updating a docker image and allows you to give selective access to local tooling. I actually go as far as to run nearly every. single. application. in bwrap that doesn't come with native sandboxing. I share credential authentication via sockets, had to build custom schemas for k8s and docker since they still don't have a way to do remote attestation...
I use bubblewrap to unshare all namespaces (net, pid, ipc, user) and ro-bind necessary system paths like /etc, /lib, create a tmpfs home, mount the project folder under it (writable), then mount tmpfs over sensitive directories inside the project to hide them.
For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to localhost with socat. With the net namespace unshared, the app can't reach the network at all except through this proxy, which only allows LLM providers.
By separating the coding tool from the LLM provider, I feel safer: the coding tool cannot leak anything on its own. It can only talk to the LLM provider, so a real leak would require the provider to be complicit too. And any sensitive files, inside or outside the project, are hidden by the mount namespace, which I suppose is hard to escape.
> I mount the Unix socket into the sandbox and bridge it to localhost with socat
I was experimenting with network sandboxing and found a solution that doesn't require an agent inside a sandbox. You can create listening socket on localhost inside the sandbox, send it over the Unix socket to the supervisor outside and close the Unix socket. The supervisor outside now has a listening socket that accepts connections from inside. No socat needed.
My setup was more complicated though, I wanted transparent proxying (intercepting every TCP/UDP connection without having to specify a proxy) and I spent 2 nights fighting with lack of documentation on netfilter. For TCP I ended up with creating a listening socket with IP_TRANSPARENT options and tproxy'ing all traffic into it using nftables. It was easy part. The difficult part was to figure out how to intercept UDP datagrams and send replies with correct sender address. I ended up creating IP_TRANSPARENT listening UDP socket to receive datagrams, and raw IP socket to send replies with forged source address (because single UDP socket doesn't allow sending datagrams from arbitrary port number).
ChatGPT was pretty much useless, probably due to lack of documentation and I had to experiment myself.
I still do not have the supervisor done though, that would decide whether to allow or block a connection. I have the following idea: whenever the target makes a DNS request, I reply with a new IP address like 10.x.x.x. So I can have a map which maps every IP address to a domain, and when a program connects to an IP, I can figure out which domain it is and decide whether allow or block it. This is necessary because there might be multiple IPs for a domain, they can change in time, so it is better to have a persistent mapping, to protect from DNS rebinding attacks.
This achieves much the same thing but using docker, not bubblewrap. `byre develop` drops you into your agent in a sandbox with the current folder mounted. Enabling the firewall or mounting other folders is a few seconds in `byre config` (although you can also switch the firewall on by default). https://github.com/pjlsergeant/byre
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.
> however, the tradeoff is that it will never perform as well as it does in their native agent runners
There's no reason to assume that. The recent Databricks benchmark in fact showed the exact opposite - that using Pi vs native agent both outperformed native agents in terms of task success, and did so cheaper due to using less tokens.
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.
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.
Doesn't matter if it was maliciously stealing literally all contents and secret keys, or if this was merely something vibe-coded that accidentally slipped past QA, the behaviour documented here would get a human developer not only fired but also prosecuted (stealing all the keys and all the code?!), unlikely to get further work, and if not naturalised or a citizen of the country they were in then deported; while the parent company employing a person who acted like Grok is reported to be acting here is likely facing privacy regulator investigations, consent orders, fines, etc.
Sure shouldn't use any software that behaves like this for, e.g. classified work at the Pentagon. If the Pentagon is using this for internal secret planning, like they're boasting they are, this is waaaaay into the "potential catastrophe" (for the US) territory:
Snowden was selective about what he leaked, and still had security people calling for him to get the death penalty.
(meme format aside, this is one for "when people tell you who they are, believe them", along with a demonstration of why "only hurting the right people" is a very dangerous value)
I'm not arguing for what they are doing, but if you use a coding agent to do work on a project, eventually it will have most of the code anyway. Granted, this is very conveniently placed for pickup and ingestion.
It almost certainly already is, at least in some jurisdictions for some forms of data. GDPR, HIPAA, CCPA, biometric privacy, et cetera almost certainly will find claws into this behaviour.
Re: HIPAA, it would be the covered entity or business associate that is allowing xAI access to PHI who would be in violation, not xAI; same as Google isn’t responsible if someone sends PHI over Gmail and Google scans it.
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!
(FWIW, in my conspiracy theory, the data sharing would be buried in the part of the company responsible for making sure that people don't upload e.g. CSAM to private repositories, so the Copilot people wouldn't be directly aware of it. I might've edited that in after you already started writing your reply though.)
Still in my bubble! I am not involved in the human review or automated analysis portions of the safety pipeline for CSAM/TVEC harms, but my team is responsible for the data handling around identifying and responding to such content.
As of 11 days ago our vision support is GA (https://github.blog/changelog/2026-07-01-copilot-vision-is-g...) and let’s just say the technical implementation wasn’t the long pull there. Figuring out the what and how of responsible data handling around what I hope is agreeably harmful use was… quite a journey.
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!
Even with your rephrasing you’re looking for an answer in absolutes which is generally impossible, but unpacking your line of questioning, what it really amounts to is how “in the know” I am or am not.
To the best of my knowledge I know about every ongoing company AI safety and user privacy initiative, and none of them involve permitting access to copilot user content to any second party or third party entity.
Of course, that’s tautological. I don’t know what I don’t know, but I’m senior enough and with broad enough scope that I’m at least read in on what I believe is the majority of high level business initiatives.
I’m not trying to be evasive, this is just the reality of any organization - I only know what I know. Everything within my scope of awareness indicates that there is no copilot user content access outside of our publicly published terms of service.
Thanks for responding. It's great to hear from someone working these issues day to day, and it's the reason I come to HN. I feel like this particular line of questioning is a bit silly, with all the "Can you absolutely guarantee X, Y, and Z?" Thanks for engaging despite the adversarial turn it has taken!
I think there's maybe a disconnect here that people are largely concerned with the contents of their private repos, while you're maybe more familiar with how AI interaction data is handled. (After all, the original topic of the thread was X.ai allegedly going above and beyond interaction data to exfiltrate entire repos.)
I personally did get the vibe that you were being evasive, just because the things you were saying didn't quite match what people were asking about, in a way that felt kind of like a corporate legally-not-a-denial denial. It's like, "Hey, has Contoso Apartments hidden a camera in my bathroom?" "Contoso Apartments is committed to your privacy and safety. We have strict controls in place to ensure that our maintenance staff cannot make a copy of your key without notifying you. To the best of my knowledge, we do not have any company initiative that involves opening envelopes addressed to you." Like it's theoretically reassuring for the company to commit to those things, but the fact that they can't directly answer the original question is disconcerting.
Ultimately there's probably not a whole lot you can do about this. Like realistically if Microsoft is doing this, they've probably constructed it in a way where not many people know and/or they can plausibly deny it. So it comes down to (a) Microsoft denies doing it, but isn't making the broadest legally binding commitment possible, (b) does the reader believe Microsoft and OpenAI are trustworthy with respect to privacy and intellectual property issues or not.
I've been in this kind of situation before, and it can be frustrating when people don't believe that you're in a good, isolated department of the company and you're committed to upholding ethical standards. I guess that's why big companies pay the big bucks :)
That’s fair, and I appreciate the more constructively critical feedback! Also worth noting that I’m solidly on the platform service side, and the article here is largely focused on malicious client behavior.
Copilot has a lot of different clients between IDEs, agentic integrations, and GitHub apps. I don’t have awareness of the implementation details of all of them, but I can assure you that we don’t provide APIs like those mentioned in the article being used for data exfiltration.
Clients are responsible for context building, and all go through the same service that does auth, policy and quota enforcement, request routing to the underlying providers all of which have zero data retention enabled unless very specifically excluded from that (looking at you, Fable 5).
> If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?
If anyone answered that question affirmatively, I'd lose a massive amount of trust in them. It would betray they fundamentally misunderstand the stochastic nature of playing defense.
I do not believe in being non-antagonistic in pursuit of truth. They could have admitted they never had any control over what's uploaded. Instead even when "antagonistically asked a question" they chose to not answer it. This is an answer in itself and to our great sadness extracting that required some amount of "antagonism".
> Very few employees within GitHub proper even have access to view private repositories
so we're just discussing what business Microsoft likes more at any moment. and you didn't provide a list of allowed use cases (is Ai training one?). making your huge answer(s) empty and not contributing one yota. sorry.
i feel your job exist to uphold the illusion and you will not see it any other way.
Prove that I work at GitHub? Username + LinkedIn can show (not prove) that easily.
Prove that we have an entitlements system which regulates and audits access? I could point you to https://github.com/entitlements, but it’s all private repositories so that won’t prove much either.
Prove that there are no OpenAI employees with access to GitHub systems? Not sure how I’d do that without dumping (what you would still need to trust me is) the entirety of our org chart/HR system, which I’m not willing to do because I do enjoy being employed and am not exactly obfuscating my identity here.
Prove that HN has a strong anti-Microsoft bias? Well that one is pretty easy actually, you’re helping prove it yourself!
Let’s be real, we now live in a post-truth world. Nothing can truly be proven or disproven outside of formal logic and mathematics. You can either believe what I’m saying as good faith insider knowledge sharing (which is unfortunately rare nowadays) or you can not. Makes no difference to me.
That is my point! The fact that there are a lot of people that will believe what you are stating without a reasonably proof is what makes me sad and worry about the future. That kind of statements you are doing are enough to put in company webpage and term of service and thats it. Any attempt to repeat them as if they are true makes:
1) The messenger looks good in the eyes of stupid and innocent people.
2) The messenger looks stupid in the eyes of people that have reasonable doubts about company statements that are agains their own interest.
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?
Note that everything GPT knows (I.e news etc) is actually from real news websites that never gave GPT rights to use their content. In the pure “American way” OpenAI closed some deals when threatened with lawsuits but of course unless you have the political connections or financials to fight trillion dollars companies stop worrying about your private repo. If it’s in the “cloud” it’s already public just not for everybody.
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?
The readme is confusing. You say it has bubblewrap, but you also have an FAQ saying why not to use bubblewrap? Another FAQ says why not to use sandbox-exec for mac, yet the link for mac goes to sandbox-exec?
It would be extremely naive to assume Elon, or even a real human had a hand in this. The whole analytics pipeline is very likely vibecoded and never reviewed by a human.
These things are all built on the back of stolen content, and they guy running X is a notoriously corrupt billionaire who recently ran an illegal effort to strip food and medical aid from third world countries which has already resulted in hundreds of thousands of deaths.
I don’t understand why anyone would be surprised that they’re also stealing code from their users. Pay attention to what people like Musk do to those under their power. He will do the same to you in a heartbeat.
You should try getting your news from somewhere other than X and Fox.
You know, I actually suspect musk is much worse that what has been reported, especially given his involvement with Epstein and those other creeps, but I moderated my post to only confirmed and broadly reported facts.
He forgot right-winger, bad father, lier (yeah sure, pedo guy is South-African slang), video game cheater, helped dismantling USAID which costs the lives of many people and the worst of all: he promoted an Uwe Boll movie
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.
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.
AFAIK, Cursor does some kind of indexing locally. So they don't have to upload all files, but can still search through them in order to find the relevant _parts_ that they upload so that the model can use them.
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.
Grok Build has had impressive performance in a couple of my projects. And fast. So this revelation has been very disappointing...
I will say, a majority of the code I'm writing now is fully through an online LLM. If a company wanted to reconstruct a project I'm working on, they could just replay all of the tool calls from their logs, if they decide to retain the data (I did this locally once to recover a project that I mistakenly clobbered in Git).
Still, this is a big overstep IMO. At the very least, they should make it clear in their terms of service and privacy policy, and not hidden through legalese. Not all usage of Grok Build will be through their enterprise plan which offers ZDR.
I don’t know why anyone would use Grok Build when they could use Cursor, with access to both Grok-4.5 and Composer-2.5-Fast and astonishingly cheap prices, and easy access to Opus if you need it.
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.
> 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.
If this doesn’t bother you (depending on the codebase it might not) you should know Deepseek flash is free on opencode, probably because they’re doing something similar.
If it does, I’m not sure what to recommend. Even Anthropic and OpenAI might be training on your code anyways. See: Alex Karp.
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.
If a harness wants to upload the whole codebase in one batch, it should explicitly inform the user about it. Instead of exfiltrating the data without consent.
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.
This is exactly why tools like Landstrip[1] exist. Sandboxing is a good mitigation to an extent, but it cannot address every class of attack. If an agent allows untrusted content to influence privileged decisions, the underlying design still has a large attack surface. Claude Code is also susceptible to this class of issue because of how its plugin interface works.
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?
The first item is "a file in the repository which contains secrets was read by the model".
Well yeah, obviously, that's pretty much intended behaviour. The LLM can't determine that there are secrets in your file before reading them.
The real issue here is that you're giving an LLM access to a file with plain-text secrets and then surprised that it reads that file.
The fact that the whole repo is automatically uploaded is crazy though, especially for multi-gigabyte repositories. This could take a long time on some connections, and seems generally pointless — unless there's some ulterior motive for uploading all this data.
The things you allow the LLM to read will obviously be sent as part of a prompt. You can control that though. Reads are tool calls and you can configure permissions for that or be asked every time the agent wants to read something.
This is straight up just uploading your whole working directory. Not as a LLM prompt, but to a Google Storage.
More or less, but most harnesses will rely on tools such as grep to only read portions of files. For even a small sized repo, only a small portion would be tokenized and uploaded
>For even a small sized repo, only a small portion would be tokenized and uploaded
Only on a per-chat basis. Over time, it'll eventually grab the entire repo, or enough of the "secret sauce" that the rest can be reconstructed with AI.
since github. or you truly believed your code was private in private repos? I never understood that belief of a label on a button.
since jira-cloud, or you truly believed your processes were private?
leaks are assured, but centralisation amplifies impact. no one cares if your self-hosted something gets owned _because_ it does not affect anyone else.
At this stage passwords are irrelevant. You already moved your data out. This is all there is to it: either you control access, or you don't and then all bets are off.
It is common knowledge that any ai tool will upload whatever it has access to.
So why the drama? It did what it was designed to do and what you consented to by using it.
If you don't want your foot sawn off learn maybe something about tool safety.
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.
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.
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.
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 wonder how many of you guys actually read this kind of reports (or even skim through)? At the first glance it looks to me like someone just asked an agent for a security review of this CLI and then pasted results to the gist.
When I see a report like that I just assume it's a low-effort AI slop and stop reading immediately. Why would I read it since I can do the same with my agent and with that understand it better? Or if I'm really lazy then just copy paste this report and ask for a summary or have a discussion.
Please tell me then how ridiculous my post is. I wanna hear that - that's why I posted this. Your comment did literally nothing useful except bumping your own ego.
> You literally did not take 5 minutes to even start
Yes you're exactly right - you can guess that from reading my post. But you're hitting the wrong topic there. Seems like you didn't understand what I asked.
But let me elaborate on that. Why would I take >5 minutes to start reading each report I see on the web? Like all humans I have limited capacity of information I can effectively gather so I'm not gonna start reading each article 24/7.
Topic was interesting, got many upvotes, so I opened the report. I saw there a bunch of LLM-generated paragraphs, got mixed feelings and just closed it.
I mean just see the beginning
"A measured, reproducible teardown. Findings are backed by captured artifacts (endpoint, HTTP method, status code, byte size, host) and repro commands; where an observation was seen live but not retained as a file, §7 says so explicitly.". When I see something like that I immediately lose motivation to read that.
This is yet another reason to use open weight models and open source harnesses so that this can never happen.
Why do you continue to give these companies all your secrets, env vars, source code and data? That is effectively a data breach by this form of malware.
If you had data that was never meant to be uploaded or shared by a third party, consider that a security incident.
It turns out that utility overrides all security concerns. It's the same reason that Cloudflare gets to snoop on 90% of web traffic. If you wanted a honeypot you couldn't ask for a better one.
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.
It’s funny how you’re always policing me and not the thousands of other people that are posting much worse things.
I’d be happy if there was a version where I can just see links, comments and add posts to favourites. That’s all I need really.
It always feels like the mods are against you, and it always feels like others are doing worse. These are fixtures of internet forum psychology and you are far from the only one who feels that way.
If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. You can help by flagging it or emailing us at hn@ycombinator.com.
Still, other people breaking the site guidelines doesn't make it ok for you to also break them, and pointing the finger at others, as if you needn't correct your own behavior, is unhelpful.
If you've gotten multiple moderation responses, the likeliest reason is that you've broken the site guidelines multiple times. Btw, it's nothing personal—we don't know anything about you—and the answer to your "it's funny" is that it's simply random.
I'm sure it's true that other people have done the same or worse and not gotten the same replies, because that's how randomness works. We do our best within the quantity limits of what we're physically able to read and respond to.
A criminal is doing criminal things. Please, let’s not act surprised. The person who runs this company is the very worst kind of human being, literally shutting down agencies to stop investigations into his business practices. I would actually be surprised if he wasn’t doing shady things to try to catch his garbage product up with the competition.
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:
I tried to use Grok once, but it required a Twitter Blue subscription, which required a 30-day-old Twitter account and for some reason they kept flagging my account for fraud sooner than that. Are they still doing these requirements?
A lot of people are now upset because xai is running a bulk upload instead of a stream upload like oai or Anthropic.
Suddenly they became aware that the AI agents are not actually running on their computers. AI agents are just uploading the shit on some servers for how long they want and in exchange of that you pay them and get some work done.
I am surprised through that nobody is asking if the agents are GDRP compliant or if they are even legal considering they are trained with illegal/copyrighted content or if you are liable for theft because now you own, publish and sell illegal content generated by agents….
Enough ranting…instead of this stuff people should just admit that after social media, AI is the new frontier towards a kind of zero privacy, at least until you can have local AI/if ever.
There’s a hell of a difference between a tool that asks my permission to read a file to make it part of a prompt and a tool that packages up my whole working directory and sends it to Google Cloud Storage.
Who told you that it needs your permission? You are in Disneyland and you are debating why Mickey Mouse is not handing you over a legal agreement with guarantees on the ingredients of the candy you’ve just got from him.
Depending on how many files it requests to read, in practice there might not be a difference at all.
Of course there is. It’s not about the _amount_ of files or how many percent of them. I might have 1000 files that I’m fine having the LLM read and then some that it really shouldn’t. The problem here is plainly uploading your whole directory without prompting for permissions to read them - even if you explicitly set up permissions for read tools.
> even if you explicitly set up permissions for read tools.
Part of problem is that "permissions" here are managed by the tools themselves as if filesystem access control hasn't been invented yet. Even a half-assed sandbox container would be better than that.
Well, excepting that there's a toggle to turn off 'improving the model' (i.e. don't use my repo for training data) and it still uploads your entire repository, git history, etc., all of which can be fetched locally and fed to the model rather than uploading it to a bulk storage bucket.
Add to that the fact that this also includes env files, which may contain secrets that aren't part of the repo, that don't need to be fed to the model, and that might now be leaked.
Which leads us to the third thing: if this bucket weren't discovered and Grok didn't turn this 'feature' off, imagine the disaster fallout if someone ever managed to get read access to this bucket.
My point is that I believe those toggles are placebo buttons. You are free to believe that they prevent Grok from slurping up your IP, but the most reliable way to prevent that from happening is to prevent Grok from seeing your IP in the first place.
And by the time you figure out that they have, taking them to court is not going to be reliable recourse.
The same is true for Claude and Codex.
It's funny to remember that the legal definition of something is almost never aligned with how the technology actually works.
Like for instance the legal definition for "encryption at rest" is often wildly different than what a customer thinks that means, what an average SRE think it means, and what a cryptologist thinks it means.
All those regulations like GDPR mean nothing if I can convince a random judge or regulator that an apple is actually an orange.
These technologies are moving so fast that it makes sense why there a lag in understanding and any real attempts at regulating agaists the negative effects.
I don't think there needs to be a lot of understanding that downloading copyrighted content and selling it is illegal under the current law.
The only unclear thing is if the law should be changed or trillion dollar corporations should be liquidated and their executives put in jail(a’la Kim Dotcom). I think we already know the answer.
Mitigation for use:
The practical takeaway for users: your entire codebase leaves (uploaded) your machine unencrypted on each Grok Build invocation, not just files you ask it to read, and no visible setting stops it.I've built Nemesis8 (n8) for blast radius control and monitoring these sorts of things, from containers: https://github.com/deepbluedynamics/nemesis8
I've added the mitigation above to the image build for Grok Build instances. There is a lot of telemetry already turned on in n8 containers, so will investigate further.
[flagged]
There's many reasons to not use Musk's products, but if you wish to convince people who don't already buy into that description (or worse, who like that description), I would instead focus on the "this endangers your secrets" angle. Business secrets if you're a business, government secrets if you're a government, military secrets if you're military.
Imagine the fallout if someone discovered a method of read access to this bucket.
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.
This is the way.
For CC I have a template here https://kaveh.page/blog/claude-code-sandbox
+1 for bubblewrap, unsharing everything and then adding back everything your agent needs saves the trouble of updating a docker image and allows you to give selective access to local tooling. I actually go as far as to run nearly every. single. application. in bwrap that doesn't come with native sandboxing. I share credential authentication via sockets, had to build custom schemas for k8s and docker since they still don't have a way to do remote attestation...
What's your mechanism for doing this?
I use bubblewrap to unshare all namespaces (net, pid, ipc, user) and ro-bind necessary system paths like /etc, /lib, create a tmpfs home, mount the project folder under it (writable), then mount tmpfs over sensitive directories inside the project to hide them.
For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to localhost with socat. With the net namespace unshared, the app can't reach the network at all except through this proxy, which only allows LLM providers.
By separating the coding tool from the LLM provider, I feel safer: the coding tool cannot leak anything on its own. It can only talk to the LLM provider, so a real leak would require the provider to be complicit too. And any sensitive files, inside or outside the project, are hidden by the mount namespace, which I suppose is hard to escape.
> I mount the Unix socket into the sandbox and bridge it to localhost with socat
I was experimenting with network sandboxing and found a solution that doesn't require an agent inside a sandbox. You can create listening socket on localhost inside the sandbox, send it over the Unix socket to the supervisor outside and close the Unix socket. The supervisor outside now has a listening socket that accepts connections from inside. No socat needed.
My setup was more complicated though, I wanted transparent proxying (intercepting every TCP/UDP connection without having to specify a proxy) and I spent 2 nights fighting with lack of documentation on netfilter. For TCP I ended up with creating a listening socket with IP_TRANSPARENT options and tproxy'ing all traffic into it using nftables. It was easy part. The difficult part was to figure out how to intercept UDP datagrams and send replies with correct sender address. I ended up creating IP_TRANSPARENT listening UDP socket to receive datagrams, and raw IP socket to send replies with forged source address (because single UDP socket doesn't allow sending datagrams from arbitrary port number).
ChatGPT was pretty much useless, probably due to lack of documentation and I had to experiment myself.
I still do not have the supervisor done though, that would decide whether to allow or block a connection. I have the following idea: whenever the target makes a DNS request, I reply with a new IP address like 10.x.x.x. So I can have a map which maps every IP address to a domain, and when a program connects to an IP, I can figure out which domain it is and decide whether allow or block it. This is necessary because there might be multiple IPs for a domain, they can change in time, so it is better to have a persistent mapping, to protect from DNS rebinding attacks.
My colleague implemented your idea of assigning fake IPS to hostnames to allow hostname filtering. It works great.
Think they are referring to this https://github.com/containers/bubblewrap
This achieves much the same thing but using docker, not bubblewrap. `byre develop` drops you into your agent in a sandbox with the current folder mounted. Enabling the firewall or mounting other folders is a few seconds in `byre config` (although you can also switch the firewall on by default). https://github.com/pjlsergeant/byre
This is an option:
https://github.com/GreyhavenHQ/greywall
> This makes me feel much more comfortable enabling "yolo" mode and letting the tools do everything.
But is this only a feelings thing, or did this additional hardening ever actually catch something nasty?
I find that models that do really dumb shit where constraints pay off are models not worth using in general.
Not a knock on the practice, I'm in the process of hardening my own stuff too, just curious.
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.
> however, the tradeoff is that it will never perform as well as it does in their native agent runners
There's no reason to assume that. The recent Databricks benchmark in fact showed the exact opposite - that using Pi vs native agent both outperformed native agents in terms of task success, and did so cheaper due to using less tokens.
> 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.
I agree with you, but Codex is open source.
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.
Yeah. Not the Desktop App though.
its an electron app you an inspect it
I'm using my own agent, but i can't risk blocking the company account with it.....
last time I checked, codex is still open source w Apache-2.0 license
"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.
it's straight up data exfiltration and should be illegal
Suspect it is illegal.
Doesn't matter if it was maliciously stealing literally all contents and secret keys, or if this was merely something vibe-coded that accidentally slipped past QA, the behaviour documented here would get a human developer not only fired but also prosecuted (stealing all the keys and all the code?!), unlikely to get further work, and if not naturalised or a citizen of the country they were in then deported; while the parent company employing a person who acted like Grok is reported to be acting here is likely facing privacy regulator investigations, consent orders, fines, etc.
Sure shouldn't use any software that behaves like this for, e.g. classified work at the Pentagon. If the Pentagon is using this for internal secret planning, like they're boasting they are, this is waaaaay into the "potential catastrophe" (for the US) territory:
Snowden was selective about what he leaked, and still had security people calling for him to get the death penalty.
> chose to use the explicitly evil AI
> look inside
> it does evil things to you too
(meme format aside, this is one for "when people tell you who they are, believe them", along with a demonstration of why "only hurting the right people" is a very dangerous value)
Elon's whole fortune derives from his ability to do illegal stuff without consequence, repeatedly.
[flagged]
"don't believe your lying eyes"
he bought tesla btw
I'm not arguing for what they are doing, but if you use a coding agent to do work on a project, eventually it will have most of the code anyway. Granted, this is very conveniently placed for pickup and ingestion.
> and should be illegal
It almost certainly already is, at least in some jurisdictions for some forms of data. GDPR, HIPAA, CCPA, biometric privacy, et cetera almost certainly will find claws into this behaviour.
Re: HIPAA, it would be the covered entity or business associate that is allowing xAI access to PHI who would be in violation, not xAI; same as Google isn’t responsible if someone sends PHI over Gmail and Google scans it.
Does OpenAI also have access to all github repos via partnership with microsoft?
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!
(FWIW, in my conspiracy theory, the data sharing would be buried in the part of the company responsible for making sure that people don't upload e.g. CSAM to private repositories, so the Copilot people wouldn't be directly aware of it. I might've edited that in after you already started writing your reply though.)
Still in my bubble! I am not involved in the human review or automated analysis portions of the safety pipeline for CSAM/TVEC harms, but my team is responsible for the data handling around identifying and responding to such content.
As of 11 days ago our vision support is GA (https://github.blog/changelog/2026-07-01-copilot-vision-is-g...) and let’s just say the technical implementation wasn’t the long pull there. Figuring out the what and how of responsible data handling around what I hope is agreeably harmful use was… quite a journey.
I appreciate the detailed response. It's a very important topic that is often filled with empty platitudes and not enough detail.
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!
Can you state with absolute сertainity that no entity outside your github unit can exfiltrate data at will?
This is not spicy, this is basic infosec.
Nobody can say that with absolute certainty, so obviously not.
And since you presumably knew that already (as it is basic infosec) then yes it is spicy, or simply antagonistic.
If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?
Even with your rephrasing you’re looking for an answer in absolutes which is generally impossible, but unpacking your line of questioning, what it really amounts to is how “in the know” I am or am not.
To the best of my knowledge I know about every ongoing company AI safety and user privacy initiative, and none of them involve permitting access to copilot user content to any second party or third party entity.
Of course, that’s tautological. I don’t know what I don’t know, but I’m senior enough and with broad enough scope that I’m at least read in on what I believe is the majority of high level business initiatives.
I’m not trying to be evasive, this is just the reality of any organization - I only know what I know. Everything within my scope of awareness indicates that there is no copilot user content access outside of our publicly published terms of service.
Thanks for responding. It's great to hear from someone working these issues day to day, and it's the reason I come to HN. I feel like this particular line of questioning is a bit silly, with all the "Can you absolutely guarantee X, Y, and Z?" Thanks for engaging despite the adversarial turn it has taken!
I think there's maybe a disconnect here that people are largely concerned with the contents of their private repos, while you're maybe more familiar with how AI interaction data is handled. (After all, the original topic of the thread was X.ai allegedly going above and beyond interaction data to exfiltrate entire repos.)
I personally did get the vibe that you were being evasive, just because the things you were saying didn't quite match what people were asking about, in a way that felt kind of like a corporate legally-not-a-denial denial. It's like, "Hey, has Contoso Apartments hidden a camera in my bathroom?" "Contoso Apartments is committed to your privacy and safety. We have strict controls in place to ensure that our maintenance staff cannot make a copy of your key without notifying you. To the best of my knowledge, we do not have any company initiative that involves opening envelopes addressed to you." Like it's theoretically reassuring for the company to commit to those things, but the fact that they can't directly answer the original question is disconcerting.
Ultimately there's probably not a whole lot you can do about this. Like realistically if Microsoft is doing this, they've probably constructed it in a way where not many people know and/or they can plausibly deny it. So it comes down to (a) Microsoft denies doing it, but isn't making the broadest legally binding commitment possible, (b) does the reader believe Microsoft and OpenAI are trustworthy with respect to privacy and intellectual property issues or not.
I've been in this kind of situation before, and it can be frustrating when people don't believe that you're in a good, isolated department of the company and you're committed to upholding ethical standards. I guess that's why big companies pay the big bucks :)
That’s fair, and I appreciate the more constructively critical feedback! Also worth noting that I’m solidly on the platform service side, and the article here is largely focused on malicious client behavior.
Copilot has a lot of different clients between IDEs, agentic integrations, and GitHub apps. I don’t have awareness of the implementation details of all of them, but I can assure you that we don’t provide APIs like those mentioned in the article being used for data exfiltration.
Clients are responsible for context building, and all go through the same service that does auth, policy and quota enforcement, request routing to the underlying providers all of which have zero data retention enabled unless very specifically excluded from that (looking at you, Fable 5).
[flagged]
> If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?
If anyone answered that question affirmatively, I'd lose a massive amount of trust in them. It would betray they fundamentally misunderstand the stochastic nature of playing defense.
It's a pretty antagonistic way of asking a question man. Don't do that
I do not believe in being non-antagonistic in pursuit of truth. They could have admitted they never had any control over what's uploaded. Instead even when "antagonistically asked a question" they chose to not answer it. This is an answer in itself and to our great sadness extracting that required some amount of "antagonism".
> Very few employees within GitHub proper even have access to view private repositories
so we're just discussing what business Microsoft likes more at any moment. and you didn't provide a list of allowed use cases (is Ai training one?). making your huge answer(s) empty and not contributing one yota. sorry.
i feel your job exist to uphold the illusion and you will not see it any other way.
[flagged]
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.
That is my point! The fact that there are a lot of people that will believe what you are stating without a reasonably proof is what makes me sad and worry about the future. That kind of statements you are doing are enough to put in company webpage and term of service and thats it. Any attempt to repeat them as if they are true makes: 1) The messenger looks good in the eyes of stupid and innocent people. 2) The messenger looks stupid in the eyes of people that have reasonable doubts about company statements that are agains their own interest.
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.
It wouldnt be _that_ surprising since they committed widespread copyright violations building the models, plus the recent Apple IP theft...
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.
This speaks to OpenAI's approach to things. But it doesn't speak to Microsoft and Microsoft would need to provide the access.
this might be relevant about microsoft.
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...
They were caught stealing Apple trade secrets, dude. Nothing is beneath them.
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?
Well let’s just say it’s not that hard to see that: https://variety.com/2025/digital/news/studio-ghibli-openai-s...
Note that everything GPT knows (I.e news etc) is actually from real news websites that never gave GPT rights to use their content. In the pure “American way” OpenAI closed some deals when threatened with lawsuits but of course unless you have the political connections or financials to fight trillion dollars companies stop worrying about your private repo. If it’s in the “cloud” it’s already public just not for everybody.
I could see there being different rules for enterprise accounts.
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
I was hesitant to try the free trial exactly because I haven't found any info about what data was required to share...
Race to the bottom.
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.
1 - https://github.com/ashishb/amazing-sandbox
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.
Open source project are unlikely to do this, however.
And I run most of them inside sandbox now.
Why would you let a markdown linter access your ssh keys?
Because I'm confident nothing will happen if it does
> Because I'm confident nothing will happen if it does
Well, best of luck.
1. Amazon has shipped backdoored packages - https://aws.amazon.com/security/security-bulletins/AWS-2025-... 2. Scanners like Trivy have been compromised - https://socket.dev/blog/trivy-under-attack-again-github-acti... 3. Redhat is shipping backdoored FOSS packages - https://access.redhat.com/security/vulnerabilities/RHSB-2026... 4. Even fake and malicious ESLint packages have been published - https://gbhackers.com/eslint-package-attack/
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?
> 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?
Gotta say, if I ever was, I am really not envying the AI guys these days! Sounds terrible!
The readme is confusing. You say it has bubblewrap, but you also have an FAQ saying why not to use bubblewrap? Another FAQ says why not to use sandbox-exec for mac, yet the link for mac goes to sandbox-exec?
It would be extremely naive to assume Elon, or even a real human had a hand in this. The whole analytics pipeline is very likely vibecoded and never reviewed by a human.
The only way is to make sure your AI cannot possibly read what it's not supposed to. For CC, I have a bubblewrap that has been effective:
https://kaveh.page/blog/claude-code-sandbox
These things are all built on the back of stolen content, and they guy running X is a notoriously corrupt billionaire who recently ran an illegal effort to strip food and medical aid from third world countries which has already resulted in hundreds of thousands of deaths.
I don’t understand why anyone would be surprised that they’re also stealing code from their users. Pay attention to what people like Musk do to those under their power. He will do the same to you in a heartbeat.
*trillionaire
[flagged]
You should try getting your news from somewhere other than X and Fox.
You know, I actually suspect musk is much worse that what has been reported, especially given his involvement with Epstein and those other creeps, but I moderated my post to only confirmed and broadly reported facts.
He forgot right-winger, bad father, lier (yeah sure, pedo guy is South-African slang), video game cheater, helped dismantling USAID which costs the lives of many people and the worst of all: he promoted an Uwe Boll movie
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.
It will have to be sent through the context again. That's how LLMs work.
The only reason to do this is so that Musk has clean training data for his next model. Project setup, popular libraries, CI workflows, etc.
> 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.
Even if it's uploaded once, it's still being ran through inference. It saves a bit of HTTP traffic I suppose.
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.
AFAIK, Cursor does some kind of indexing locally. So they don't have to upload all files, but can still search through them in order to find the relevant _parts_ that they upload so that the model can use them.
I wish a human would’ve written the overview.
Nonetheless, this is disturbing.
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.
Or even just that a human had iterated a bit more with the LLM to improve the style.
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.
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.
exactly. looks like this is what they doing
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.
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.
Grok Build has been useless for me personally. Claude is the only one that works best.
I find Deepseek to be a great compromise between cost and performance. Anthropic and OpenAI are simply too expensive at this point.
I don’t know why anyone would use Grok Build when they could use Cursor, with access to both Grok-4.5 and Composer-2.5-Fast and astonishingly cheap prices, and easy access to Opus if you need it.
Deepseek is phenomenal. It needs more baby sitting but it’s just so goddamn cheap.
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.
A bit hyperbolic, no? A majority of code is now written through Claude and similar services.
How is it hyperbolic when it's literally the subject of the post? Did you not read the OP?
The "scam" part is the hyperbolic part
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.
$3b for a splashdown in the ocean instead of a lunar landing of a lunar lander?
> 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.
If this doesn’t bother you (depending on the codebase it might not) you should know Deepseek flash is free on opencode, probably because they’re doing something similar.
If it does, I’m not sure what to recommend. Even Anthropic and OpenAI might be training on your code anyways. See: Alex Karp.
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.
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).
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.
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.
Possibly, but people were worried about this with cloud hosting when it first came out, and it turned out to be a total nonissue.
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.
they are literally going after "creating everything app" and "everything business" (macrohard).
they are litearlly ingesting and integrating your app/business into theirs.
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.
If a harness wants to upload the whole codebase in one batch, it should explicitly inform the user about it. Instead of exfiltrating the data without consent.
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.
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?
This is exactly why tools like Landstrip[1] exist. Sandboxing is a good mitigation to an extent, but it cannot address every class of attack. If an agent allows untrusted content to influence privileged decisions, the underlying design still has a large attack surface. Claude Code is also susceptible to this class of issue because of how its plugin interface works.
[1]: https://github.com/landstrip/landstrip
Also, I'm not particularly fond of using VM/microVM for sandboxing agents. This aligns with my line of thought: https://www.linkedin.com/pulse/why-your-microvm-sandbox-solv...
[flagged]
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 just tried it for myself and couldn’t reproduce it. However, I have no familiarity with Grok Build.
Let me share my annoyance that Grok Build’s installer is yet another “curl | sh”. Please stop doing this!
I assume Cursor will be replacing it soon.
How do these findings compare to Codex, Claude code, and cursor
Cursor is the closest as it uploads your entire source code to build a search index.
SpaceX bought cursor, so one and same now
Oh and they just shipped Grok in Cursor. Yay.
Well, it’s just yet another of 75 or so you can access from Cursor, albeit very cheaply.
The first item is "a file in the repository which contains secrets was read by the model".
Well yeah, obviously, that's pretty much intended behaviour. The LLM can't determine that there are secrets in your file before reading them.
The real issue here is that you're giving an LLM access to a file with plain-text secrets and then surprised that it reads that file.
The fact that the whole repo is automatically uploaded is crazy though, especially for multi-gigabyte repositories. This could take a long time on some connections, and seems generally pointless — unless there's some ulterior motive for uploading all this data.
After this, I reconsider whether I want to use grok 4.5 just over an API at all.
Correct me if I'm wrong but aren't the contents of the repo sent up in the token stream eventually?
The things you allow the LLM to read will obviously be sent as part of a prompt. You can control that though. Reads are tool calls and you can configure permissions for that or be asked every time the agent wants to read something.
This is straight up just uploading your whole working directory. Not as a LLM prompt, but to a Google Storage.
I think in this case the tool was sending the contents of the entire folder it was started in, no matter what files the LLM actually read.
And the .git directory contains much more information than most realize.
The better models generally try to at least make a meandering attempt to not upload secrets (like .env tends to contain)
More or less, but most harnesses will rely on tools such as grep to only read portions of files. For even a small sized repo, only a small portion would be tokenized and uploaded
>For even a small sized repo, only a small portion would be tokenized and uploaded
Only on a per-chat basis. Over time, it'll eventually grab the entire repo, or enough of the "secret sauce" that the rest can be reconstructed with AI.
5.1GB?
haha so they just stealing entire codebases?
Elon doing Elon things.
I imagine the terms and conditions state:
-All disputes to be dealt with by arbitration
-You agree to not have a trial by Jury
If you go with an Elon company, you kinda have to expect ruthlessness
> 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
Downloading the SSN/tax/etc data from the entire US wasn't bad either.
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.
...
Neither of those examples have access to, what are basically, passwords you use for other services
At this stage passwords are irrelevant. You already moved your data out. This is all there is to it: either you control access, or you don't and then all bets are off.
It is common knowledge that any ai tool will upload whatever it has access to.
So why the drama? It did what it was designed to do and what you consented to by using it.
If you don't want your foot sawn off learn maybe something about tool safety.
In particularly even a harness designed not to access your secrets may still do so accidentally or be prompt-injected into doing so.
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.
Claude reads secrets all the time. It just also tells me when secrets enter context and reminds me that they should be rotated later.
Same here. It’s possible to greek secrets, but hardly anyone ever does.
Apple Intelligence does along with any PII, which makes it harder to code for.
Both Grok and Claude Code are malware.
This is another reason to use open source harnesses and open weight local models.
Describing Claude Code as malware is kind of ridiculous. It isn’t. Neither is Grok.
[dead]
And Codex?
How is this not on the frontpage, this should be editorially pinned given the number of programmers here
You know why :-)
this is sad. seriously pg?
Considering the network traffic consumption itself already very bad for Chinese users (they use VPNs)
Why use this CLI over something like OpenCode?
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.
So xAI now has a "legal" copy of all of Tesla's code? Convenient.
https://electrek.co/2026/07/10/musk-tells-tesla-staff-switch...
The simplest way to disable uploading your repo is disabling it in the config.
> simplest way to disable uploading your repo is disabling it in the config
Have you verified this flag is respected?
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 completely made up. The Grok Build CLI reference lists no such thing. Whatever LLM you asked probably hallucinated this.
>completely made up
If you want easily verifiable evidence, run strings on the Grok Build CLI binary and you will see:
It does not appear anywhere in the docs.
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
None of them upload the whole repo, which is what this link claims it does. That's unheard of.
Codex would like to have a chat
Removing the word actually from the title really confused me
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
Now, where are the people afraid of the Chinese AI companies, who claim they are going to copy their very precious code...?
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.
> none of them upload entirety of codebase or even attempt to.
How do you know? Did you do an analysis like OP did?
no analysis. only based what I see in VSCode tool calls.
I'm not saying they are, but if they were, it probably wouldn't be in explicit tool calls shown to the user.
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.
same here. API access + low price is why I am using Chinese models
Considering DeepSeek Flash probably generates more of my precious code than any other model, yeah. I’m sure they have it. Good for them.
The second I opened Deepseek, it had my harness scan my entire home dir. Not sure what's worse here.
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 use omp with Deepseek v4 Flash and Pro. Probably put about 20 million tokens through it. I've never seen this. US-hosted versions. Opencode Zen.
Friendly reminder: since Musk now owns Cursor, there are a bunch of really good open-source alternatives you can use.
So Alex Karp was right, AI companies "are stealing customers' data while charging them for unproductive tokens."
I wonder how many of you guys actually read this kind of reports (or even skim through)? At the first glance it looks to me like someone just asked an agent for a security review of this CLI and then pasted results to the gist.
When I see a report like that I just assume it's a low-effort AI slop and stop reading immediately. Why would I read it since I can do the same with my agent and with that understand it better? Or if I'm really lazy then just copy paste this report and ask for a summary or have a discussion.
You literally did not take 5 minutes to even start reading the report or you would have realized how ridiculous your post is.
Please tell me then how ridiculous my post is. I wanna hear that - that's why I posted this. Your comment did literally nothing useful except bumping your own ego.
> You literally did not take 5 minutes to even start Yes you're exactly right - you can guess that from reading my post. But you're hitting the wrong topic there. Seems like you didn't understand what I asked.
But let me elaborate on that. Why would I take >5 minutes to start reading each report I see on the web? Like all humans I have limited capacity of information I can effectively gather so I'm not gonna start reading each article 24/7.
Topic was interesting, got many upvotes, so I opened the report. I saw there a bunch of LLM-generated paragraphs, got mixed feelings and just closed it. I mean just see the beginning "A measured, reproducible teardown. Findings are backed by captured artifacts (endpoint, HTTP method, status code, byte size, host) and repro commands; where an observation was seen live but not retained as a file, §7 says so explicitly.". When I see something like that I immediately lose motivation to read that.
This is yet another reason to use open weight models and open source harnesses so that this can never happen.
Why do you continue to give these companies all your secrets, env vars, source code and data? That is effectively a data breach by this form of malware.
If you had data that was never meant to be uploaded or shared by a third party, consider that a security incident.
It turns out that utility overrides all security concerns. It's the same reason that Cloudflare gets to snoop on 90% of web traffic. If you wanted a honeypot you couldn't ask for a better one.
sam altman: aww you're sweet
elon musk: hello human resources
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.
Mostly like enforcement is slow and I’m not even sure if someone has sent in a complaint.
imagine using grok lol
it's like purposefully running into a brick wall and giving yourself a concussion. you have to be a dumbass to do it.
[flagged]
"Eschew flamebait. Avoid generic tangents."
https://news.ycombinator.com/newsguidelines.html
Edit: I suppose I'd better add that this is not a defense of $THAT_GUY - just an attempted defense of HN comment quality.
Edit 2: Could you please stop posting unsubstantive comments and flamebait generally? It's not what this site is for, and destroys what it is for.
For example, we ban accounts that post things like https://news.ycombinator.com/item?id=48878096 and your account history unfortunately has quite a bit of this. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
It’s funny how you’re always policing me and not the thousands of other people that are posting much worse things. I’d be happy if there was a version where I can just see links, comments and add posts to favourites. That’s all I need really.
It always feels like the mods are against you, and it always feels like others are doing worse. These are fixtures of internet forum psychology and you are far from the only one who feels that way.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. You can help by flagging it or emailing us at hn@ycombinator.com.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Still, other people breaking the site guidelines doesn't make it ok for you to also break them, and pointing the finger at others, as if you needn't correct your own behavior, is unhelpful.
If you've gotten multiple moderation responses, the likeliest reason is that you've broken the site guidelines multiple times. Btw, it's nothing personal—we don't know anything about you—and the answer to your "it's funny" is that it's simply random.
I'm sure it's true that other people have done the same or worse and not gotten the same replies, because that's how randomness works. We do our best within the quantity limits of what we're physically able to read and respond to.
Shades of:
> People just submitted it. I don't know why. They 'trust me'. Dumb f..ks.
- Zuckerberg circa 2004, in case anyone is out of the loop
there are 2.7 m starlink subscribers in US, I don't think they are fools.
Those are people without a better option.
Big difference vs xAI, where the sentiment is valid.
I'm with you, and surprised I got so many downvotes for speaking about this.
There is a German proverb, that goes roughly like this: "eating shit is good for you, billions of flys can't be wrong!"
that's like 1% of the US
we definitely have that level of mental deficiency in this country..
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
A criminal is doing criminal things. Please, let’s not act surprised. The person who runs this company is the very worst kind of human being, literally shutting down agencies to stop investigations into his business practices. I would actually be surprised if he wasn’t doing shady things to try to catch his garbage product up with the competition.
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:
I assume this doesn't have anything to do with their speed improvements.
Grok 4.5 is so fast, it's great. And only $10/month subscription. It's slightly less censored as well.
I tried to use Grok once, but it required a Twitter Blue subscription, which required a 30-day-old Twitter account and for some reason they kept flagging my account for fraud sooner than that. Are they still doing these requirements?
I was able to get a free trial anonymously, not going to pay them.
No Twitter for me, just throwaway email.
No I think you can have a Grok account now without an X account.