Grok got caught uploading your entire codebase…

[00:00:00]Two weeks ago, an AI security researcher discovered that the XAI code-writing agent was secretly packaging and uploading entire developer repositories to Google Cloud storage. A Sere Lab researcher created a large test repository and pointed the Grok Build command-line interface at it. He set up a proxy server to monitor every data request leaving his computer. And he discovered that Grok Build was sending more than just the specific code file it was asked for. In the background, it packed the entire repository, every tracked file, including the full git history, the ENV file with the database keys and passwords, and uploaded it all to the XAI repository. And all of this had nothing to do with what the agent was actually asked during the session. They directly wrote to him: " Okay, don't read any files," but he packed them anyway. And when they downloaded what had left the machine, the specially implemented control files, which the agent was strictly forbidden to touch, came back word for word. He even changed the privacy settings in the app, tested everything again, and still found that all the files had been transferred.

[00:01:12]Only the settings on the XAI side have changed. The key here is that the code was transferred from the computer, being packaged and sent to Google Cloud storage.

[00:01:22]Obviously, this caused quite a stir online, both on X and in various tech media outlets such as Hacker News and Tech Times. This all happened on July 9th, and within a few days, the packaging feature for entire repositories was disabled by the XAI server, and downloads stopped. Elon Musk then stated that the collected data, according to him, was completely and completely deleted. There will be no remnant of anything left. And two days later, they opened up the Grok Build source code on GitHub so anyone could download it. This means that now anyone can look inside and see what's really going on. It looks like there are still traces of the download left in the codebase, but they have been disabled on the server side. In this post, SpaceX confirmed that data retention was enabled by default for users with non-zero retention periods, and as of July 12, this option has been disabled for all Grok Build users. This video is not an attempt to discredit XAI or Grok. This incident only highlights the much broader issue of data storage by AI vendors, as almost every coding tool like Grok Build, Claude Code, CodeEx, or Cursor sends code somewhere, and there are three separate aspects of this situation that cannot be said with certainty. The first is where the code actually goes. You tell the tool the path to a folder, and of course, something is passed out.

[00:02:51]But on whose servers, in which country, and under whose control?

[00:02:55]Second, is a copy kept on the servers after the response is received?

[00:02:59]After all, sending a request and saving a copy are two different things, and nothing on the screen will tell you whether the second happened.

[00:03:07]The most worrying question is: do these mechanisms even work?

[00:03:12]Privacy settings, opt-out, ZDR modes. As we saw in this case, changing the privacy mode had no effect on data transfer. This is the act of trust you take when choosing a provider. Before we continue: if you like these in-depth breakdowns, subscribe to our channel below. This helps us a lot.

[00:03:32]There are different levels of data storage on cloud servers when working with your encoding agent. This is a learning use. Do they use your private data to train future models?

[00:03:44]Saved application state: whether the session can be resumed tomorrow, remotely or locally.

[00:03:50]Abuse and reliability logs that they keep for the security of the service. Caches, because storing a prompt in memory for a few minutes is not considered saving it. Only writing to disk is considered data retention. And the last thing is logging. This could be a gateway or a surveillance tool.

[00:04:07]For example, such as Langfuse or LangSmith. Many of them store the full request and response by default.

[00:04:14]It is important to track data movement step by step and identify areas where storage may become a problem.

[00:04:21]Having a signed agreement doesn't mean you're safe. Almost all providers offer a data processing agreement or addendum (DPA). These are documents that define what exactly the provider is allowed to store and do with your data. On the other hand, you have a zero data retention (ZDR) policy.

[00:04:41]This is a setting that ensures that nothing is saved permanently. They only work together.

[00:04:47]Each provider's agreement requires data retention unless a separate zero retention option is enabled. According to xAI's DPA documents, request-response pairs are stored for about 30 days. Even with ZDR, in-memory caching and query metadata remain unprotected. According to Cloud Code's policy, even with ZDR, Anthropic can retain input and output data for up to 2 years. So, this is a pretty nuanced and complex topic. When it comes to zero data retention, you can group different providers into two categories. For most large vendors like Cloud, OpenAI, Azure, it's all closed through the sales department. So, full confidentiality is a corporate feature, and you actually need to contact their customer service department.

[00:05:40]Whereas in others, like XAI, Together AI, Fireworks or OpenRouter, you can enable zero data retention with the click of a button, or it is enabled by default, and this is a double- edged sword as you cannot independently verify it from the outside. There is no test that would prove that the provider did not store anything.

[00:06:00]Existing audits, such as SOC 2 reports, only confirm that the company follows the stated processes, but no one monitors every request and proves that your prompt was not recorded. So whoever you choose, you choose to trust what they say and do. This changes the perspective on the “ closedness” of sales somewhat, because when a provider forces you to go through the approval process for zero retention, they are, in particular, trying to understand what exactly they can honestly promise you. For which endpoints, models, and functions are they willing to guarantee “zero” in writing? And after granting such access, certain features are disabled, as anything that needs to store your data to work cannot fall under this promise. At the same time, a smaller and faster company may offer you a convenient switch to zero data retention.

[00:06:45]However, in many cases, this is a promise that no one has audited. So, you can think of all this as a ladder of trust. And with every step you climb, you trust someone less and less. It's important to note that it's not necessarily about finding the best provider and running everything through it. Instead, it is worth classifying each task depending on its sensitivity.

