---
title: "Data Processing Agreement"
description: "This Data Processing Agreement sets out how Caveman Labs, Inc. processes personal data on your behalf in Caveman Cloud: the GDPR Article 28 terms, the EU Standard Contractual Clauses, the UK and Swiss"
canonical: https://caveman.so/legal/dpa
last-updated: 2026-10-07
status: "draft, not yet in effect"
version: "2026-10-06"
publisher: "Caveman Labs, Inc."
contact: "contact@caveman.so"
---

# Data Processing Agreement

This Data Processing Agreement sets out how Caveman Labs, Inc. processes personal data on your behalf in Caveman Cloud: the GDPR Article 28 terms, the EU Standard Contractual Clauses, the UK and Swiss transfer terms, US state privacy law terms, our security measures and our sub-processors. It forms part of the Terms of Service.

## Summary

This summary is for convenience only. The full text below governs.

- This Data Processing Agreement ("DPA") forms part of the [Terms of Service](/terms). Accepting the Terms accepts this DPA. For a countersigned copy, write to [contact@caveman.so](mailto:contact@caveman.so).
- It covers personal data Caveman Labs, Inc. processes on your behalf in Caveman Cloud, only on your instructions. You are the controller (or a processor for your own customer); we are your processor.
- Model Providers you reach with your own API keys or accounts are not our sub-processors. For account data, billing, security logs and Product Data Sharing, we are an independent controller under our [Privacy Policy](/privacy).
- We keep Customer Data, including redacted and encrypted Payloads, until you delete it, on every plan. You can set a deletion window, and on paid plans turn payload storage off. Replay of stored Payloads to your Model Providers is on by default for each project, and you can turn it off.
- Product Data Sharing is a condition of the Free plan, off by default for new Pay-as-you-go Workspaces (Workspaces moved from the former Indie or Team plans kept their earlier setting) and never on Enterprise.
- We give 30 days' notice of [sub-processor](/legal/subprocessors) changes, and you can object. We report personal data breaches without undue delay. You can export your data during the term and for 30 days after it ends; we delete it within 30 days after that.
- Caveman Labs, Inc. is a US company. The EU Standard Contractual Clauses, the UK Addendum and Swiss adaptations cover transfers. We hold no security certification today; Annex II lists the measures we operate.

## 1. How this DPA applies

### 1.1 Part of the Agreement

This DPA is between Caveman Labs, Inc. ("Caveman", "we", "us") and the customer that has accepted the Terms of Service or signed an Order Form ("Customer", "you"). It forms part of the Terms and of any Order Form that incorporates it. By accepting the Terms, Customer accepts this DPA, and the person accepting confirms they have authority to bind Customer. If Customer's affiliates use the Services under Customer's account, Customer accepts on their behalf and remains Caveman's single point of contact.

### 1.2 Signed copies

This DPA applies without a signature. For a countersigned copy, write to [contact@caveman.so](mailto:contact@caveman.so). It will match the version published here on the date of signature, unless the parties agree changes in writing.

### 1.3 Scope

This DPA applies to Customer Personal Data that Caveman processes on Customer's behalf in providing the Services. It does not apply to the Open-Source Tools or the Website, or to data for which Caveman is an independent controller (section 3.4). A dedicated deployment of Caveman Cloud in Customer's own cloud account, or a self-hosted deployment, is governed by Customer's separate written agreement for that deployment, which sets out what, if anything, Caveman can access. A self-hosted deployment sends Caveman no Customer Data; if Customer sends Caveman personal data from one, for example in a support request, that agreement governs.

## 2. Definitions

Capitalised terms not defined here have the meaning given in the Terms. "Controller", "processor", "data subject", "personal data", "personal data breach", "processing" and "supervisory authority" have their GDPR meanings, and equivalent terms in other Data Protection Laws (such as "service provider", "personal information", "sell" and "share" under the CCPA) are read accordingly.

- **Agreement**: the Terms, any Order Form and this DPA.
- **CCPA**: the California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020, and its regulations.
- **Customer Data**: has the meaning given in the Terms.
- **Customer Personal Data**: personal data within Customer Data that Caveman processes on Customer's behalf as a processor or sub-processor.
- **Data governance**: the dashboard settings page for retention, payload storage, Product Data Sharing and deletion.
- **Data Protection Laws**: all data protection and privacy laws that apply to the processing of Customer Personal Data under the Agreement, including, where applicable, the GDPR, the UK GDPR, the Swiss FADP and US State Privacy Laws.
- **GDPR**: Regulation (EU) 2016/679, the General Data Protection Regulation.
- **Model Provider**: a third-party provider of AI models that Customer reaches through the Services using its own API keys or accounts ("bring your own key", or BYOK).
- **Order Form**: an ordering document for the Services agreed between Customer and Caveman.
- **Payloads**: the bodies of requests sent through the gateway and of the responses returned, and content imported from Customer's own traces and logs.
- **Product Data Sharing**: the setting under which Payloads and Usage Metadata may be used to improve Caveman's own models. It is a condition of the Free plan, off by default for new Workspaces on Pay-as-you-go, and never available on Enterprise or on a dedicated or self-hosted deployment.
- **Replay**: the feature that sends a project's redacted stored Payloads to Customer's Model Providers, on Customer's stored keys, to compare models, build and test changes, and judge results.
- **Restricted Transfer**: a transfer of Customer Personal Data (including remote access) subject to the GDPR, the UK GDPR or the Swiss FADP, to a recipient in a country those laws do not recognise as adequate for that transfer.
- **SCCs**: the standard contractual clauses for the transfer of personal data to third countries annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.
- **Services**: hosted Caveman Cloud: the gateway (api.caveman.so), the dashboard (app.caveman.so) and the control API.
- **Sub-processor**: a third party Caveman engages to process Customer Personal Data on its behalf. Model Providers, services Customer connects and Caveman's employees are not Sub-processors.
- **Swiss FADP**: the Swiss Federal Act on Data Protection of 25 September 2020 and its ordinances.
- **UK Addendum**: the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses (version B1.0) issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018, as revised.
- **UK GDPR**: the GDPR as it forms part of the law of the United Kingdom under the European Union (Withdrawal) Act 2018, read with the Data Protection Act 2018.
- **Usage Metadata**: data that describes each request, such as model, provider, token counts, cost, latency, status, salted hashes of Payloads, tags, the member user ID, a hashed client user ID, the session ID and any routing decision.
- **US State Privacy Laws**: the CCPA and the comprehensive consumer privacy laws of other US states, to the extent they apply.
- **Workspace**: a customer organisation in Caveman Cloud.

