Data-processing terms

These terms apply when MergeReady processes personal data in a customer's repositories on the customer's behalf. They form part of the terms of service. The customer is the controller of that data and MergeReady, [To be supplied by the owner: the legal name of the company that provides MergeReady], is its processor.

1. What is processed

• Subject matter and purpose: owning the customer's pull requests from open to mergeable, as the customer's policy allows.
• Data: pull-request metadata (titles, descriptions, authors, reviewers, file paths), diffs and the files the agents read, CI logs, review threads and comments, CODEOWNERS and workflow files, and what MergeReady writes back.
• People: the customer's contributors, reviewers and anyone whose name, login or words appear in those.
• Nature: reading through the code host's API, running the customer's setup and tests in a sandbox, model calls, storing what is listed in section 4, and writing to the pull request as the policy allows.

2. Instructions

MergeReady processes the data only to provide the service, on the customer's instructions. The customer's policy and settings in MergeReady, and the GitHub App's installation, are those instructions. Recordings of the customer's pull requests enter MergeReady's test corpus only with the customer's separate written agreement; until it is recorded, MergeReady refuses to make them.

3. Confidentiality

Only people who need access to run the service have it, and they are bound to keep the data confidential.

4. What is kept, and for how long

Data	Kept
Raw CI logs	30 days
The code host's events, as MergeReady records them	30 days in full, then cut down to a few facts, with no person's name or words
Run text: agent outputs, tool-call arguments, a finished run's step results and its workflow snapshot	90 days, then removed
Verified patches	90 days
Caches of CI results	30 days
Evidence-pack revisions, transitions, attempts and refusals; the nightly numbers; review bots' findings (facts only); pull requests' titles, authors and file paths; learned conventions and flaky-test history	for the life of the organization's data
The audit log of every write and refusal	for the life of the organization's data
A repository's sandbox template	until the repository leaves the installation (it is removed the following night) or the organization's data is erased
The service's logs and error reports, which can name the organization, the repository and the pull request, and for an organization without zero data retention carry an error's message	30 days, also after the organization's data is erased

Prompts are never stored, only a hash of each. Everything stored in the object store (CI logs, pack text, verified patches) is encrypted under a key of the organization's own. An agent's output, a tool's arguments and an audit entry's details are scanned for secrets before they are stored. The nightly retention run removes what has passed its period.

Zero data retention. An owner can turn it on for the organization. While it is on, no prompt or trace text is kept; agent outputs, tool-call arguments, step results, workflow snapshots and the payloads of processed events are removed at the next nightly run; every stored object except verified patches is removed at the next nightly run; and agents keep no memory between runs. It covers what MergeReady stores, not what a model provider retains of a call: no model provider is set up for zero data retention.

5. Deletion

An owner can delete the organization in MergeReady, on the Access page. That erases every row of the organization, its objects and its sandbox templates, and keeps only a record that the erasure happened: who asked, when and how much was removed. The service's host is backed up as a snapshot of its whole disk every 4 hours, and the 42 newest snapshots are kept, so erased data remains in those snapshots for at most 7 days after the erasure. The service's logs and error reports are not part of the erasure: they are kept for the period section 4 gives them. Uninstalling the GitHub App stops MergeReady and keeps what it stored until its period in section 4 ends.

6. Security measures

• Each organization's rows are separated from every other's by row-level security in the database.
• Stored objects are encrypted (AES-256-GCM) under a key of the organization's own, which the service's key vault seals.
• Credentials the customer gives MergeReady are sealed, bound to the organization and their purpose, and never shown again or sent to a sandbox.
• MergeReady's servers never clone the repository. Tests run in a sandbox that holds no GitHub token, no model key and no MergeReady credential, whose network is denied except through MergeReady's proxy, and which is never shared between pull requests.
• Every write and refusal is in the organization's audit log, which owners can export.

7. Sub-processors

