AI Code Review Privacy: Does It Store Your Code?

When an AI tool reviews a pull request, it has to read your diff. That’s the point. But reading a diff means your code leaves your repository and travels somewhere — a vendor’s service, an LLM API, a cloud region you may not control. For a lot of teams, that’s fine. For teams with compliance obligations, customer data in the codebase, or simply a conservative security posture, the details matter quite a bit.

This post is a neutral explainer. It covers how different tool architectures handle your code, the right questions to ask any vendor, a nuance about API gateways that often gets missed, and how to think about compliance frameworks in this context.

The concern is mainstream, not paranoid. In Cisco’s 2024 Data Privacy Benchmark Study — 2,600 security and privacy professionals across 12 countries — 27% of organizations said they had banned generative-AI tools outright over privacy and data-security risks, while 48% admitted staff had entered non-public company information into them. Source code is some of the most sensitive non-public information a company holds, which is exactly why where your diff travels during review is worth understanding before you adopt a tool.

Key Takeaways

• Hosted SaaS tools route your diff through the vendor’s own infrastructure before it reaches an LLM.
• BYOK tools send the diff to whatever endpoint you configure — but “BYOK” alone doesn’t guarantee your code stays in your infrastructure if you route through a third-party gateway.
• Self-hosting a local model endpoint is the only way to keep code entirely within your own infrastructure.
• The right questions cover storage, retention, training use, processing location, and subprocessors.
• Compliance (SOC 2, GDPR, HIPAA) depends on the full vendor, contractual, and operational picture — not a single configuration setting.

Where Does Your Code Actually Go?

The answer depends entirely on the tool’s architecture. At a high level, there are three patterns.

Hosted SaaS. Tools like CodeRabbit and Greptile operate as platforms. You install a GitHub App or connect your repo, and the vendor’s service receives the pull request event, fetches the diff, and sends it to an LLM (often OpenAI or Anthropic) on your behalf. Your code touches the vendor’s servers before it ever reaches a model. The vendor controls the infrastructure, the API keys, and the data handling policies. This is the most convenient setup and covers most teams just fine. But the diff does travel through a third party’s environment.

BYOK (bring your own key). Tools in this category — including open-source options like Robin and PR-Agent — run as GitHub Actions workflows inside your own repository. You supply an API key. The tool sends the diff directly to the endpoint you configure. The vendor has no server in the middle receiving your code. What the tool does is take the diff, compose a prompt, and call the API URL you pointed it at.

Self-hosted local model. A variation of BYOK: instead of sending your diff to an external API, you configure the tool to call a local model endpoint (Ollama, vLLM, or a similar runtime) running on your own hardware or private cloud. In this case, the diff never leaves your infrastructure at all.

The Gateway Nuance: Why “BYOK” Isn’t Always the Full Story

This is a detail that’s easy to miss. If you use a BYOK tool and point it at a routing gateway like OpenRouter, your diff goes to OpenRouter’s servers before reaching the underlying model provider. OpenRouter forwards the request to whoever runs that model. So your code passes through at least two parties: OpenRouter and the model provider.

That’s not necessarily a problem. OpenRouter has its own data handling policies, and most underlying providers (Mistral, Meta’s hosted endpoints, Anthropic, OpenAI) have enterprise agreements available with stronger data protections. But it does mean the flow is:

Your repo - GitHub Actions - OpenRouter - Model provider

Not: Your repo - GitHub Actions - Model provider directly.

If you point your BYOK tool directly at the OpenAI API, Anthropic’s API, or a model provider’s endpoint with no gateway in between, OpenRouter is out of the picture. If you point it at a self-hosted endpoint, only your infrastructure is involved.

The practical takeaway: “BYOK” tells you the tool vendor has no infrastructure receiving your code. It doesn’t tell you where your API key’s endpoint is. Those are two separate questions.

The Right Questions to Ask Any Vendor

Regardless of whether you’re evaluating a SaaS tool or an LLM API provider, the questions that matter are roughly the same.

Is my code stored, and if so, for how long? Some services store diffs or prompts temporarily for debugging or quality purposes. Others process and discard. Retention windows vary. Ask for specifics, not just a “yes/no”.

Is my code used to train models? Most major LLM providers offer a way to opt out of training data use, often through enterprise agreements or specific API plans. The default behavior on consumer-grade API tiers is often different from the enterprise tier. Check which tier your key is on.

Where is my code processed? For GDPR purposes, whether processing happens in the EU or outside it matters. For US federal or healthcare contexts, region and cloud provider may be governed by contract. Ask which cloud regions and which subprocessors are involved.

Who are the subprocessors? A SaaS vendor almost certainly sends your code to an LLM provider downstream. That provider is a subprocessor. GDPR-compliant vendors publish a subprocessor list. Ask for it. If the vendor can’t tell you who processes your data downstream, that’s a signal.

Is there a DPA available? A Data Processing Agreement is a contractual document that governs how a processor handles personal data on your behalf. Many vendors offer one on request, especially for business or enterprise plans. It’s the mechanism through which GDPR Article 28 obligations flow.

For a more detailed look at how different tools stack up on these dimensions, the tools comparison page covers several popular options side by side.

