Get started
How MergeHarbor uses AI and your code
Exactly what MergeHarbor sends to AI model providers, what it never sends, how long providers and MergeHarbor keep it, and the controls you have.
MergeHarbor reviews code with large language models. This page explains, feature by feature, what leaves MergeHarbor’s servers, which providers receive it, how long they and we keep it, and how you can limit it. It describes the hosted service at mergeharbor.com. A self-hosted installation sends data only to the providers you configure.
Provider terms change. The provider details below were checked against the providers’ own published pages on October 21, 2026 (Amazon Bedrock: October 30, 2026).
Summary
- Only the parts of your code a task needs are sent: the pull request diff and the files and snippets the reviewer reads to understand it, never a whole repository in one request.
- Secrets are removed first. Diffs, file contents, tool results, ticket text and comments pass through a secret scanner before they reach a review model.
- No one trains on your code. MergeHarbor does not train or fine-tune models on customer data, and the model providers we use do not train on API data under their commercial terms.
- Providers keep requests for a limited time for abuse monitoring, typically up to 30 days (details below).
- On the hosted service, MergeHarbor runs every model call on its own provider accounts. You never supply model API keys or pay a model provider. Self-hosted Enterprise installations can use their own provider accounts instead.
- You can choose the providers, restrict regions, exclude paths, turn features off, or self-host.
How a review flows
- Your code host sends MergeHarbor a webhook for a new or updated pull request.
- A worker updates its copy (mirror) of the repository on MergeHarbor’s servers in AWS Sydney (ap-southeast-2) and computes the diff.
- The secret scanner removes credentials from the diff, title and description. Files that match your
ignore_paths, lockfiles, vendored, generated and binary files are left out of the diff. - The review agent sends the diff, your rules and relevant context to the model chosen for that pull request. While it works, the model can ask for more context through read-only tools (read a file, search the code, find callers, read commit history, look up a linked ticket). Each tool result is also passed through the secret scanner before the model sees it. The agent can only read the repository and commit under review, using a short-lived signed token.
- Findings are verified (a second, usually smaller model call per finding), then posted to the pull request and stored in MergeHarbor.
What is sent to model providers
| Feature | Sent to the model |
|---|---|
| Pull request review | The diff (redacted); the pull request title, description and author username; repository name; the list of changed files; your rules and review instructions; relevant knowledge-base pages and context files you configured; and file contents, code search results and commit messages the reviewer requests through its tools (redacted). |
| Linked issues | When you connect Jira, Linear, Sentry or Notion, the text of issues linked to the pull request (title, description, acceptance criteria), the Confluence pages they link to, and Notion pages the pull request or its issues link to (redacted). |
| Finding verification | Each candidate finding with the code around it. |
| Questions about a pull request (chat) | Your question, the conversation thread, the review summary and findings, and the diff (all redacted), plus files the model reads through its tools. |
| Diagrams and review tour | The diff and title (redacted). |
| File summaries for search | An outline of each indexed file: its path, language and symbol signatures (function and type declarations, up to 150 lines), redacted. Function bodies are not included. |
| Generated docs | File paths and the file summaries above, plus module dependencies, and the messages of revert and hotfix commits (redacted). Not raw source. |
| Learning and rule suggestions | Review comments, replies and reactions from your team (redacted) and your existing rules. |
| Test writing and proof runs | The diff, relevant source and test files (redacted), and output of test runs. Tests run in an isolated sandbox on MergeHarbor’s servers, not at the model provider. |
Embeddings
To make code searchable by meaning, MergeHarbor indexes the repositories you enable and turns code chunks (a function, class or block, with its file path and symbol name), file summaries and search queries into embeddings (lists of numbers). Code chunks are embedded for files changed in the last year, the files they call or that call them, entry points and documentation, and any file a pull request changes; older files are searchable by name and text without being sent for embedding until a pull request touches them. On the hosted service this uses OpenAI’s text-embedding-3-small model. The embedding request contains the code chunk itself, passed through the same secret scanner as review traffic: detected secrets are replaced before the text leaves MergeHarbor. Files that commonly hold secrets (.env files, keys and certificates) are not indexed at all because they are not source files, and you can exclude any other path with .mergeharborignore (see Controls). Embeddings are used only for search inside your organization. Embeddings go through OpenAI’s real-time embeddings endpoint. Batch embedding, which sends first-time indexing through OpenAI’s Batch API at half the price, is off by default and is not used on the hosted service. If a self-hosted installation turns it on (EMBED_BATCH_MODE=auto), code chunks go through the Batch API: OpenAI keeps the uploaded request and result files until MergeHarbor deletes them when the batch ends, and the Batch API is not eligible for zero data retention.
What is not sent
- Secrets. Before review content reaches a model, and before code reaches the embedding provider, MergeHarbor removes private keys, cloud access keys (AWS, Google, Azure), code-host tokens (GitHub, GitLab), Slack, Stripe, Anthropic and OpenAI keys, JWTs, passwords in connection URLs, and high-entropy values assigned to names such as
password,secret,tokenorapi_key. Pattern-based detection cannot catch every secret, so keep secrets out of source control in the first place. Redaction is always on. Settings → Security → Policies shows how many secrets were removed from reviews in the last 30 days, by kind. - 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 sign-in credentials, code-host tokens, or API keys. These are encrypted at rest and never included in prompts.
- Ignored and excluded files in the diff. Files matching
ignore_paths, lockfiles, generated, vendored and binary files are not part of the diff sent to the model. The reviewer may open other files in the repository at the pull request’s head commit for context, but its tools (file reads, directory listings, grep, code search and symbol lookups, in reviews and chat) never return paths that matchignore_paths. Use.mergeharborignoreto keep paths out of search and indexing, and keep truly sensitive material in a separate repository that you do not connect.
Model providers and their data terms
On the hosted service, MergeHarbor routes each task to a model based on the pull request’s size and risk and your settings. The providers MergeHarbor may use are listed on the subprocessors page. Today these are Anthropic (the default for reviews), OpenAI (some routed tasks, and embeddings) and Amazon Web Services (see below). Organizations can restrict which providers, regions and model classes are allowed under Settings → Review behaviour → AI models & cost (see Review costs).
| Provider | Trains on API data? | Retention by the provider |
|---|---|---|
| Anthropic (Claude API) | No. Anthropic’s Commercial Terms state that “Anthropic may not train models on Customer Content from Services.” | Inputs and outputs are deleted within 30 days. Requests flagged for Usage Policy violations may be kept up to 2 years. Zero data retention is available to eligible organizations by agreement with Anthropic, but not for the Message Batches API (29-day retention) or for “Covered Models” (currently Claude Fable and Claude Mythos models), which require 30-day retention. Prompt caching holds data in memory only for the cache lifetime. |
| OpenAI (API) | No, unless the customer opts in. Data sent to the API is not used to train OpenAI models by default. | Abuse-monitoring logs up to 30 days. Zero data retention requires OpenAI’s approval; the embeddings endpoint is eligible, the Batch API is not. |
| Amazon Bedrock (open-weight models) | No. AWS does not use Bedrock prompts or outputs to improve the base models and does not share them with the model’s developer. | Zero data retention for MergeHarbor’s account in the Sydney region (set before use): nothing is written to durable storage. |
Work that can wait (file summaries, generated docs, rule suggestions) runs through Anthropic’s and OpenAI’s batch APIs on MergeHarbor’s accounts, which keep batch data for up to 29–30 days as noted above (open-weight models on Amazon Bedrock are called directly, not through a batch API). Code chunks for embeddings are not sent through a batch API unless batch embedding is turned on, which is off by default (see Embeddings).
Sources (checked October 21, 2026):
- Anthropic: Commercial Terms of Service; How long do you store my organization’s data? (updated July 1, 2026); API and data retention.
- OpenAI: Data controls in the OpenAI platform; Enterprise privacy.
Open-weight models on Amazon Bedrock
Some low-risk, high-volume tasks may be processed by open-weight models hosted on Amazon Bedrock in AWS Asia Pacific (Sydney), ap-southeast-2, the same AWS region that hosts MergeHarbor. These tasks are: the pre-review risk check, generated docs (knowledge-base module and repository pages), issue-triage classification and learning (rule) distillation. Pull request reviews and finding verification never use them. Each task is switched on separately by MergeHarbor; when a model on Bedrock cannot complete a request, that request is served by the usual model instead.
- No training, no sharing with the model’s developer. AWS states that with Amazon Bedrock “your data is not shared with model providers, and is not used to improve the base models”. Models run in AWS-owned model deployment accounts that the model developers cannot access, so they “don’t have access to Amazon Bedrock logs or to customer prompts and completions”.
- Retention. Before any task is switched on, MergeHarbor sets Amazon Bedrock’s data retention for its account in the Sydney region to zero retention, under which “no request or response data is written to durable storage by AWS or shared with the model provider”. Requests stay in the Sydney region (no cross-region inference).
- Your controls apply. Organizations that require US or EU model processing, or that do not allow Amazon Bedrock as a provider, never use these models.
Sources (checked October 30, 2026): Amazon Bedrock security and privacy; Data protection in Amazon Bedrock; Amazon Bedrock data retention; Amazon Bedrock abuse detection.
What MergeHarbor stores, and for how long
All hosted data is stored in AWS Asia Pacific (Sydney), encrypted at rest.
| Data | Where | How long |
|---|---|---|
| Repository mirror (a git clone of each enabled repository) | Worker disk | While the repository is enabled; least-recently-used mirrors are evicted when disk is full. |
| Search index: file paths, symbols, call graph, code chunks, embeddings, file summaries | PostgreSQL | While the repository is enabled. Deleting a repository queues a purge of its index. |
| Reviews, findings, comments, usage records, review archives | PostgreSQL and Amazon S3, encrypted | The retention period your administrators set under organization settings; kept until then if none is set. |
| Generated docs, rules, knowledge-base pages, learned preferences | PostgreSQL | Until you delete them or the organization. |
| Audit log | PostgreSQL | For the life of the organization, or the period agreed in your contract. |
| Embedding cache (vectors keyed by a hash of the embedded text) | PostgreSQL | 30 days. |
| Connector cache: ticket, page and document text, and documents read for issue triage | PostgreSQL | Reused for 10 minutes; deleted within 24 hours. If you turn on Keep linked documents in the knowledge base: the days you choose (1–365) after last use, deleted at once when turned off. |
| Organization exports | Amazon S3, encrypted | 7 days; download links expire after 15 minutes. |
| Database backups | Amazon S3, encrypted | Expire within 40 days. |
Deleting a repository in MergeHarbor removes it from reviews and queues a purge of its mirror, index data, embeddings, review archives and stored test-run artifacts. Deleting your organization starts a 7-day grace period (you can restore it within that time); after that all organization data is purged, and backup copies expire within 40 days. After your agreement ends, data is deleted as described in the DPA section 9. Uninstalling the GitHub App stops access and reviews, hides the installation’s repositories immediately, and deletes their data after a 7-day grace period (reinstalling within that period restores them; suspending the app deletes nothing). Removing a connection in the console (any code host) does the same: its repositories are hidden at once and deleted after 7 days unless you reconnect the same code host first. GitLab, Bitbucket and Azure DevOps send no uninstall event, so revoking MergeHarbor’s token on the host alone stops reviews but deletes nothing; remove the connection in the console as well.
Your controls
| Control | Where |
|---|---|
| Restrict providers, model classes and region (US, EU) | Settings → Review behaviour → AI models & cost. Requests are routed only to providers, classes and regions you allow, including during provider outages. |
| Exclude paths from review diffs | ignore_paths in .mergeharbor.yml or a folder’s .mergeharbor/config.yml (repository configuration). |
| Exclude paths from indexing and embeddings | A .mergeharborignore file at the repository root (gitignore-style patterns). |
| Choose which repositories are connected | Enable only the repositories you want reviewed; repositories that are not enabled are not indexed. |
| Turn features off | Generated docs, learning, test writing and integrations (Jira, Linear, Sentry, Notion) can each be turned off or left unconnected. |
| Retention | Set a retention period for review data in organization settings; export or delete the organization at any time. |
| Keep everything in your environment | Self-hosting runs MergeHarbor, including embeddings, entirely in your infrastructure with the model providers you choose. |
Questions about AI and data handling: privacy@mergeharbor.com. Security questions: security@mergeharbor.com.