## 3. Roles of the parties

### 3.1 Customer's role

Customer is the controller of Customer Personal Data, or a processor where it processes that data on behalf of its own customer.

### 3.2 Caveman as processor

Caveman is Customer's processor where Customer is a controller, and a sub-processor where Customer is a processor. In that case Customer confirms that the relevant controller has authorised its instructions, including Caveman's appointment, and Customer remains Caveman's only point of contact unless Data Protection Laws require otherwise.

### 3.3 Service provider

For US State Privacy Laws, Caveman is Customer's "service provider", or "processor" where the relevant law uses that term, for Customer Personal Data. Section 16 sets out the related terms.

### 3.4 Independent controller

Caveman acts as an independent controller, outside the processor scope of this DPA, for:

- (a) account data about Customer's users, such as name, email address, authentication material, role, Workspace membership, session records (including IP address and user agent) and sign-up checks;
- (b) billing data, such as billing contact, plan and billable usage;
- (c) security and audit logs, and load balancer and edge logs;
- (d) support communications; and
- (e) Payloads and Usage Metadata used under Product Data Sharing, where it applies.

Caveman processes that data under its [Privacy Policy](/privacy) and Data Protection Laws.

### 3.5 Product Data Sharing

Product Data Sharing is a condition of the Free plan, which Customer agrees to on a separate screen at sign-up. On Pay-as-you-go it is off by default for new Workspaces and applies if a Workspace admin turns it on in Data governance. Workspaces moved from the former Indie or Team plans kept their earlier setting, which may be on, until a Workspace admin turns it off. It never applies on Enterprise or on a dedicated or self-hosted deployment, and cannot be turned on there.

Where it applies, it covers what reaches the Services from the Workspace, including recorded requests with their Payloads. On Free, for projects that opt in to router learning, it also covers sampled routing-request text. Caveman uses that data to improve its own routing, compression, caching and optimisation models and evaluations. Caveman starts using data for this purpose only once its own legal review of that use is complete; until then, the data is collected and kept as Customer Data only. Caveman never sells this data, never shares it with other customers and never uses it to train a third party's general-purpose model. Where the redaction pipeline applies, Payloads are redacted before they are stored.

Turning Product Data Sharing off stops new collection for that purpose and deletes the stored copies kept only for it. Training sets already built from that data are not rebuilt with it and are deleted when they expire, at most 365 days after they were built. Copies the Workspace keeps for its own use, under its payload setting, stay until Customer deletes them. On the Free plan it stays on while the Workspace is on Free; to stop it, move to Pay-as-you-go, or stop using the Workspace. A Workspace that moves from Free to Pay-as-you-go stops sharing from that moment. A Workspace that returns to Free after a failed payment keeps its existing setting, and sharing turns back on only if an Owner or Admin turns it on. Deleting Workspace data in Data governance also deletes data held under Product Data Sharing, including from training sets. Improvements already made to models, and aggregated or de-identified data, cannot be undone.

Caveman keeps data used under Product Data Sharing while sharing applies to it, unless Customer deletes it first, and never longer than the Workspace's retention window. Training sets built from it are rebuilt from the kept data, and each expires after 365 days. If an individual objects to this use under GDPR Article 21, Caveman honours the objection, whatever the plan, by excluding from Product Data Sharing the data it can link to that person (email address, member ID or client user ID).

Customer must have the right to share this data, including by giving any notices and obtaining any consents Data Protection Laws require. Customer must not send special categories of personal data, criminal-offence data or children's personal data through a Workspace where Product Data Sharing applies (always the case on Free).

### 3.6 Model Providers and connected services

The Services forward requests to the Model Providers Customer chooses, using Customer's own API keys or accounts, under Customer's own agreement with each provider. Customer can pass a key with each request or store it in the Services, encrypted as Annex II describes. If Customer connects Amazon Bedrock on hosted Caveman Cloud, Customer gives Caveman a Bedrock API key or AWS access keys, which the Services store encrypted like other stored keys, and those requests run in, and are billed to, Customer's AWS account. Hosted Caveman Cloud does not assume a role in Customer's AWS account. Model Providers are Customer's own processors or independent controllers, not Caveman's Sub-processors. Caveman does not contract with them on Customer's behalf and does not resell their tokens. Caveman's role on that leg is to transmit each request, on Customer's instruction, to the endpoint Customer's configuration points to, and return the response. Customer's agreement with the Model Provider governs what the provider does with the data, including where it processes it and whether it retains or trains on it.

The same applies to AI features in the Services, such as Ask, briefs, judges, model comparisons and agent runs, which on the hosted Services run on Customer's own provider keys, and to Replay.

