AI coding agents are becoming a normal part of software work. I use them to explain unfamiliar code, draft changes, find bugs, and move much faster through repetitive tasks. Yet every time I point an agent at a folder, I need to ask a more basic question first: what data is leaving my machine, where is it going, and what happens to it afterwards?
That question became much more urgent after an AI safety researcher, Cereblab, investigated xAI’s Grok Build coding agent on July 9. The findings were serious. A test repository was created, Grok Build was pointed at it, and a proxy recorded outbound requests from the machine.
The agent did not appear to send only the file relevant to the request. In the background, it packaged the entire tracked repository and enqueued it to a Google Cloud Storage bucket. The reported bundle included the Git history and an unredacted .env file containing keys and database passwords. It also included planted canary files that the agent had been explicitly told not to read.
This is not a hit piece on xAI or Grok. The incident is important because it exposes a much bigger issue across AI coding tools. Claude Code, Codex, Cursor, Grok Build, and similar products all need some degree of access to code in order to help with it. The hard part is understanding the exact boundaries of that access.
What the Grok Build investigation found
Cereblab’s test was simple in principle. Instead of taking a provider’s privacy statement at face value, the researcher inspected the traffic leaving the machine. That is the part of the process I can actually observe from my own network.
The test repository contained deliberate canary files. These are files placed specifically to prove whether a tool accessed or transmitted information it should not have touched. Grok Build was instructed in plain language to reply with a basic acknowledgement and not read files. Despite that instruction, the repository was reportedly packaged and uploaded.
The distinction matters. An AI coding agent may need to send context to provide a useful answer. But sending an entire repository, including version history and secrets, is very different from sending one selected code file or a carefully scoped excerpt.
The investigation also tested the application’s privacy setting. Changing it did not stop the repository transmission at that time. It changed a retention-related flag on xAI’s side. In other words, the setting affected what might happen after transmission, but not the fact that data left the machine.
This is why I separate two questions that often get mixed together:
- Transmission: Does code, a prompt, a file, or a whole repository leave the local computer?
- Retention: After it arrives, does any provider, system, log, or subprocess keep a copy?
A privacy option may address retention without limiting transmission. It may also apply to one endpoint but not another. Neither the name of a toggle nor the presence of a policy page is enough to answer both questions.
What changed after the report
The incident attracted broad attention across technical media and social platforms. Within days, xAI switched off the whole-repository packaging server-side, which stopped the upload behavior described in the research.
xAI also disabled default retention for Grok Build users from July 12. Elon Musk stated publicly that the collected data had been deleted completely. That statement may be reassuring, but it remains a pledge from the provider. Someone outside xAI cannot independently verify that deletion took place.
Two days later, xAI open-sourced the Grok Build codebase. That was a meaningful step because developers can inspect how the tool works rather than relying entirely on product messaging. The code still showed traces of upload-related logic, although that behavior had been disabled server-side.
I think the useful lesson here is not that every AI coding tool is secretly uploading every repository. The lesson is that the visible product interface rarely gives enough information to determine the full data path.
The three things I usually cannot tell from a coding agent
Once I point an AI agent at a project folder, three uncertainties appear immediately.
1. Where does the code actually go?
A request clearly leaves my device if I am using a cloud-based coding agent. But where does it go after that? It may reach the AI provider directly. It may move through a gateway, a cloud host, an observability service, a search integration, or another subprocess.
Location matters as well. The country where data is processed, the legal entity that controls it, and the vendors handling it can all affect security obligations and contractual requirements.
2. Is a copy retained after the answer arrives?
A prompt leaving my machine and a copy being stored are separate events. The answer can return in seconds, while the content may remain in logs, application state, a support system, or a safety review process for days, months, or longer.
Nothing in a typical coding assistant interface tells me whether that second event happened. A fast response does not mean data disappeared.
3. Do privacy controls actually affect the relevant behavior?
Many products offer privacy opt-ins, training opt-outs, or zero data retention settings. These controls can be useful. But I need to know what each one changes in practice.
The Grok Build incident showed why this matters. Switching a privacy mode did not stop the data from leaving the computer during the reported tests. A control can apply to storage, model training, or account history without applying to transmission, file collection, or a connected feature.
Leaving your machine is not the same as keeping your data
Data can persist at multiple points during one request to an AI coding agent. I find it helpful to map each stage instead of treating “retention” as one vague category.
Training use
The first question is whether a provider uses prompts, code, files, or outputs to improve future models. Many business and API offerings say they do not train on customer API data by default, but I still need to check the terms that apply to the specific account and product.
Stored application state
An agent may save conversation history, uploaded files, project context, or a session record so that work can resume later. This can be convenient, but it also creates stored material that may sit outside the model request itself.
Safety, abuse, and reliability logs
Providers often retain records to detect misuse, investigate incidents, monitor quality, and keep their systems reliable. These systems can contain inputs and outputs. A zero data retention setting may have exceptions for safety functions, depending on the provider’s terms.
Caches
Data may also sit temporarily in memory. A prompt held in a short-lived cache is different from information written to disk for longer-term storage. The difference is technical, but it matters because zero data retention policies often focus on persistence rather than every moment of processing.
Logging and observability tools
One of the easiest places to overlook is the logging layer. An API gateway or observability platform can record full prompts and responses by default. Tools used for tracing agent runs can become an additional data store even if the model provider itself has strict controls.
Before I use an AI system with anything sensitive, I map the route end to end. I consider the coding tool, the model provider, file upload systems, search connectors, logging services, and any other linked service. A single weak point can defeat a careful setting elsewhere.
A DPA and zero data retention are different things
Businesses often rely on a Data Processing Agreement, or DPA. A DPA is a contract that explains what a provider may collect, process, store, and do with customer data. It is important paperwork, but it does not automatically mean the provider stores nothing.
Zero data retention, often shortened to ZDR, is a separate promise. In simple terms, it means the provider says it will not persist request data after processing, subject to the scope and exceptions in the policy.
These two concepts work together:
- A DPA establishes the contractual rules for processing data.
- A ZDR configuration limits persistence for eligible requests or services.
I cannot assume a signed DPA makes an account zero-retention by default. In many cases, the agreement still allows a provider to retain data unless a separate ZDR configuration is enabled.
xAI’s DPA documentation described prompt and response retention of roughly 30 days. It also made clear that some temporary in-memory caching and request metadata sit outside the simplest interpretation of zero retention.
Anthropic’s Claude Code ZDR documentation adds another important nuance. Even where ZDR applies, associated inputs and outputs can be retained for up to two years in connection with a safety classifier. That does not mean the ZDR policy is meaningless. It means I need to read the exceptions as carefully as the headline.
Who gets zero data retention?
Providers broadly fall into two groups. The first group treats ZDR as an enterprise feature. The second group offers it through a self-service control or enables it by default for certain products.
Sales-gated ZDR
Major providers such as OpenAI, Anthropic, and Azure often require an enterprise agreement or an approval process for stronger retention commitments. This can feel inconvenient, but there is a practical reason for it.
The provider needs to define exactly what it can promise. That may include specific models, endpoints, regions, features, and account controls. Some functions need storage to work, so they cannot sit inside a strict ZDR commitment.
For this reason, the sales process is partly a scoping exercise. It identifies the exact service boundaries where a provider will put the word “zero” in writing.
Self-service ZDR
Other providers, including xAI, Together AI, Fireworks, OpenRouter, and Groq, can offer ZDR through a setting or provide it as a default for some services. This is convenient and can be a good fit for teams that need rapid access to stronger controls.
However, convenience does not create independent proof. A friendly toggle is still a provider promise unless the service offers a way to verify the full data path and storage behavior.
SOC 2 reports and similar audits provide useful evidence that a company runs documented security processes. They do not normally prove that every single request from every customer was never written to storage. No outside party is inspecting every request in real time.
The trade-offs of zero data retention
ZDR changes what an AI service can offer. A strict zero-retention request is stateless: one request enters, one response leaves, and the provider does not keep the session behind.
That sounds simple, but many popular features depend on state. They need to store context, files, conversations, or background work to function.
Common exclusions can include:
- Agents that continue work over time
- Batch processing
- File uploads
- Stored conversations
- Collections and retrieval systems
- Background jobs
- Some search-grounding features
For example, a search-grounding feature can send information into a separate system with its own retention period. Gemini’s Google Search grounding service can retain data for up to three days in that separate part of the service.
This creates a potential trap. A user may enable ZDR for the main API, then turn on a feature that is outside the ZDR boundary. If that feature works, it may be using a separate retention policy. I need to audit every feature I activate, rather than assuming one account-level setting covers everything.
For managed ZDR setups, I follow a simple operational rule:
- Set storage to false where the provider exposes that control.
- Keep pass-through features disabled unless I understand their subprocessors.
- Check which models, endpoints, and tools are eligible for ZDR.
- Review file uploads, agents, batch jobs, and search integrations separately.
- Keep unredacted environment files away from coding agents entirely.
A secrets manager is a much safer place for keys, database credentials, and tokens than an unredacted .env file sitting inside a repository an agent can inspect.
The AI data trust ladder
I don’t think the goal is to find one perfect AI provider and route every task through it. The better approach is to classify work by sensitivity. The more confidential the task, the less trust I should need to place in another company.
Level 1: Provider defaults for low-stakes work
At the bottom of the ladder, I use the provider’s normal API terms and default controls. For low-stakes tasks, this is often reasonable. Major API providers commonly retain submitted data for around 30 days and usually state that they do not train on business API data by default, though the exact policy always needs checking.
This level is appropriate for work where the data is not highly sensitive. It is not suitable for secrets, regulated records, private customer material, or the most valuable parts of a company codebase.
Level 2: Managed zero data retention
The next level is a managed cloud service with ZDR enabled. The model still runs on someone else’s infrastructure, but the provider has agreed not to persist eligible request data.
This can fit general coding work on proprietary codebases where I do not want source code sitting on cloud servers after the request completes. The trust boundary is the provider’s contractual promise, technical controls, and the ability to inspect the service’s policy and security documentation.
There are trade-offs. Certain models may not be eligible. Stateful features are often unavailable. The service may also limit which endpoints I can use under ZDR.
Level 3: Managed infrastructure and rented GPUs
The next step is to rent computing infrastructure rather than buy a managed AI service. This can mean using RunPod, Lambda, Modal, or a private section of an existing AWS or Azure account to run an open model.
The trust boundary shifts. The infrastructure provider is contractually restricted from accessing the workload, while I control the model, application, deployment, and deletion process.
Two practical details matter here.
- Shared hardware: A rented GPU is often shared infrastructure by default. If the use case requires dedicated hardware, I need to choose a single-tenant option.
- Persistent storage: Terminating a temporary pod can wipe its scratch disk, but an attached persistent volume remains until I remove it separately.
Modal can be a useful entry point because its inference endpoints have zero data retention by default. Still, managed infrastructure does not remove the need to understand storage, access controls, and attached volumes.
Level 4: Local AI for the most sensitive data
At the top of the ladder is local AI. This means running models on hardware I control, behind my own network and firewall. Tools such as Ollama, LM Studio, vLLM, and llama.cpp make this approach increasingly practical.
When data stays on local hardware, the outside provider retention problem largely disappears because the source material does not need to leave the network. I gain much better transparency and direct control over files, prompts, logs, and model behavior.
Local deployment has costs. I need hardware, model management, storage, and enough technical capability to operate it well. Larger cloud models may still outperform what I can run locally. Yet for crown-jewel information, a local model offers the clearest path to keeping data inside the boundary I control.
Match the AI setup to the sensitivity of the work
A useful data policy does not need to force one tool on every task. I can use different levels of the trust ladder for different classes of work.
- Low sensitivity: Use standard provider controls for general research, public code, and low-risk drafting.
- Proprietary code: Use a managed service with ZDR enabled and remove secrets from the agent’s reach.
- Highly confidential work: Run an open model on rented infrastructure where I control the environment and deletion process.
- Crown-jewel data: Run models locally, with no third-party AI provider receiving the underlying information.
This approach avoids an all-or-nothing choice. It also avoids pretending that every request has the same risk. A public utility script and a production repository containing credentials should never receive identical treatment.
Why zero data retention cannot be fully proven from outside
The hard truth is that ZDR is a contractual commitment. It is not a cryptographic proof that makes hidden storage impossible. A provider can publish policies, undergo audits, and supply enterprise agreements, but I still cannot inspect every internal database, every cache, every safety system, and every deletion job.
I can inspect the wire. I can see requests leaving my network. I can check whether the agent is sending an entire repository, a selected file, or a smaller context window. I can also inspect local logs, monitor domains, review source code where it is available, and validate that sensitive files are excluded.
What I cannot normally prove is that a third-party provider kept nothing after the request arrived. That is why the Grok Build investigation mattered so much. It tested the observable part of the system rather than relying on a setting label.
Safety systems add another layer. Even under ZDR, providers may retain content related to abuse detection, policy enforcement, or security review. Those exceptions may be reasonable. But they mean “zero” is rarely as absolute as it first appears.
For the highest-sensitivity work, local AI is the only option in this ladder that removes the need to trust an external provider’s deletion process. The information does not leave the controlled environment in the first place.
A practical checklist before connecting an AI coding agent to a repository
I use this checklist before I grant an agent access to a meaningful codebase:
- Classify the repository. Decide whether it contains public code, proprietary logic, customer data, credentials, or regulated material.
- Remove secrets first. Keep unredacted environment files, API keys, database passwords, and tokens in a secrets manager rather than accessible project files.
- Read the data policy for the exact product. API policies, consumer chat policies, coding-agent policies, and enterprise terms may differ.
- Separate transmission from retention. Confirm what files and context the tool can upload, then check what happens after upload.
- Enable ZDR where it fits. Verify which models, endpoints, and features are actually included.
- Check linked tools. Review observability systems, search grounding, file upload features, gateways, and subprocessors.
- Inspect outbound traffic where the risk justifies it. Network monitoring can reveal what leaves the machine.
- Move up the trust ladder for sensitive work. Use managed ZDR, controlled cloud infrastructure, or local models based on the sensitivity of the task.
- Document the decision. A short internal record of approved tools, settings, and repository classes makes consistent use much easier.
AI coding agents can be extremely useful. They can also become a direct path from a developer machine to infrastructure that is hard to inspect. The right response is neither panic nor blind trust. It is to understand the data route, minimize what an agent can access, and choose a level of control that matches the value of the code and information involved.
