Where Your Code Actually Goes: AI Coding Agent Privacy
Before an AI coding tool is useful, somebody in your organisation has to answer a harder question than whether it writes good code: where does the code go. Most tools answer partially — a privacy policy about training, a note about retention — and leave the mechanics unstated. This is the mechanical answer for Atlarix, including the parts where code does leave your machine, because a privacy page that only lists reassurances is not one.
What never leaves, and why that is structural
Atlarix builds no index of your codebase. There is no embedding model, no vector store and no symbol graph, so there is no artefact of your code sitting anywhere — not on your disk, not on ours. Search is bundled ripgrep, shelled out per call, holding no state between calls.
This matters more than a retention promise because it is not a policy. There is nothing to retain, nothing to leak in a breach, and nothing to invalidate. A tool that indexes has to be trusted to handle the index; a tool that does not index has nothing to be trusted with.
What does leave, stated plainly
The files the model reads go to the model. That is what a coding agent is, and any tool claiming otherwise while calling a hosted model is describing something that cannot work.
With Atlarix Core, the managed option, requests route through our proxy — not logged, not retained — to the provider serving them. Bring your own API key and the request goes to that provider directly. Run a local model through Ollama or LM Studio and nothing touches our infrastructure at all, and nobody meters you.
Approval before anything is written
Reading is one risk; writing is another. Every file write an agent proposes goes into an approval queue where you see the diff first, and on a multi-hunk edit you can accept some hunks and reject others rather than taking the whole change.
Commands are separate again. Agent commands run inside an OS-level write-confining sandbox — Seatbelt on macOS, Landlock on Linux, Low Integrity Level on Windows — which restricts writes to your workspace and granted paths while leaving reads and execution alone.
Three surfaces, one account, one balance
Atlarix is a desktop app, a Chrome extension and a GitHub pull-request reviewer. They share one account and one balance, and spend is attributed per surface on a single ledger from a header the server validates rather than a string the client sends.
That is unusual enough to be worth naming. The common arrangement elsewhere is a subscription for the editor, separate metering for review, and compute billed to the repository — three bills and three trust decisions for one vendor.
The extension, including its uncomfortable part
Page contents and attachments never sync to our servers. A tool result is stored as a label capped at 200 characters, and an attachment as a placeholder naming the file. That is enforced twice: by the function that projects a conversation for sync, and independently by a database constraint that rejects anything longer.
The uncomfortable part: the extension requires broad host access at install, so Chrome tells you it can read and change data on all websites. That is required rather than optional, and you narrow it from chrome://extensions rather than widening it from the panel.
The reviewer never runs your code
Atlarix Reviewer reads pull requests and posts findings. Its entire tool surface is three read-only operations — read a file, find files, list changed files — and the hosted path builds its context from read-only API calls. No clone, no checkout, no container, no runner.
The security consequence is the point: there is no build step to poison and no runner to compromise. A reviewer that executes the branch it is reviewing is running untrusted code by definition, which is a design most review bots accept and we did not.
The honest summary is that your code goes to a model and nowhere else, that you choose which model and whether we are involved at all, and that nothing about your codebase is stored anywhere in a form that outlives the request. Everything above is checkable in the product rather than only in a policy — which is the standard we would want applied to us.