Replay is on by default for each project, on every plan. With Replay on, the Services may, on their own initiative, send a project's redacted stored Payloads to Customer's Model Providers on Customer's stored keys, to compare models, build and test changes, and judge results. A Workspace admin can turn Replay off for each project, and `x-cave-retention: zdr` excludes a request from it. If Customer connects a repository, Caveman's agents may copy its code and history, read the Workspace's recorded traffic, write tests and open pull requests. They run in isolated sandboxes and call Model Providers with Customer's keys.

By configuring a provider key for an AI feature, leaving Replay on for a project, or starting an agent run, Customer instructs Caveman to send the relevant Customer Data to that Model Provider. At the date of this version, Caveman does not use a model provider under its own account to process Customer Personal Data on the hosted Services. Before it does, it adds that provider to the Sub-processor list with the notice section 8.3 requires.

Other services Customer connects, such as GitHub, Google sign-in or Customer's own identity provider, are engaged by Customer in the same way. For example, on the hosted Services the optional GitHub integration uses Caveman's GitHub App, which Customer installs on the repositories it chooses in its own GitHub account. The App has read access to repository metadata and write access to repository contents and pull requests, and GitHub notifies Caveman when the App is installed or changed and when its pull requests change. GitHub handles that repository data under Customer's own agreement with GitHub.

## 4. Customer instructions

### 4.1 Documented instructions

Caveman processes Customer Personal Data only on Customer's documented instructions, including with regard to transfers to a third country, unless Union or Member State law, or other law to which Caveman is subject, requires otherwise. In that case Caveman will inform Customer of that legal requirement before processing, unless that law prohibits this on important grounds of public interest.

### 4.2 What the instructions are

Customer's instructions are the Terms, any Order Form and this DPA; Customer's use and configuration of the Services, including the settings a Workspace admin chooses in Data governance; and per-request instructions, including the `x-cave-retention` header. Other instructions require written agreement.

The `x-cave-retention` header can only tighten retention for a request, never loosen it. With `x-cave-retention: metadata`, Caveman records only Usage Metadata for that request: it does not store the Payload, keep a compression recovery original or cache the response. With `x-cave-retention: zdr`, Caveman does not store the Payload, keep a compression recovery original, cache the response or include the request in Replay.

### 4.3 Unlawful instructions

Caveman will tell Customer promptly if, in its opinion, an instruction infringes Data Protection Laws, and may suspend the affected processing until Customer confirms or changes it.

### 4.4 Zero data retention configurations

If an Order Form provides for a zero data retention configuration, Caveman turns payload storage off for the Workspace and keeps artifact storage off, which is already the default on Enterprise. The Services then keep Usage Metadata only and store no Payloads, compression recovery originals, cached responses or artifacts, and Replay has nothing to send. A Workspace admin can change these settings in Data governance, and each change is recorded in the audit log. Customer can also send `x-cave-retention: zdr` on any request.

## 5. Customer responsibilities

Customer:

- (a) is responsible for the lawfulness of the Customer Personal Data it sends and of its instructions, including having a lawful basis and giving any notices and obtaining any consents Data Protection Laws require;
- (b) must not send special categories of personal data, criminal-offence data or children's personal data through a Workspace where Product Data Sharing applies (always the case on Free), and elsewhere must send such data only where lawful and with the Services configured to match, for example with a short retention window or `x-cave-retention: zdr`;
- (c) must not send protected health information regulated under HIPAA or payment card data on any plan unless an Order Form allows it;
- (d) is responsible for its agreements with Model Providers and other services it connects, and any transfer mechanism they need; and
- (e) is responsible for the security of its own systems, accounts, credentials and provider API keys, and for deciding whether the measures in Annex II meet its needs.

## 6. Confidentiality

Caveman ensures that everyone it authorises to process Customer Personal Data has committed to confidentiality or is under a statutory obligation of confidentiality. Access is limited to personnel who need it to provide, secure or support the Services, and production access is granted on a least-privilege basis.

## 7. Security

Caveman implements and maintains the technical and organisational measures in Annex II, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risks to individuals, as GDPR Article 32 requires. Caveman may update these measures as the Services change, provided the update does not materially reduce the overall protection of Customer Personal Data.

## 8. Sub-processors

### 8.1 General authorisation

Customer gives Caveman general written authorisation to engage Sub-processors, and authorises those listed on the [Sub-processors](/legal/subprocessors) page (Annex III).

### 8.2 Sub-processor terms

Caveman engages a Sub-processor only under a written contract imposing data protection obligations no less protective than this DPA, as relevant to its service. Caveman remains fully liable to Customer for each Sub-processor's performance of those obligations.

### 8.3 Notice of changes

Caveman will give at least 30 days' notice before a new Sub-processor starts processing Customer Personal Data or an existing one is replaced. Caveman gives notice by updating the Sub-processors page and by emailing the owners of Customer's Workspace and anyone who has subscribed to change notices. Anyone can subscribe by writing to [contact@caveman.so](mailto:contact@caveman.so). The notice names the Sub-processor, describes what it will do and states where it processes data.

If Caveman must replace a Sub-processor urgently to protect the security or continuity of the Services, it may do so on shorter notice and will notify Customer as soon as reasonably possible. Section 8.4 still applies.

### 8.4 Objections

Customer may object to a new Sub-processor on reasonable data protection grounds by writing to [contact@caveman.so](mailto:contact@caveman.so) within the notice period. The parties will discuss the objection in good faith, and Caveman may propose a change that avoids use of that Sub-processor for Customer Personal Data. If the objection is not resolved within 30 days after Caveman receives it, Customer may terminate the affected Services by written notice, and Caveman will refund, pro rata, any prepaid fees for the terminated Services covering the period after termination. This is Customer's sole remedy for the objection.