[00:07:05]So the more secret or sensitive the job, the higher you climb this ladder. And most of us are at the very bottom right now, completely trusting the provider. These are default tools, with standard terms of use. For low- risk tasks, frankly, this level is sufficient. And it's probably better than most people assume.

[00:07:25]Standard API levels from major providers typically delete submitted data within 30 days and generally do not use it for training. It's worth checking this further, but that's usually the case. One improvement that can be made to the default settings is to keep unedited ENV files as far away from encryption agents as possible, using, for example, secret managers. The first level is zero- data storage management. This is someone else's cloud, where storage is disabled at the level of a written agreement. As we have already discussed, there are self-service options such as XAI, Fireworks, Together, OpenRouter. These are providers where you turn on the zero storage switch yourself without calling the sales department. For example, in Groq—and this is not Grok from xAI, but another Groq— you can enable global zero storage in the data settings. In Together AI, zero data retention is actually enabled by default.

[00:08:19]Whereas in closed systems like OpenAI, Azure, or Anthropic, you need to contact the sales department or support team. In any case, the limit of trust here is the promises of the providers plus your ability to verify them. Groq, for example, has an entire trust center with relevant compliance badges, controls, and resources. This level is ideal for general programming, say in closed code bases where you don't want data to remain on servers. You pay for zero data storage both through feature limitations and, more recently, through limited model choices. Due to controversies surrounding export control of the Mythos and Fable 5 models, access to them with zero data storage is not possible.

[00:09:01]In terms of functionality, ZDR is a guarantee that all requests will be stateless. One request comes in, one response comes out, and nothing is left behind. This means that any stateful functionality is outside the scope of this warranty. If you look at the XAI list, for example, there is a long list of API functions that do not work with ZDR. Mistral has a similar list of what is not included in the package when this feature is activated. Things like agents, batch processing, file uploads, saved conversations— all of these are excluded with zero storage. OpenAI has a similar correspondence table and a list of endpoints that are not available when using ZDR.

[00:09:41]When a provider cannot adapt a feature for ZDR, they usually simply disable it for that account. This can be a trap, because if you accidentally access this endpoint or enable the feature, it can silently restore data storage, and that's where the problems begin. This is where you need to understand in detail all the functions that the service offers.

[00:10:04]For example, the Google search function used in Gemini for fact checking. It stores information for up to three days in a separate system within their shared ecosystem. So the main rule of this first level is to clearly know which features you are willing to give up.

[00:10:20]Make sure you set storage to "false".

[00:10:23]Leave pass-through disabled, as sometimes hints can be passed from the main provider to the subprocessors, and then you will have to check which features you actually have enabled. The second level is not the use of a managed service, but the use of managed infrastructure. So, it's a GPU rental in the cloud that you can control yourself. These are services like RunPod or Lambda, or managed options like Modal, or the same step within a cloud account that your company already uses, running an open model in your own private AWS or Azure bucket. And the trust boundary shifts here because it becomes a clause in the terms of service that the host is contractually prohibited from viewing your data, plus the fact that you control the deletion. However, you should know two things about this.

[00:11:11]Here is the RunPod documentation. A rented GPU is usually a shared piece of hardware by default.

[00:11:17]So, your system is next to someone else's, so to speak.

[00:11:20]So if you want to get the hardware just for yourself, you need to choose the single- tenant option. And second: by stopping the pod, you clear the temporary disk, and you control this deletion, unless you attach a permanent volume, which will also need to be deleted. And Modal is a convenient and easy way to go, as their default output endpoints do not store data. And the highest level is local AI. So, Ollama, LM Studio, vLLM, llama.cpp.

[00:11:49]Here you run your own models on your own hardware, hidden behind firewalls, to which no third-party vendor has access at all. So, here you should have complete transparency and complete control because data storage is no longer an issue. The data does not leave your network. And as I said, you can choose these options depending on your use case. So, for your most important, most confidential data, you should use a fully local startup. This completely eliminates the risks. Whereas if you need larger models and don't want to bother with hardware management, renting a GPU in the cloud is a good approach. For everyday coding using proprietary databases, you can go to the first level, where ZDR is activated with the respective vendor. And for unimportant tasks that you're not too worried about, you can just rely on the default settings, like most people do. Building AI-powered solutions is an important part of what we teach in our AI Architect course. This is available in our AI Automators community, where hundreds of serious developers are building industrial-grade systems.

[00:12:56]If this interests you, be sure to follow the link below.

[00:13:00]Trust is key to everything we've talked about, because can you really prove data deletion when working with third-party providers? And that is the crux of the matter. Zero data retention is just a contract. This is not a technical mechanism.

[00:13:14]There is no cryptographic proof that your data was not saved. This is a written commitment that you cannot independently verify. This is why inspecting traffic, as Cereb Lab did in the XAI study, is so important, because network traffic is what you can see. You see requests leaving your network, and in most cases, " zero" is not exactly zero, as the security layer is still running in the background. As I mentioned about the Anthropic security classifier, they can retain data for up to two years even with zero retention enabled, so it's impossible to prove deletion.

[00:13:53]This is the same thing that was in XAI's tweet last week. There is no audit trail.

[00:13:58]We can only believe that it really happened. That's why on-premises solutions are the best choice for those who need full control and transparency. If you're interested in getting the most out of local AI models on your own hardware, check out my latest video about DeepSeek DSpark. And don't forget to subscribe to the channel if you want to see more videos like this. Thanks for watching, see you next time.