What to Check in an AI Coding Tool's Privacy Policy

A checklist for auditing what any AI coding assistant does with your source code: retention, training use, subprocessors, and the settings that quietly change all three.

This post was created with AI assistance and reviewed for accuracy before publishing.

"Does this tool upload my code?" is the wrong question, because the answer for every cloud-backed assistant is yes, at least sometimes. Completions require context, and context is your code.

The useful questions are narrower: which code, how long is it kept, who else sees it, is it used for training, and which of those answers change depending on a setting somebody can toggle.

This applies to any assistant. Vendor policies change, so what follows is a checklist to run against the current documentation rather than a summary of any particular product's terms.

What actually leaves the machine

Start here, because it is usually broader than developers assume. Beyond the file you are editing, an assistant may send surrounding files, imports it resolved, repository structure, and in agent modes the output of commands it ran.

That last category is the one that catches people. If the tool can run tests or a build, it can capture whatever those commands print, and build output routinely contains environment variables, connection strings, and internal hostnames.

Also worth establishing: does an indexing feature upload the whole repository, or only embeddings of it? Those are meaningfully different exposures, and both are usually described somewhere in the documentation.

The five things to find in the policy

The subprocessor list is the one most often skipped and it is where the real answer lives. A tool that does not train on your code may still route it to a model provider that has its own retention policy. Read that provider's terms too, since it is the party actually holding the data.

Abuse-monitoring retention deserves specific attention. Providers commonly keep request data for some period for safety review even when the product tier promises no training and short retention. That is a defensible practice and it is a different number from the one in the marketing table.

Check the defaults, then check them again after an update

Almost every tool has a privacy mode that reduces or eliminates retention. Three things are worth verifying rather than assuming.

Whether it is on by default, and specifically whether that differs between free, pro, and enterprise tiers. Whether it applies to every feature, since a tool can honour it for completions and not for a newer agent mode. And whether it survives updates, because settings do occasionally reset or a new feature ships with its own separate toggle.

The practical version of this: after any major version update, re-open the privacy settings and look. It takes a minute and it catches the case where a new capability arrived with a permissive default.

For team and enterprise use

If the tool is being approved for a team rather than an individual, a few additional items belong on the list.

Whether an administrator can enforce the privacy setting centrally, rather than trusting each developer to configure it. Whether the vendor offers a data processing agreement, which you will need if any regulated data can appear in your codebase. Whether attestations such as SOC 2 are available on request, if your own contracts require them. And what the deletion path is, both for an individual leaving and for terminating the contract.

Ask specifically whether deletion covers backups and logs, and on what timeline. "Deleted from our systems" and "deleted from our backups within 90 days" are both reasonable answers, and only one of them is what most people assume they are getting.

Keep a dated record

When tooling is approved, save a dated copy of the policy as it stood, not just a link. Policies are updated without notice, and if a question arises later about what was agreed, a live URL cannot tell you what it said at the time.

A PDF or an archive link with the date is enough. This is unglamorous and it is exactly what an auditor or a customer security questionnaire will ask for.

The rule underneath all of it

Do not infer policy from forum posts, changelogs, or someone's confident summary, including this one. Read the vendor's current pages, note the date you read them, and re-check when the tool updates significantly.

The tools are genuinely useful and this is not an argument against using them. It is an argument for knowing what you agreed to, which takes half an hour once and is difficult to reconstruct later.