## 9. Data subject requests

### 9.1 Tools and assistance

Taking into account the nature of the processing, Caveman assists Customer by appropriate technical and organisational measures, insofar as possible, in responding to data subjects exercising their rights. The Services provide retention settings and Workspace data deletion in Data governance, and an API to export the Customer Personal Data associated with an individual end user. The Services do not offer a function to erase the data of an individual end user. Customer can request that erasure by writing to [contact@caveman.so](mailto:contact@caveman.so), and Caveman will erase the Customer Personal Data it can identify by the client user ID or other identifiers Customer supplies; Customer can also delete Workspace data or set a retention window in Data governance. Where these tools are not enough, Caveman will give reasonable further assistance on request.

### 9.2 Requests sent to Caveman

If Caveman receives a data subject request that relates to Customer Personal Data and identifies Customer, it will forward the request to Customer without undue delay and will not respond itself, beyond confirming receipt and referring the data subject to Customer, unless Data Protection Laws require otherwise.

## 10. Impact assessments and consultation

Taking into account the nature of the processing and the information available to it, Caveman will give Customer reasonable assistance with data protection impact assessments and prior consultations with supervisory authorities under GDPR Articles 35 and 36, or equivalent provisions, relating to Customer's use of the Services. Caveman will do this first through this DPA, its Annexes and written answers to Customer's reasonable questions.

## 11. Personal data breaches

### 11.1 Notification

Caveman will notify Customer of a personal data breach affecting Customer Personal Data without undue delay and, where feasible, within 72 hours of becoming aware of it, by email to the owners of the affected Workspace.

### 11.2 Content of the notice

To the extent known, the notice describes:

- (a) the nature of the breach, including, where possible, the categories and approximate number of data subjects and records concerned;
- (b) a contact point for more information;
- (c) the likely consequences; and
- (d) the measures taken or proposed to address the breach and mitigate its possible adverse effects.

Where Caveman cannot provide all of this at once, it will provide it in phases, without undue further delay, as it becomes available.

### 11.3 Response

Caveman will take reasonable steps to contain, investigate and mitigate the breach, and will give Customer reasonable assistance with its obligations under GDPR Articles 33 and 34. Unless agreed otherwise, Customer notifies supervisory authorities and data subjects where required. A notification is not an admission of fault. Unsuccessful attempts that do not compromise Customer Personal Data, such as pings, port scans or failed sign-ins, are not personal data breaches.

## 12. Deletion and return

### 12.1 During the term

Caveman keeps Customer Personal Data until Customer deletes it, subject to the shorter periods for derived data in Annex I. Customer can set a retention window in Data governance, and a daily retention worker deletes data whose window has ended. Customer can delete a Workspace's data in Data governance at any time; Caveman carries out the deletion 30 days after the request.

### 12.2 Export and deletion at the end

Customer exercises its choice of return by exporting Customer Data. Customer can export Customer Data during the term and for 30 days after the Agreement ends, or longer where EU Data Act switching applies, using the export tools in the Services, which document their formats and structures, plus reasonable assistance on request. Caveman deletes the remaining Customer Personal Data within 30 days after that export period ends.

### 12.3 Backups

Database backups, point-in-time recovery logs and object versions roll off within about 35 days after deletion. Rows deleted from ClickHouse Cloud by a retention window can stay on disk, and in backups taken in that time, for about a month, and those backups are kept up to 30 days more, so in total up to about two months. Until then they stay protected under Annex II and are used for no other purpose.

### 12.4 Retention required by law

Caveman may keep Customer Personal Data that Union or Member State law, or other law to which Caveman is subject, requires it to store, only for as long and for the purpose that law requires, and protected under this DPA.

### 12.5 Confirmation

On Customer's written request, Caveman will confirm the deletion in writing.

## 13. Audits and information

### 13.1 Information first

Caveman will make available the information reasonably necessary to demonstrate compliance with GDPR Article 28 and this DPA. Customer agrees to seek it first through documentation and written answers: this DPA, its Annexes, the Sub-processors page, and Caveman's answers to a reasonable security or privacy questionnaire, once a year or more often if a supervisory authority requires it or after a personal data breach affecting Customer.

### 13.2 Audits and inspections

If that information is not enough to demonstrate compliance, if there are indications of non-compliance, or if a supervisory authority requires it, Customer, or an independent auditor it mandates who is bound by confidentiality and is not a Caveman competitor, may audit Caveman's compliance with this DPA, including by inspection. Audits:

- (a) take place at most once a year, unless a supervisory authority requires otherwise or after a personal data breach affecting Customer;
- (b) need at least 30 days' written notice and a scope agreed in advance;
- (c) take place during business hours without unreasonable disruption, and exclude other customers' data and information Caveman must keep confidential for third parties; and
- (d) are at Customer's cost, including Caveman's reasonable costs, unless the audit shows a material breach of this DPA by Caveman.

Customer will share the audit report with Caveman and keep it confidential.

### 13.3 Certifications

Caveman does not currently hold SOC 2, ISO 27001 or any other security certification, and does not claim one. If it later obtains a certification or independent audit report covering the matters in question, it may provide it in answer to an audit request. Audits under the SCCs follow this section to the extent consistent with the SCCs, and nothing here limits Customer's rights under them.

## 14. International transfers

### 14.1 Where data is processed

Caveman hosts Customer Data on Google Cloud in the europe-west4 region (the Netherlands), and keeps Usage Metadata, derived prompt data and imported log content in ClickHouse Cloud in the same region. Customer Personal Data may still be processed outside the European Economic Area ("EEA"): Caveman Labs, Inc. is a US company whose personnel may access data from the United States and elsewhere, Cloudflare handles traffic on its global network, and some Sub-processors are US companies. Caveman does not promise that Customer Personal Data stays in the EEA.

