Every AI coding tool tells you some version of "we don't train on your code." That sentence is only as strong as the company saying it — and, as Cursor's acquisition by SpaceX just reminded everyone, the company saying it can change overnight. If your codebase is a competitive asset, you don't want to rely on a single promise. You want defense in depth: layers where each one still holds if the one above it fails.
Here's the practical version, from the cheapest fix to the strongest.
First, the distinction that decides everything: API vs. chat#
Most accidental code leaks come from confusing two very different products:
- Business/developer APIs — the endpoints your app and tools call. The major providers do not train on API inputs by default. OpenAI and Anthropic both state that data submitted through their APIs is not used to train their models unless you opt in.
- Consumer chat tiers — the free/personal chatbot. These often can use your conversations to improve models unless you turn it off.
The single highest-leverage rule: stop pasting proprietary code into consumer chatbots. Route it through the API, where the default already protects you. That one habit change closes the most common leak before you touch a contract.
Layer 1 — get zero data retention in writing#
"Not used for training by default" still leaves one gap: abuse monitoring. By default, some providers retain your inputs for a limited window (commonly ~30 days) so they can investigate misuse. Zero data retention (ZDR) is the contractual term that removes even that — the provider doesn't store your inputs or outputs at rest after serving the request.
ZDR is a term you negotiate on a business/enterprise agreement and then verify — not a checkbox. When you ask, get answers to exactly these:
- Is training-on-our-data off, contractually, not just by policy?
- Is the default abuse-retention window removed under ZDR?
- Does the guarantee survive a change of control?
That last question is the one the Cursor deal made non-theoretical.
Layer 2 — enforce it at one chokepoint#
A contract you can't enforce is a hope. The enforcement mechanism is architectural: route every model call through a single gateway with a provider allowlist, so "which vendors are allowed to see our code" is one config value you own — not a setting each developer flips in each tool.
# litellm gateway: only ZDR-covered providers may receive code
model_list:
- model_name: code-primary
litellm_params:
model: anthropic/claude-sonnet-5
api_base: https://api.anthropic.com # your ZDR-covered account
- model_name: code-fallback
litellm_params:
model: openai/gpt-5.6-terra
api_base: https://api.openai.com # ZDR-covered account
# Anything not on this list simply can't be called.
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
Point every tool, agent, and script at the gateway (LiteLLM, an internal proxy, whatever) instead of at providers directly. Now adding or dropping a vendor is a reviewed one-line change with an audit trail, and a rogue endpoint that isn't on the list can't receive a single token of your code.
Your policy is only as good as the narrowest place all traffic must pass through. If there's no chokepoint, there's no policy — just a document.
Layer 3 — watch the tools, not just the models#
The model provider is rarely the leak. The leak is the tooling around it — IDE autocomplete, agent runners, and observability that quietly ship code to endpoints your policy never reviewed. Three quick controls:
- Pin the privacy mode in every AI coding tool, and confirm it's the default on every seat — not something each developer must remember to enable.
- Kill prompt-logging leaks in your own stack. Your LLM traces and error logs are the most common everyday exposure. Redact or hash code before it lands in logs, and check that your tracing vendor's retention matches your model provider's.
- Inventory the egress. Any tool that can read your repo and make an outbound call is in scope. If you can't name where it sends data, assume it's the wrong place.
Layer 4 — when contracts aren't enough, self-host#
For code that legally or strategically cannot touch anyone's training pipeline — regulated data, air-gapped environments, crown-jewel IP — stop renting trust and change the guarantee from contractual to physical. Run an open-weight model on your own hardware and the code never leaves your network. There's no provider to trust, no policy to change, no acquisition to survive.
Open weights make this real in 2026: models like Z.ai's GLM family and Llama-class releases are strong enough for most day-to-day coding, MIT- or permissively-licensed, and deployable behind your own firewall. You take on the operational cost of serving a model — but you get the one guarantee no vendor can match: the data physically never leaves.
The one-paragraph policy#
Most teams don't need all four layers on day one. The default posture that covers the common case: API only, never consumer chat; ZDR in writing with the change-of-control clause; one gateway with a provider allowlist; privacy mode pinned and logs redacted. Reserve self-hosting for the code that can't be allowed off-network at all. That ladder turns "we don't train on your code" from a promise you inherited into a property you control — which is the only version that survives your favorite tool changing owners.



