What Your AI Coding Assistant Sends to the Vendor

When you use an AI coding assistant, roughly five categories of data leave your machine: the code you have open, code the assistant retrieves from elsewhere in your repository, your prompts, the terminal and tool output it reads, and telemetry about how you use it. What varies between vendors is not whether these leave, but how much of each, how long it is kept, and whether it trains a model.

That distinction matters more than the marketing does. "We do not train on your code" is a claim about one of the five, and it is the one most vendors can make honestly while still retaining everything for thirty days. Of the risks worth tracking when you adopt AI tooling, this one is unusual in being fully checkable, which is why it is worth actually checking.

The five things that leave

Open file context. Whatever is in your active buffer, plus some window around your cursor. This is the minimum required for completion to work at all. There is no configuration that removes it.

Retrieved repository context. Modern assistants pull in related files: the interface you are implementing, the test file, the config, sometimes an embedding index built over the whole repo. This is where the surprise lives. A developer editing a small utility file may be sending twenty other files they never opened, and this is the category most likely to include a secrets file, a fixtures file with real customer data, or an internal document that happens to live in the repo.

Prompts and chat history. Everything you type, including the parts where you paste a stack trace containing a customer email address or a production hostname.

Tool and terminal output. Agentic assistants read command output. env, git log, database query results, error messages with connection strings in them. If the agent runs it, the output goes into the context window, and the context window goes to the vendor.

Telemetry. Acceptance rates, latency, which model was used, session length. Usually anonymous, usually genuinely uninteresting, and worth mentioning only so you can stop worrying about it and worry about the other four.

The questions that separate vendors

Vendor policies change often enough that a table of current answers would be wrong within a month. The questions do not change. Ask these against the vendor's own documentation, not a comparison article:

1. Is there zero-day retention on the paid tier, or thirty? Many enterprise plans offer zero retention for inference. Many individual plans do not, even paid ones. This is frequently the only difference between two tiers with identical model access.

2. Does the free tier train on inputs? Very often yes, and very often disclosed clearly in a document nobody reads. It is a reasonable trade for a free product. It is not a reasonable trade for a client's codebase.

3. What is the retrieval scope, and can I bound it? Whether the assistant indexes the whole repo, respects .gitignore, respects a separate ignore file, and whether that index lives locally or on the vendor's servers.

4. Where does inference run, geographically? Relevant if you have data residency commitments in a contract. Ask about the inference endpoint specifically, not the company's headquarters.

5. What happens to data on subprocessors? Most assistants call a model they did not train. That is a second company with a second policy, and the sub-processor list is where you find out who.

Our guide on checking whether an AI tool trains on your data covers where these commitments are usually written down, and vetting an AI vendor covers the parts of that conversation that are actually negotiable.

A twenty-minute audit you can run today

You do not have to take anyone's word for what leaves. You can observe most of it.

Check what the retrieval index covers. Most assistants expose the list of files they have indexed, or a command that reports it. Look specifically for .env, .env.local, anything under a secrets/ or fixtures/ path, and any .sql dump. If your ignore rules only cover .gitignore and you keep a local-only .env, it may well be indexed precisely because git is not tracking it.

Read your own agent transcripts. Agentic assistants keep a log of tool calls. Skim one real session and look at what command output was pulled into context. This is usually the moment people find the connection string.

Watch the network once. Point a local proxy at the editor for a single session and look at request sizes rather than contents. You are not trying to decrypt anything. You are checking whether a small edit produced a 4KB request or a 400KB one, which tells you how aggressive the retrieval is far more reliably than the docs do.

Diff the tiers. Open your vendor's privacy page and your own billing page side by side. Confirm which retention policy your actual plan is on. This takes two minutes and is wrong surprisingly often.

Practical mitigations, ranked

Ordered by how much they buy you per unit of effort:

The fourth one is the answer if you only do one thing. An assistant cannot leak a secret that is not in a file it can read. Running an AI coding model locally is the nuclear option and worth understanding, though for most teams the capability gap is still large enough that it is a per-repository decision rather than a default.

If a secret has already gone out, what to do when an AI coding agent commits a secret to your repo covers the rotation sequence, and the same sequence applies when the secret went to a vendor's logs instead of a commit.

The realistic threat model

The failure that actually happens is not a vendor breach. It is a developer pasting a production stack trace with a customer identifier into a chat window on a free tier, or an agentic session running cat .env because it was debugging a config problem and that was a sensible thing to do.

Both are ordinary, well-intentioned actions. Neither is prevented by picking a better vendor. Both are prevented by not having the secret in a readable file, and by knowing which retention tier you are on before it matters. That is why the list above is ordered the way it is.

FAQ

Does my AI coding assistant send my whole codebase to the vendor?

Usually not all of it at once, but retrieval-based assistants send far more than the file you have open. Related files, indexed context and tool output all travel with the request. Check what your assistant's index covers rather than assuming it is just the current buffer.

Do AI coding assistants train on my code?

It depends on the tier. Free tiers commonly do, and disclose it. Paid and enterprise tiers commonly do not, and often add zero retention on top. Verify against the vendor's own policy page and check which plan your account is actually on.

Can an AI coding assistant read my .env file?

Yes, if the file is on disk and not excluded. Being untracked by git does not exclude it, and in some setups makes it more likely to be indexed. Use an explicit ignore rule for the assistant, or move secrets out of files entirely.

Is a local model the only safe option?

It is the most complete option and it costs you capability. For most teams the better trade is a zero-retention tier plus disciplined secret handling, with local models reserved for specific repositories where the data cannot leave.

What should I check before using an assistant on client work?

Retention policy for your specific plan, whether inputs train a model, the sub-processor list, and where inference runs. Get those four in writing if the client contract has any data commitments in it.