### 14.2 Model Providers

Where a Model Provider processes data depends on the Model Provider and the endpoint Customer chooses. Customer is responsible for any transfer mechanism that leg needs, under Customer's agreement with that Model Provider.

### 14.3 EU Standard Contractual Clauses

To the extent Customer's provision of Customer Personal Data to Caveman is a Restricted Transfer under the GDPR, the SCCs are incorporated into this DPA and apply as follows:

- (a) Module 2 (controller to processor) applies where Customer is a controller, and Module 3 (processor to processor) applies where Customer is a processor;
- (b) Customer is the data exporter and Caveman Labs, Inc. is the data importer;
- (c) Clause 7 (docking clause) is included;
- (d) in Clause 9(a), Option 2 (general written authorisation) applies, and the time period for prior notice of changes to Sub-processors is 30 days, given as described in section 8.3;
- (e) in Clause 11(a), the optional language does not apply;
- (f) in Clause 13(a), the competent supervisory authority is determined as set out in Annex I, Part C;
- (g) in Clause 17, Option 1 applies, and the SCCs are governed by the law of the Netherlands;
- (h) in Clause 18(b), disputes are resolved before the courts of Amsterdam, the Netherlands; and
- (i) Annexes I, II and III of the SCCs are completed by Annexes I, II and III of this DPA.

By entering into this DPA, each party is treated as having signed the SCCs, including their Annexes. The confirmation in section 12.5 is the certification of deletion under Clause 8.5. Nothing in the Agreement varies the SCCs or prejudices data subjects' fundamental rights or freedoms, and the SCCs prevail over any conflicting term.

### 14.4 Controller-to-controller transfers

To the extent Customer transfers personal data to Caveman for processing as an independent controller under section 3.4, including account data and data used under Product Data Sharing, and the transfer is a Restricted Transfer under the GDPR, Module 1 (controller to controller) of the SCCs applies. Clause 7 is included; the optional language in Clause 11(a) does not apply; Clause 13 and Annex I, Part C apply as for Modules 2 and 3; under Clause 17 the SCCs are governed by the law of the Netherlands; under Clause 18(b) disputes are resolved before the courts of Amsterdam, the Netherlands; Annex I of the SCCs is completed by Annex I, Parts A, C and D of this DPA, and Annex II by Annex II.

### 14.5 UK transfers

To the extent the transfer is a Restricted Transfer under the UK GDPR, the SCCs apply as amended by the UK Addendum, which is incorporated into this DPA. Its Part 1 tables are completed as follows:

- (a) Table 1: parties, details and contacts as in Annex I, Part A; the start date is the date this DPA takes effect;
- (b) Table 2: the SCCs as incorporated by sections 14.3 and 14.4, with the modules and options selected there;
- (c) Table 3: the Appendix Information is in Annexes I, II and III; and
- (d) Table 4: neither party may end the UK Addendum under its Section 19.

Under the UK Addendum's Mandatory Clauses, the supervisory authority is the UK Information Commissioner, and the law and courts are those of England and Wales.

### 14.6 Swiss transfers

To the extent the transfer is subject to the Swiss FADP, the SCCs apply as set out in sections 14.3 and 14.4 with these adaptations:

- (a) references to the GDPR are read as references to the Swiss FADP, to the extent the transfer is subject to it;
- (b) the competent supervisory authority under Clause 13 is the Swiss Federal Data Protection and Information Commissioner, alongside the authority in Annex I, Part C where the GDPR also applies; and
- (c) the term "Member State" in Clause 18(c) does not prevent data subjects habitually resident in Switzerland from bringing claims there.

### 14.7 Onward and alternative mechanisms

Caveman makes an onward Restricted Transfer to a Sub-processor only under a lawful transfer mechanism, such as standard contractual clauses or the EU-US Data Privacy Framework where the Sub-processor is certified under it. Caveman Labs, Inc. is not currently certified under the EU-US Data Privacy Framework. If Caveman adopts another recognised mechanism that covers a transfer, such as that certification or revised SCCs, it applies in place of the SCCs while valid. If a mechanism relied on here ceases to be valid, the parties will cooperate in good faith to put a lawful one in place.

### 14.8 Transfer impact assessments

Caveman will give Customer the information reasonably available to it that Customer needs to assess transfers under Clause 14 of the SCCs, including on US laws and practices that apply to Caveman.

## 15. Government access requests

If Caveman receives a legally binding request from a public authority, including a judicial authority, to disclose Customer Personal Data, Caveman will:

- (a) assess whether the request is lawful and, where it concludes after careful assessment that there are reasonable grounds to consider it unlawful, challenge it using the remedies available, including interim measures;
- (b) notify Customer promptly, and before disclosure where possible, unless the law prohibits it, in which case Caveman will use reasonable efforts to obtain a waiver so it can tell Customer as much as possible, as soon as possible;
- (c) try to redirect the authority to request the data directly from Customer;
- (d) disclose only the minimum data permissible under a reasonable interpretation of the request; and
- (e) keep a record of the request and its response, and share it with Customer where the law permits.

These commitments add to Clause 15 of the SCCs where the SCCs apply.

## 16. US State Privacy Laws

Where US State Privacy Laws apply to Customer Personal Data, Caveman:

