Do AI coding agents keep your code private? What to check before you connect a repo
Jul 20, 2026 · 9 min read · By Maya Cohen, Engineering
Whether an AI coding agent keeps your code private comes down to three things: whether it trains on your code, how long it retains it, and who or what can access it. The marketing answer is always yes. The real answer is in the data processing terms, and the three questions that matter are answerable in a few minutes if you know where to look.
Connecting an agent to your repository gives it read access to your source, and often the ability to open branches and pull requests. That is a meaningful grant of trust. It does not have to be a privacy problem, but it becomes one if you assume good behavior instead of confirming it.
Does the agent train on your code?
This is the first question and the one with the clearest right answer: reputable tools sold to businesses do not train their models on your private code, and they say so in the terms, not just the homepage. The distinction that trips people up is between training and processing. Every agent has to send your code to a model to do anything useful, so processing is unavoidable. Training, meaning your code becomes part of a model that improves and is served to other customers, is avoidable and is what you actually care about.
Read the data processing terms and look for an explicit statement that customer code is not used for training. If it is only on a marketing page and not in the contract, treat it as aspirational. The deeper mechanics of what training on code would even mean are covered in whether AI trains on your code.
How long is your code retained?
Processing your code to complete a task is fine. Keeping it indefinitely on someone else's servers is a different risk. Retention policy tells you how long your code, prompts, and generated output sit in the vendor's systems after the task is done, and whether that data is encrypted and access-controlled while it is there.
| What to ask | The answer you want |
|---|---|
| Is customer code used to train models? | No, stated in the contract, not only in marketing |
| How long is code and prompt data retained? | A defined, short window, or ephemeral processing only |
| Is data encrypted in transit and at rest? | Yes, with access limited to the task |
| Who can access the repository grant? | Scoped tokens, least privilege, revocable |
| Where is data processed? | A named region and subprocessor list you can review |
Short or ephemeral retention is the safe answer. If a vendor cannot tell you how long your code lives in their systems, that is itself the answer.
What can the agent actually access?
The third question is scope. An agent that can read one connected repository is a smaller risk than one holding a broad token across your entire organization. Look for scoped, least-privilege access you can revoke, and prefer tools that request the narrowest grant that lets them do the job. The same discipline applies to what the agent reads while it works, because untrusted text in an issue or a dependency can carry instructions; that failure mode and its defenses are in how to contain the real risks of a coding agent.
One adjacent point that teams in regulated settings raise: your source and logs sometimes contain personal data, in test fixtures, seed files, or captured payloads. If a subject asks you to delete their data, you need a way to honor that request wherever the data landed, which is easier when you have a clear inventory and a process to remove personal data from the systems it spread to. That is not the agent vendor's job, but it is part of the same privacy posture.
Does a human always review the change?
Privacy is about who sees your code; safety is about what ships. A review-first agent never merges on its own, so a person approves every change before it reaches your main branch. That control is separate from the data questions above but belongs in the same evaluation, because an agent that could merge unattended is a different risk profile entirely. How that review gate works, and where automated review helps, is covered in how AI code review works and where it falls short.
Where Agentcode stands
Agentcode does not train on your code, keeps a human on every merge, and works on your existing GitHub or GitLab repository with scoped access rather than a broad organization-wide grant. It is review-first by design: the agent writes the change, runs your tests, and opens a pull request, and nothing merges without a person approving it. Those are the same three properties this article tells you to verify in any vendor, which is the point: ask for them in writing, from whoever you choose.
What about self-hosting and regulated teams?
Some organizations cannot send code to a third party at all, either because of contractual obligations to their own customers or because a regulator requires it. For those teams the questions above are table stakes and two more get added: can the tool run in your own environment or a private cloud, and will the vendor sign the data processing agreement your compliance team needs. Not every tool offers self-hosting, and the ones that do usually reserve it for enterprise contracts, so ask early if it is a hard requirement.
Most teams are not in that bucket, and for them a hosted tool with a clear no-training commitment, short retention, and scoped access is enough. The point of asking is to land in the right category on purpose rather than by accident. If you operate under a specific framework such as SOC 2 or an industry rule, the practical considerations are laid out in using AI coding agents in regulated industries.
The short version
An AI coding agent keeps your code private when the vendor contractually declines to train on it, retains it briefly or not at all, scopes its access to the task, and leaves the merge to a human. All four are checkable before you connect anything. Ask the questions, read the data terms rather than the homepage, and prefer the tool that answers plainly. Privacy here is not a feature you can see; it is a set of commitments you confirm.