Every code review tool has a privacy policy, and most of them say something close to: we do not sell your code, we do not share it with third parties, we take security seriously. Each of those sentences is true on the day it is written. None of them tells you whether your code is safe.
What actually happens to code you submit
When you paste code into a review tool it goes somewhere. A server receives it, a process analyses it, a response returns. The only question that matters is what happens in between, and specifically whether anything was written down.
Most tools write it to a database. Sometimes for review history, which is a genuinely useful feature. Sometimes for model training. Sometimes retained for a fixed window then deleted. The details vary; the common thread is that your code now exists inside someone else's infrastructure in a form that can be read, exported, subpoenaed, or exposed.
What is the difference between a policy and an architecture?
A policy is a commitment made by the current management of a company. It holds until it does not. Companies get acquired, leadership changes, business models get revisited under pressure. The privacy policy you agreed to today is not necessarily the one governing your data in three years, and you will most likely learn about the change through an email you skim.
An architectural constraint is a different category of thing. If a system never writes submitted code to persistent storage, then there is no stored code, not as a matter of restraint, but as a matter of what exists. There is nothing to breach, nothing to produce under legal demand, nothing to include in an asset sale, and nothing to quietly reclassify as training data.
A privacy policy describes what a company intends to do. An architecture describes what its systems are capable of doing. Only one of those survives a change of ownership.
Why this matters for your codebase specifically
It helps to be concrete about what is actually in the files you would submit.
- Your authorisation logic: precisely how sessions are validated and permissions enforced. Read together, this is a map of your security perimeter drawn by you.
- Your business rules: the pricing, entitlement, and workflow logic that differentiates your product from a template. This is frequently the actual moat.
- Your unreleased work: the feature you are building now that competitors do not know exists.
- Your integration surface: which third parties you depend on, and how you talk to them.
All of that travels to the reviewer. What happens next is determined entirely by how the reviewer was built, not by how sincerely it was described.
What zero retention looks like in practice
At Nexdge, code enters an ephemeral process, the specialists analyse it in memory, findings are returned, and the process is destroyed. The findings and score are stored against your account so your history works. The code itself is never written.
That is a design decision rather than a promise, which is the entire point: it cannot be revised by a terms-of-service update, it does not change hands in an acquisition, and it cannot be complied with under a legal demand because there is nothing to hand over. The security page sets out the full model, and the privacy policy documents what is retained and for how long.
Does zero retention cost you anything?
Honestly, yes. One thing. You cannot have features that require the tool to re-read your code later: no diffing this month's submission against last month's, no cross-file analysis over a history you never stored, no fine-tuning a model on your codebase.
That is a real trade and it is worth stating plainly rather than pretending the decision is free. For teams reviewing proprietary production code, giving up retrospective diffing to remove an entire category of risk is a straightforward trade. For teams that want a tool trained on their private repository, it is the wrong architecture and a different product is a better fit.