- (a) processes Customer Personal Data only for the limited and specified business purposes of providing, securing and supporting the Services, as set out in the Agreement and in Annex I, Part B (the "Business Purposes"), or as US State Privacy Laws otherwise permit a service provider;
- (b) does not sell or share Customer Personal Data;
- (c) does not retain, use or disclose Customer Personal Data for any purpose, including any commercial purpose, other than the Business Purposes, and does not retain, use or disclose it outside the direct business relationship between Caveman and Customer;
- (d) does not combine Customer Personal Data with personal information that it receives from or on behalf of another person, or collects from its own interactions with a consumer, except as US State Privacy Laws permit a service provider to do;
- (e) complies with the obligations that apply to it as a service provider and gives Customer Personal Data the same level of privacy protection that US State Privacy Laws require of Customer;
- (f) will notify Customer if it determines that it can no longer meet its obligations under US State Privacy Laws;
- (g) gives Customer the right, on notice, to take reasonable and appropriate steps to stop and remediate unauthorised use of Customer Personal Data, and to ensure Caveman uses it consistently with Customer's obligations, including through section 13; and
- (h) certifies that it understands and will comply with the restrictions in this section 16.

Sections 6, 8, 12 and 13 meet the other processor contract requirements of US State Privacy Laws. Data used under Product Data Sharing falls outside these service provider terms, because Caveman uses it as an independent controller; where it applies, Customer is responsible for any notice, consent or opt-out US State Privacy Laws require.

## 17. Liability

Each party's liability arising out of or related to this DPA, including the SCCs to the extent permitted, is subject to the limitations and exclusions of liability in the Terms or the Order Form, to the extent Data Protection Laws permit. This DPA creates no separate limit. Nothing limits either party's liability to data subjects where Data Protection Laws do not permit it, or affects data subjects' third-party beneficiary rights under the SCCs.

## 18. Order of precedence

If documents conflict on the processing of Customer Personal Data, they prevail in this order:

- (a) the SCCs, as amended by the UK Addendum or the Swiss adaptations where those apply;
- (b) an Order Form, only to the extent it expressly changes this DPA;
- (c) this DPA;
- (d) the Terms;
- (e) the [Acceptable Use Policy](/legal/acceptable-use); and
- (f) other policies.

## 19. Term and general terms

### 19.1 Term

This DPA takes effect when Customer accepts the Terms or signs an Order Form that incorporates it, and continues for as long as Caveman processes Customer Personal Data on Customer's behalf, including after the Agreement ends until deletion under section 12. Provisions that by their nature should survive termination survive it.

### 19.2 Changes

Caveman may update this DPA, including to reflect changes in Data Protection Laws, regulatory guidance or the SCCs. Caveman gives 30 days' advance notice of material changes, by email to Workspace owners and admins and by a notice on this page, except where law or security requires a change to take effect immediately. An update will not materially reduce the protection of Customer Personal Data unless Data Protection Laws require it. A countersigned copy governs until the parties agree a change in writing, except for changes Data Protection Laws require.

### 19.3 Governing law and severability

Except where the SCCs or Data Protection Laws require otherwise, this DPA is governed by the law that governs the Terms, and disputes are resolved as the Terms provide. If a provision is invalid or unenforceable, the rest remains in effect, and the provision is amended to the minimum extent needed to make it valid.

## Annex I: Details of processing

### Part A: List of parties

**Data exporter**

- Name: the Customer that accepts the Terms or signs an Order Form, as identified in its Workspace or Order Form.
- Address: the address Customer provides in its Order Form or billing details.
- Contact person: the owner of Customer's Workspace, or the contact named in the Order Form.
- Activities relevant to the data transferred: use of the Services.
- Role: controller (Modules 1 and 2) or processor (Module 3).
- Signature and date: treated as signed when Customer accepts the Terms or signs an Order Form.

**Data importer**

- Name: Caveman Labs, Inc.
- Address: \[registered address\]
- Contact: [contact@caveman.so](mailto:contact@caveman.so)
- Representative: if we are required to appoint a representative in the EU or UK under Article 27 GDPR / UK GDPR, we will list their details here.
- Activities relevant to the data transferred: providing the Services as described in Part B.
- Role: processor (Module 2), sub-processor (Module 3) or independent controller (Module 1).
- Signature and date: treated as signed on the same date.

### Part B: Processing on Customer's behalf

This Part covers Modules 2 and 3.

**Categories of data subjects.** Customer decides what it sends. Data subjects may include:

- Customer's authorised users, such as employees and contractors, whose identifiers appear in Usage Metadata;
- Customer's end users, and any other individuals whose personal data Customer includes in Payloads;
- individuals identified by client user IDs that Customer sends, which Caveman stores in hashed form; and
- contributors to Customer's code repositories, whose details appear in repository history that the GitHub integration and agent runs read.

**Categories of personal data.**

- Usage Metadata, as defined in section 2.
- Tags attached to requests. In the `caveman` CLI's managed gateway mode, these include repository owner and name and branch name, unless the user disables this.
- Span metadata and aggregate findings uploaded by `caveman sync` when a user is signed in, never including raw prompt or response bodies.
- Payloads, which may contain any personal data Customer sends. They are stored by default on every plan, after automated redaction. On Pay-as-you-go and Enterprise, a Workspace admin can turn payload storage off.
- Routing requests, where a user turns routing on, on every plan: the latest message with what the agent attaches to it (up to 128 KiB), the previous message and the end of the agent's last reply (up to 16 KiB each), and request facts such as tool names, effort and token counts. They are processed in memory to choose a model and effort, and not kept outside the Free router-learning conditions in section 3.5.
- Redacted prompt snippets and embeddings derived from Payloads, used for traffic analysis and the semantic cache and stored in ClickHouse Cloud.
- Compression recovery originals (encrypted, unredacted exact copies that let compressed prompts be restored byte for byte), cached responses, files the SDKs save for recovery, and, while artifact storage is on, the artifacts produced by agent runs.
- Imported traces and logs: their metadata, such as span names, models, timings, severity, event names and exception types, stored as the exporter sent it, without redaction; their prompt, completion and tool content, stored as a Payload where the project stores Payloads, unless the exporter sends `x-cave-capture-content: false`; and log bodies, exception messages and stack traces, redacted and cut to 16 KiB each.
- Repository code and history copied for agent runs, including commit author names and email addresses, and the repository inventories and fix results that Caveman's skills for coding agents send to the Workspace.
- The content of account emails generated from Customer Data, such as usage digests and spend alerts.

