Where your code goes when developers use AI

The short answer, because the question deserves one: on the business and enterprise tiers of the major AI coding assistants, your code is not used to train models, retention is bounded or zero, and the guarantees are contractual. On consumer tiers, most of those guarantees weaken or disappear. AI coding assistant data security is therefore less a vendor question than an account question. The risk is rarely the enterprise contract; it is the personal account a developer signed up with last spring and still uses.

Before rolling out agents to an engineering team, get three questions answered per tool, in writing: is our code used for training, what is retained and for how long, and who processes it (which subprocessors, in which regions). Most of what fills vendor security pages is decoration around those three.

What AI coding assistants guarantee, tier by tier

This is about data handling, not capability. Which tool fits which team is a separate question.

GitHub Copilot: on Business and Enterprise plans, your prompts and code are not used to train models, and the commitment sits under GitHub’s data protection agreement, documented through the GitHub Trust Center. Individual plans carry settings around snippet collection that you should not assume are configured the way you would want.

Anthropic: under commercial terms (the API, Claude for Work, Claude Code on commercial accounts), inputs and outputs are not used for training by default and are deleted from backends within 30 days, and qualifying organizations can arrange zero data retention. Consumer Claude accounts run under different terms, with a training preference the individual user controls, not you.

OpenAI draws the same commercial boundary on its enterprise privacy page: no training on business data sent through the API, ChatGPT Team or ChatGPT Enterprise. Consumer ChatGPT is the tier where content can feed training depending on user settings.

Cursor routes code through model providers, so its privacy mode is the setting that matters: enabled, Cursor does not train on your code and holds zero-retention agreements with its upstream providers, and on business plans it is enforced organization-wide.

Two caveats. Policies change, so assign an owner and re-verify quarterly against the vendor pages rather than trusting any blog post, this one included. And the tier is the guarantee: the same vendor, the same model, on a different account type, can answer all three questions differently.

Consumer accounts are the actual leak

When we see company code actually reach places it should not, it is almost never through an enterprise contract. It is a developer on a personal account, usually because the company banned the tools or simply never provided them. Prohibition does not produce abstinence; it produces shadow use on exactly the tiers with the weakest guarantees, invisible to your security team. The strongest data-security move available is unglamorous: buy the enterprise tier of the tools your engineers already want, make the sanctioned path the easy path, and state clearly what may go where.

Secrets in context, the part no vendor fixes

Even a perfect contract covers only what happens after data leaves. Whatever a developer or an agent puts in the prompt is in the prompt. Agents raise the stakes here: an autocomplete assistant sees the open file, while an agent exploring your repository to fix a bug reads whatever it decides it needs. If credentials sit in a .env file at the project root, they are now in context.

The controls are on your side of the line: secrets in a secret manager, never in files an agent can read; secret scanning as a pre-commit hook and again in CI; deny rules in the agent’s permission configuration for paths and commands it must not touch, the same discipline you would apply when giving any agent access to your systems; and scoped, short-lived tokens for whatever the agent legitimately needs.

The pre-rollout checklist

• The three questions (training, retention, subprocessors) answered in writing, for each tool, at the tier you are actually buying.
• A data processing agreement in place, reviewed by whoever owns GDPR, with regions checked against your residency requirements.
• Enterprise tiers purchased before the policy is announced, so the sanctioned path exists on day one.
• Secret scanning on, agent permission configs reviewed, .env patterns and credential paths denied.
• A one-page policy saying which data may go to which tool, written as enablement with limits rather than prohibition.
• A named owner and a quarterly date to re-verify every vendor claim above.

We run this exact review, tool by tool and tier by tier, in the first weeks of an agentic engineering engagement, because rollout speed is worth little if legal has to walk it back in month three.