Source code is usually the most sensitive asset an engineering organization has, and an AI code reviewer needs to read it to be useful. The security review for one is therefore not a formality. The questions are concrete: what leaves your network, who receives it, how long they keep it, whether anyone trains on it, and what you can switch off.
This guide answers those questions for MergeHarbor, with links to the documentation that states each answer precisely, and ends with a checklist you can use for any AI reviewer. The authoritative, feature-by-feature reference is How MergeHarbor uses AI and your code. Where this guide summarises, that page wins.
The data flow of one review
It helps to follow one pull request. On the hosted service:
- Your code host sends a webhook for a new or updated pull request.
- A worker updates its mirror of the repository on MergeHarbor’s servers in AWS Asia Pacific (Sydney) and computes the diff.
- A secret scanner removes credentials from the diff, title and description. Ignored paths, lockfiles, and vendored, generated and binary files are left out.
- The review agent sends the diff, your rules and relevant context to the model chosen for that pull request. The model can ask for more through read-only tools (read a file, search the code, find callers, read history, look up a linked ticket). Each tool result goes through the secret scanner too. The agent can only read the repository and commit under review, using a short-lived signed token.
- Findings are verified by a second model call per finding, then posted to the pull request and stored.
The mechanics of each stage are in How AI code review works, step by step. From a security point of view, the important properties are that the model sees only what a task needs, everything passes through redaction first, and access is scoped to one repository and commit.
What is sent to model providers
For a pull request review, the model receives the redacted diff; the pull request title, description and author username; the repository name and list of changed files; your rules and review instructions; relevant knowledge-base pages and context files you configured; and the file contents, search results and commit messages the reviewer requests through its tools, also redacted.
Other features send other things. Linked issues from Jira, Linear, Sentry or Notion send the linked issue text. File summaries for search send an outline of each file (path, language and symbol signatures, not function bodies). Embeddings for search by meaning send code chunks, after the same secret scanning as review traffic. The full table lists every feature.
What is never sent
- Secrets, as far as pattern detection can find them. Private keys, cloud access keys, code-host tokens, common API keys, JWTs, passwords in connection URLs and high-entropy values assigned to names such as
password,secret,tokenorapi_keyare removed. Redaction is always on, and Settings → Security → Policies shows how many secrets were removed in the last 30 days. Pattern-based detection cannot catch every secret, so the documentation is explicit that secrets should stay out of source control in the first place. - Whole repositories in one request. Models see the diff and the specific files and snippets they ask for, limited to 800 lines per file read and about 12,000 characters per tool result.
- Other organizations’ data. Each request is scoped to one repository and one commit by a signed token.
- Your credentials. Sign-in credentials, code-host tokens and API keys are encrypted at rest and never included in prompts.
- Ignored files. Paths matching
ignore_pathsare not in the diff, and the reviewer’s tools never return them.
Training: who learns from your code
This is usually the first question, and the answer has three parts:
- No model training on customer code. In the documentation’s words: “MergeHarbor does not train or fine-tune any model, its own or a provider’s, on customer code, pull request content or review results.”
- Providers do not train on API data. The providers MergeHarbor uses do not train on API data under their commercial terms. The AI data page quotes each provider’s terms and links the sources, with the date they were checked.
- What MergeHarbor learns from your team stays with your organization. Rules, suppressed comment types and preferences come from your own pull requests and feedback and are never used for another customer. The only cross-customer signal is numeric: how useful each model’s reviews were, counted per model, task, language and change size, with no code, text, file or repository names.
Retention: who keeps what, and for how long
Model providers keep requests for a limited time for abuse monitoring, typically up to 30 days. The exact terms differ by provider and by API (batch interfaces, for example, keep data longer than real-time ones), and some low-risk tasks run on open-weight models on Amazon Bedrock with zero data retention set for MergeHarbor’s account. Read the provider table rather than a summary when you do your review.
MergeHarbor stores hosted data in AWS Asia Pacific (Sydney), encrypted at rest. Repository mirrors and search indexes are kept while a repository is enabled. Reviews and findings are kept for the retention period your administrators set. Database backups expire within 40 days. Deleting a repository queues a purge of its mirror, index, embeddings and review archives; deleting the organization starts a 7-day grace period, after which everything is purged.
One detail worth knowing: GitLab, Bitbucket and Azure DevOps send no uninstall event, so revoking MergeHarbor’s token on the host stops reviews but deletes nothing. Remove the connection in the console as well.
Controls you have
| Control | Where |
|---|---|
| Restrict providers and model classes | Settings → Review behaviour → AI models & cost |
| Keep inference in the US or the EU | Same page; US or EU inference regions are part of the Enterprise plan |
| Keep paths out of the review diff | ignore_paths in .mergeharbor.yml or a folder’s .mergeharbor/config.yml |
| Keep paths out of indexing and embeddings | .mergeharborignore at the repository root |
| Choose what is connected | Only enabled repositories are indexed; connectors are optional |
| Turn features off | Generated docs, learning, test writing and integrations can each be off |
| Retention | Set a retention period for review data; export or delete the organization at any time |
Provider restrictions hold during outages too: when a provider is down, MergeHarbor falls back only to providers your organization allows, and residency settings still apply. For truly sensitive material, the documentation’s advice is simple: keep it in a separate repository that you do not connect.
Access to your organization
The controls around who can see review data matter as much as the model path:
- Single sign-on and SCIM. SAML 2.0 or OpenID Connect, enforced per organization, with verified domains, group-to-role mapping, SCIM 2.0 provisioning and up to five break-glass owners. These are part of the Enterprise plan and self-hosted deployments. See Single sign-on and SCIM.
- Roles. Owner, admin, member and viewer roles, with custom roles built from granular permissions on Enterprise.
- Audit log. Append-only and hash-chained per organization, so modified, deleted or reordered records are detectable, with CSV and JSONL export and streaming to your SIEM on Enterprise.
- Support access. In MergeHarbor cloud, support access is a time-limited session, read-only by default, that an owner of your organization approves and can revoke, and every action is in your audit log.
- Encryption. TLS 1.2 or later in transit. Code-host tokens, identity-provider secrets and connector tokens are encrypted at rest with AES-256-GCM and rotatable keys.
The Security and trust page covers isolation, encryption and disclosure in more detail, and AI code review for enterprises covers the identity and governance side.
When the hosted service is not an option
Some organizations cannot send source code to any third party, or need it to stay in a specific country or network. For them, the answer is to run the reviewer themselves.
Self-hosted MergeHarbor runs the console, API, workers, review agent and database in your environment, on Kubernetes with Helm, on a single VM with Docker Compose, or on AWS with Terraform. Reviews call only the model providers you configure: the Anthropic API, Amazon Bedrock, or your own OpenAI-compatible server such as vLLM, Ollama or TGI. Embeddings can run in your cluster too.
For networks with no internet access, an air-gapped install loads checksummed, signed images from a bundle, checks the license offline, and with AIR_GAPPED=true refuses every public address for outbound connections. The review agent then refuses to start if a model endpoint resolves to a public address. Open-weight models served by vLLM or Ollama are the tested air-gapped setup. Self-hosted MergeHarbor sends no telemetry and makes no update checks, in any mode. Self-hosting is part of the Enterprise plan.
Compliance status, stated plainly
MergeHarbor is built around controls aligned with SOC 2 and GDPR requirements: access control, audit logging, encryption, retention and vendor data-processing terms. MergeHarbor does not yet have a SOC 2 report; readiness work is under way and a Type I audit is planned. A data processing addendum and the subprocessor list are published.
If your procurement process requires a vendor SOC 2 report today, say so early. Self-hosting is one option to discuss, because it keeps code and review data inside your own controls. Separately, MergeHarbor’s compliance evidence feature produces change-management records for your own audits; that is a product feature, not a certification of MergeHarbor.
Questions to ask any AI code review vendor
Use these in your security review, whichever tool you are evaluating:
- Exactly which data is sent to model providers for each feature, and is it documented per feature?
- Is a whole repository ever sent in one request, and what limits apply to what the model can read?
- Are secrets removed before code reaches a model or an embedding provider, including from tool results?
- Does the vendor, or any provider it uses, train or fine-tune on our code or review results? Where is that written?
- Which providers and regions are used, and can we restrict them? Do the restrictions hold during provider outages?
- How long does each provider keep requests, and how long does the vendor keep mirrors, indexes, reviews and backups?
- What happens to our data when we disconnect a repository or leave?
- Can vendor staff access our data, and is that access approved by us and logged?
- Is there SSO, SCIM, role-based access and a tamper-evident audit log?
- Can we self-host, including air-gapped, with our own models? Does the self-hosted product phone home?
- Which audits and reports exist today, and which are planned? Ask for dates, not intentions.
A vendor that answers each of these with a link to documentation is easier to approve than one that answers with a sales call.
Try it, or review the details first
If your review allows a hosted trial, start a 14-day trial of the Team plan, with no card required, on a few non-sensitive repositories. If it does not, contact us about an evaluation license for a self-hosted installation.
Further reading
- How MergeHarbor uses AI and your code: the full reference
- Security and trust
- Self-hosting and Air-gapped install
- Code host permissions: what MergeHarbor requests on each host, and how to revoke it
- AI code review for enterprises