**Sensitive data.** Customer must not send special categories of personal data, criminal-offence data or children's personal data where Product Data Sharing applies (always the case on Free); otherwise only as section 5 permits. Safeguards: the measures in Annex II, retention limits and the `x-cave-retention: zdr` header.

**Frequency of the transfer.** Continuous, for as long as Customer uses the Services.

**Nature of the processing.** Receiving requests and forwarding them, with Customer's keys passed per request or stored in the Services, to the Model Providers Customer chooses; returning responses; reversible prompt compression; response caching; routing between models as Customer configures; recording Usage Metadata; storing Payloads and derived prompt data; importing Customer's traces and logs; traffic analysis and semantic-cache evaluation; Replay of stored Payloads to Customer's Model Providers, where Replay is on; AI features and agent runs on Customer's keys, where Customer uses them; measuring cost, latency and savings for the dashboard; sending account emails; export; and deletion.

**Purpose of the processing.** To provide, secure and support the Services under the Agreement and Customer's instructions.

**Retention.**

| Data | Retention |
|---|---|
| Usage Metadata and other request history | Until Customer deletes it, or until the end of the Workspace's retention window. A Workspace admin can set a window from 1 to 36,500 days; by default no window is set. |
| Payloads, compression recovery originals, imported content and agent artifacts | Until Customer deletes them, or until the end of the Workspace's retention window. With payload storage off, Payloads are not kept. Agent artifacts are kept only while artifact storage is on, which is the default on Free and not on Pay-as-you-go or Enterprise. |
| Redacted prompt snippets, embeddings and cluster maps | 90 days at most. Semantic-cache samples: 30 days at most. Semantic-cache judgments: 90 days at most. Never longer than the Workspace's retention window. |
| Cached responses | 5 minutes by default and 24 hours at most. |
| SDK shared contexts and reversible checkpoints | Shared contexts: 2 hours by default and 24 hours at most. Checkpoints: 24 hours. Written and read only while payload storage is on. |
| Requests sent with `x-cave-retention: zdr` | No Payload, recovery original or cached response is stored, and the request is excluded from Replay. |
| Workspace data deleted in Data governance | Deleted 30 days after the request. |
| Customer Data after the Agreement ends | Exportable for 30 days, or longer where EU Data Act switching applies; deleted within 30 days after that. |
| Backups, point-in-time recovery logs and object versions | Roll off within about 35 days after deletion. Rows deleted from ClickHouse Cloud by a retention window can stay on disk, and in backups taken in that time, for about a month, and those backups are kept up to 30 days more: up to about two months in total. |

**Transfers to Sub-processors.** For the subject matter and nature described on the [Sub-processors](/legal/subprocessors) page, for as long as Caveman needs their service, within the retention periods above.

### Part C: Supervisory authority

For transfers under the GDPR, the competent supervisory authority under Clause 13 of the SCCs is:

- where Customer is established in an EU Member State, the supervisory authority responsible for ensuring Customer's compliance with the GDPR as regards the transfer;
- where Customer is not established in the EU but falls within GDPR Article 3(2) and has appointed a representative under Article 27(1), the supervisory authority of the Member State where that representative is established; and
- where Customer is not established in the EU, falls within GDPR Article 3(2) and is not required to appoint a representative (Article 27(2)), the Dutch Autoriteit Persoonsgegevens if data subjects whose personal data is transferred are located in the Netherlands; if none are, the supervisory authority of an EU Member State where those data subjects are located, as Customer notifies Caveman in writing.

For transfers under the UK GDPR, it is the UK Information Commissioner. For transfers under the Swiss FADP, it is the Swiss Federal Data Protection and Information Commissioner.

### Part D: Module 1 transfers

This Part describes personal data Caveman receives as an independent controller (section 3.4) and covers Module 1. Both parties act as controllers.

**Categories of data subjects.** Customer's authorised users; and, where Product Data Sharing applies, individuals whose personal data appears in Payloads and Usage Metadata.

**Categories of personal data.** Account data (name, email address, authentication material, role, Workspace membership, session records including IP address and user agent, and a keyed hash of the IP address used to sign up); billing data; security and audit logs; support communications; and Payloads and Usage Metadata used under Product Data Sharing, including, on Free projects that opt in to router learning, sampled routing-request text.

**Sensitive data.** None intended. Section 3.5 lists data Customer must not send where Product Data Sharing applies.

**Frequency of the transfer.** Continuous, for as long as Customer uses the Services.

**Nature and purpose.** Providing user accounts, billing and the security of the Services; and, under Product Data Sharing, improving Caveman's own routing, compression, caching and optimisation models and evaluations.

**Retention.** Account data: for the life of the account. Session records: for as long as needed to keep the account secure. Audit logs: for the life of the Workspace, unless agreed otherwise. Infrastructure records of access to stored data: 365 days. Billing data: as tax and accounting law requires. Routing decision counts: 13 months. Routing outcomes from Free projects that opt in to router learning: up to 365 days. Daily counts of billable events: for the life of the Workspace. Data used under Product Data Sharing: while sharing applies to it, unless Customer deletes it first; training sets built from it expire after 365 days. The [Privacy Policy](/privacy) gives more detail.