The Strict-Control Option: Keep Code in Your Own Infrastructure

If your team’s security policy requires that source code never leave your own environment, achieving that takes two pieces: a self-hosted model endpoint and a self-hosted CI runner. The workflow looks like this:

1. Run a local model server (Ollama with a capable open-weight model, or vLLM on your own GPU cluster) inside your private network.
2. Run the CI job on a self-hosted GitHub Actions runner inside that same network. (On a GitHub-hosted runner, the diff is checked out on GitHub’s infrastructure first — so for true network isolation the runner must be yours too.)
3. Configure your BYOK reviewer to call the local model endpoint rather than an external API URL.
4. The Action composes the prompt and sends the HTTP request to your internal endpoint.

With both pieces self-hosted, no external model API call is made and the diff stays inside your network boundary. The trade-off is operational: you’re responsible for the model, its hardware, its updates, and its performance. Capable open-weight models exist for code tasks, but running them well requires a non-trivial infrastructure commitment.

For teams that want direct control without building full model infrastructure, the middle path is a BYOK tool pointed directly at a major provider’s enterprise API, with a signed DPA, data residency guarantees, and training opt-out in place. That’s not “code stays in your infra,” but it may satisfy compliance requirements depending on the framework and your legal team’s read.

For setup guidance on the BYOK path, the Robin documentation walks through configuring a custom endpoint, including pointing at a local model.

How This Maps to SOC 2, GDPR, and HIPAA

A few honest caveats before this section: compliance is a legal and operational question, not a technical one you can solve with a single configuration choice. The framing here is meant to give you a starting map, not a compliance checklist.

SOC 2. SOC 2 Type II reports tell you that a vendor has controls in place and that an auditor verified those controls over a period. If a SaaS code review vendor has a SOC 2 report, it means their internal processes met the audit standard. It does not guarantee their subprocessors were also audited, or that your specific use case falls within the report’s scope. Ask to see the report and check the scope section.

GDPR. If any personal data could appear in your diffs (developer names in comments, email addresses in config files, anything that might identify a person), then the LLM API call involves personal data under GDPR. The vendor or API provider processing that data on your behalf needs to be a controller or processor with an appropriate legal basis and a signed DPA. Article 28 of GDPR specifically governs processor relationships. The model provider’s standard terms may not be sufficient without a DPA.

HIPAA. If protected health information could appear in code — common in healthcare software — you need a Business Associate Agreement (BAA) with every vendor that processes or stores that data. Most LLM API providers do not offer BAAs on standard plans. Some do at the enterprise tier. Running a self-hosted model is one way to avoid the BAA requirement entirely, since no PHI leaves your environment.

In all three cases, the configuration of your code review tool is one input. Your legal and security teams’ review of vendor contracts, subprocessor lists, and audit reports is the actual compliance work. No tool setting substitutes for that.

For a side-by-side comparison of how hosted and BYOK tools differ on data handling, the CodeRabbit comparison page covers several of these dimensions specifically.

One Open-Source Option Worth Knowing

For teams that want to see exactly what happens to their diff, open-source tools are worth considering because you can read the code. Robin is a free, MIT-licensed GitHub Action (github.com/antongulin/robin) that operates on the BYOK model. You configure an API key and endpoint; the action sends the diff there and nowhere else. Because it runs inside your GitHub Actions environment, the tool vendor has no server in the path. You can inspect every line of the workflow.

That’s one example. PR-Agent is another open-source option with a similar architecture. The common thread is that the code is auditable and the data path is transparent. Whether that satisfies your requirements depends on which endpoint you configure and what that provider’s policies look like.

In our experience maintaining Robin, the question that actually settles most privacy reviews isn’t “is the tool open source?” — it’s “what is the endpoint, and who runs it?” An open-source reviewer pointed at a consumer-tier API with no DPA can be a worse privacy outcome than a closed tool on an enterprise contract. Auditability gets you a transparent data path; the endpoint decision is what determines where the code actually ends up.

---

FAQ

Does AI code review store my source code?

It depends on the tool. Hosted SaaS tools typically route your diff through their own servers and then to an LLM provider — storage and retention policies vary by vendor. BYOK tools send your diff directly to the API endpoint you configure, so no tool vendor stores your code. Whether the LLM provider itself retains prompts depends on their plan terms and whether you have a DPA or enterprise agreement in place.

What is BYOK in AI code review, and does it mean my code is private?

BYOK means you supply your own API key and the tool sends requests to the endpoint you configure. The tool vendor has no server receiving your code. However, your code still reaches whoever operates that endpoint, whether that’s OpenAI, Anthropic, a gateway like OpenRouter, or a self-hosted model. “BYOK” removes the tool vendor from the data path; it doesn’t automatically keep code in your own infrastructure.

Can I use AI code review and stay GDPR-compliant?

Potentially yes, but it requires deliberate setup. You need a Data Processing Agreement with every party that processes personal data appearing in your diffs, including the LLM API provider. Major providers offer DPAs, often on business or enterprise plans. You also need to verify data residency if EU-only processing is required. Compliance depends on the full contractual and operational review, not the choice of tool alone. For a broader look at your options, the tools page lists tools alongside their data routing model.