The customer authorises the sub-processors below. This list is updated, as a new version of these terms, before a new sub-processor receives the customer's data. The customer's code host and CI system are the customer's own, not MergeReady's sub-processors.

Sub-processor	Used for	Data it receives	Region
Amazon Web Services	Hosts the service: the server, the proxy, Postgres, Inngest and the stored objects on one host, the snapshots of its disk, the deployment's secrets, its health checks and alerts, and the service's logs and error reports	Everything the service stores	United States (us-east-1)
Amazon SES	Account mail (verification, password reset, invitations) and the waitlist's one confirmation	The recipient's address and the message	United States (us-east-1)
Anthropic	Model calls: triage and CI-log summaries on every pull request, reconciling trusted review bots' findings, and, from Propose, diagnosis, fixes, review handling, merge-conflict resolution and the check of proposed tests	PR metadata, distilled CI logs, and the diffs and files the agents read	United States
OpenAI	From Propose, the independent check of each change before it is pushed or proposed. On MergeReady's own model keys, also the calls of triage and of reconciling review bots' findings that Anthropic cannot answer, for each of those agents the service's outage settings move to another provider	For the check, the change and its plan; for a call moved from Anthropic, what that agent reads: for triage, the pull request's metadata, its diff and the text of its linked issues	United States
Google	From Propose, the independent check of a change when OpenAI cannot answer it. On MergeReady's own model keys, also the calls of diagnosis, fixes, review handling, merge-conflict resolution and the check of proposed tests that Anthropic cannot answer, for each of those agents the service's outage settings move to another provider	For the check, the change and its plan; for a call moved from Anthropic, what that agent reads: distilled CI logs, the diff, the files it reads and the review comments it handles	Per Google's region
OpenAI (embeddings)	Semantic recall over the agents' stored messages, only when the service turns it on (it is off)	The text of the agents' messages; never for an organization with zero data retention	United States
Boat	Sandboxes, when the service runs them on Boat: one virtual machine per pull-request session, which runs your setup and tests, and a saved template per repository	A checkout of the pull request's head and the commands run in it; no GitHub token and no model key	EU
Boat's AI-credentials proxy	Only for a repository whose policy runs a coding agent inside the sandbox: that agent reaches its model through Boat's proxy	That agent's prompts and completions	EU (Boat), then the model provider's region
GitHub	The MergeReady GitHub App, which reads and writes your repositories as your policy allows, and GitHub sign-in	What MergeReady writes back (the evidence pack, the check, labels, replies and, at Act, commits); GitHub already holds the repository	Per GitHub
Slack	Questions and answers, only when your organization connects a workspace	Question text, pull-request titles and links	Per workspace
Linear	Comments on linked issues, only when your organization connects it	Short status lines and links	United States

When an organization stores its own Anthropic key, the calls of its agents that work in the repository (triage, diagnosis, fixes, merge-conflict resolution, reconciling review bots' findings, writing the evidence pack and choosing reviewers), the screen for prompt injection that reads those agents' input before they do, the summary of a CI log no parser recognised (a bounded, redacted excerpt) and the learning of its conventions go to Anthropic under that key and the customer's own agreement with Anthropic. Two kinds of call are made without the organization's account and still go to Anthropic under MergeReady's own key and MergeReady's agreement with Anthropic, with the screen of their input: reading a review comment for review handling (the thread, the diff around it and the pull request's title), and the check of proposed tests and fixes against the pull request's stated intent (its title, description and linked issues, and two outputs of its code). A call Anthropic cannot answer is never moved to another provider, on either key. The independent check of each change uses MergeReady's own keys with OpenAI and Google either way.

8. Assistance, breaches and audits

• MergeReady helps the customer answer requests from the people whose data it is, as far as the service holds that data.
• MergeReady tells the customer without undue delay after it becomes aware of a breach of the customer's data, with what it knows.
• On request, MergeReady gives the customer the information needed to show that these terms are kept. MergeReady holds no third-party certification.