**Onward transfers.** To the vendors on the [Sub-processors](/legal/subprocessors) page, under a lawful transfer mechanism.

## Annex II: Security measures

This Annex describes the technical and organisational measures Caveman operates for the Services on the date of this version. Caveman does not hold SOC 2, ISO 27001 or any other security certification. This Annex lists only measures that are in place, and commitments stated as such.

### Encryption

- TLS 1.2 or higher in transit, between clients and the Cloudflare edge and between Cloudflare and Caveman's origin.
- Encryption at rest with the hosting providers' default encryption; object storage uses keys Caveman manages in Google Cloud KMS, rotated every 90 days.
- Payloads in object storage are envelope-encrypted with AES-256-GCM under data keys scoped to one Workspace. Compression recovery originals, cached responses, SDK recovery files and agent-run artifacts are also stored encrypted.
- Data in ClickHouse Cloud, including redacted prompt snippets, embeddings and imported log content, relies on the provider's at-rest encryption.

### Secrets and provider keys

- Customer can pass a Model Provider API key with each request or store it in the Services. Stored keys are envelope-encrypted with a dedicated Cloud KMS key. The gateway uses a stored key when a request carries none, and routing through Caveman Cloud, model comparisons, Replay and agent runs use stored keys.
- For Amazon Bedrock on hosted Caveman Cloud, Customer provides a Bedrock API key or AWS access keys, stored encrypted like other Model Provider keys. Hosted Caveman Cloud does not assume a role in Customer's AWS account.
- Secrets for the GitHub App are envelope-encrypted with Cloud KMS.

### Minimisation and pseudonymisation

- Payloads are stored by default on every plan. Before a Payload is stored, it passes through automated redaction, using built-in rules and any rules the Workspace adds; automated redaction reduces, but cannot eliminate, the chance that personal data is stored. On Pay-as-you-go and Enterprise, a Workspace admin can turn payload storage off, and the Services then keep Usage Metadata only.
- Compression recovery originals are exact copies and are not redacted. They are stored encrypted and follow the Workspace's payload setting.
- Replay is on by default for each project, and a Workspace admin can turn it off for each project. Stored Payloads leave Caveman's own systems for Replay only with Replay on, and only to Customer's Model Providers on Customer's keys.
- `x-cave-retention: zdr` turns off payload storage, compression recovery originals, caching and Replay for a request.
- Usage Metadata holds salted hashes of Payloads, and client user IDs are stored hashed.
- The audit log stores the IP address of each entry as a keyed (HMAC) hash, not in readable form.

### Access control and tenant isolation

- Role-based access control within each Workspace.
- Multi-factor authentication and passkeys are available to every account, and organisations can use single sign-on with OpenID Connect (including Microsoft Entra ID) or SAML and provision accounts with SCIM; passwords are stored only as hashes.
- Cloudflare Turnstile checks sign-ups for bots.
- AI assistants connect to a Workspace through OAuth, after a User approves a consent screen, and only assistants Caveman has registered can connect. Their access tokens last 15 minutes and are renewed for up to 30 days. Tokens are stored only as keyed hashes and are deleted 24 hours after they expire.
- The dashboard session cookie is HttpOnly, Secure, SameSite=Lax and host-only, and lasts 7 days, refreshed while in use.
- Caveman personnel receive production access on a least-privilege basis.
- The database enforces tenant isolation with row-level security.

### Network and infrastructure

- The Services run in Google Cloud data centres, and physical and environmental security is inherited from Google Cloud.
- Cloudflare DNS, reverse proxy, DDoS protection, web application firewall and rate limiting in front of the Services, and the origin accepts traffic only from Cloudflare.
- ClickHouse Cloud is reached only over private connectivity.
- Agent runs execute in isolated sandboxes.
- The dashboard's content security policy allows third-party scripts only from app.cal.com, for meeting booking, and from Cloudflare, for Turnstile.

### Logging, backups and deletion

- Each Workspace has an append-only audit log of activity, including consents and reads of stored Payloads.
- The arguments and results of tool calls made by connected AI assistants are not logged.
- The cloud provider's records of who accessed stored data are kept in a locked store for 365 days.
- The database has point-in-time backups. Backups, point-in-time recovery logs and object versions are kept for up to about 35 days. ClickHouse backups are locked for 30 days. Rows deleted from ClickHouse Cloud by a retention window can stay on disk for about a month, and in backups taken in that time, so up to about two months in total.
- A daily retention worker deletes data past its retention period, within the limits in Annex I.

### Personnel, incidents and software

- Caveman requires personnel with access to Customer Personal Data to be bound by confidentiality obligations, and limits access to those who need it (section 6).
- Caveman responds to security incidents by triaging and containing them, investigating their cause and scope, and notifying Customer as section 11 describes.
- Caveman's code repositories have automated dependency vulnerability alerts, and release images are signed.
- Sub-processors are engaged under written contracts (section 8).
- Caveman will review these measures regularly and when the Services change.
- Security issues can be reported to [contact@caveman.so](mailto:contact@caveman.so). Vulnerabilities in the open-source toolkit can also be reported through [GitHub private vulnerability reporting](https://github.com/JuliusBrussee/caveman/security/advisories/new).

## Annex III: Sub-processors

Customer authorises the Sub-processors listed on the [Sub-processors](/legal/subprocessors) page, as updated under section 8. Model Providers, and other services Customer connects to the Services, are not Sub-processors.