Data processing agreement
The Article 28 terms under which briq processes personal data on your behalf, including sub-processors and security measures.
If you are a business using briq and personal data ends up inside your briqs, Article 28(3) of the GDPR requires a contract between us before that processing is lawful. This is that contract.
You do not need to sign anything. This agreement is incorporated into the terms of service and takes effect when you accept them or use the service. If your procurement process needs a countersigned copy on paper, write to legal@briq.run and we will sign one.
Last updated: 21 September 2026.
1. Roles
You are the controller for personal data your agents or your code place inside your briqs, pass to our API, or store on volumes. briq is the processor for that data.
Separately, briq is the controller for your own account data. That is not covered here; see the privacy notice.
Where you are yourself a processor for someone else, you act as their processor and we act as a sub-processor, and this agreement applies to us on that basis.
2. Our obligations
We will:
- Process only on your documented instructions, including for transfers. Your use of the API, the MCP tools, the CLI and the dashboard are your instructions. We will tell you if we believe an instruction breaches the GDPR, and we will tell you if EU or member state law requires us to process beyond your instructions, unless that law forbids telling you. Art. 28(3)(a).
- Bind everyone with access to confidentiality. Art. 28(3)(b).
- Keep the security measures in Annex II, appropriate to the risk under Art. 32. Art. 28(3)(c).
- Use sub-processors only under section 3. Art. 28(3)(d), Art. 28(2) and (4).
- Help you answer data subjects. Given the design of the service you can reach your own data directly, so our help is usually giving you access or a copy. Where you need more, we will assist by appropriate technical and organisational measures. Art. 28(3)(e).
- Help you with security, breaches, impact assessments and prior consultation, taking into account what we know and what you do not. We will notify you without undue delay and in any case within 48 hours of becoming aware of a personal data breach affecting your data, with what we know and what we are doing. Art. 28(3)(f), Arts. 32 to 36.
- Delete or return your data at the end. Destroying a briq destroys its machine and its volume. When your account closes, remaining data is deleted within 30 days, except where EU or member state law requires us to keep it. Art. 28(3)(g).
- Show our work. We will give you the information you reasonably need to verify this agreement, and allow an audit or inspection by you or an auditor you mandate. In practice we ask you to start with this page, the security model and data protection; where those do not answer the question, we will. Audits are once a year unless a regulator or a breach requires otherwise, at reasonable notice, during business hours, and without compromising other customers. Art. 28(3)(h).
3. Sub-processors
You give general written authorisation for us to use the sub-processors listed in Annex III. We impose data protection obligations on them that are no less protective than these, and we remain liable to you for what they do.
We will publish any addition or replacement on this page and email account holders at least 30 days before it takes effect. If you object on reasonable data protection grounds within those 30 days, tell us; if we cannot resolve it, you may terminate the affected service and we will refund prepaid credits for what you have not used.
4. Transfers outside the EU
Your briqs, their volumes and their logs are processed in Paris, and briq operates no region outside the EU. So in the ordinary course there is no transfer.
Our infrastructure provider is incorporated in the United States, which means US law can in principle reach it even where the bytes sit in Paris. For any access that amounts to a transfer, we rely on the provider's certification under the EU-U.S. Data Privacy Framework and, where that does not apply, on the Standard Contractual Clauses, together with the measures in Annex II. We assess whether those safeguards remain effective, and we will tell you if we conclude they do not.
We will challenge any government request for your data that appears unlawful or overbroad, and we will tell you about it unless the law forbids it.
5. Liability and term
This agreement lasts as long as we process personal data for you. Liability under it is subject to the limits in the terms of service. Where those terms and this agreement conflict on data protection, this agreement wins.
Annex I — the processing
| Subject matter | Running container images as isolated microVMs, and the storage, networking, logging and metering around them |
| Duration | For as long as you have an account, and for each briq until it is destroyed |
| Nature and purpose | Execution, storage, transmission and deletion of whatever you place in a briq, in order to provide the service |
| Types of personal data | Determined by you. briq does not require personal data and does not inspect what you send. Anything your agent writes into a database, a volume, an environment variable or a log is in scope |
| Categories of data subjects | Determined by you: typically your own users, customers or staff |
| Special categories | Not expected. If you intend to process Article 9 or Article 10 data, tell us first so we can confirm the measures are adequate |
Annex II — security measures
These are the measures in place today, not aspirations. The security page is the fuller description.
| Area | Measure |
|---|---|
| Tenant isolation | One Firecracker microVM per briq; customers never share a kernel. One private network per team; nothing resolves across teams. Optional per-stack isolation |
| Network exposure | Private by default; no inbound traffic until you call briq_expose. Egress rate limited, with per-key allow, deny and allowlist policies |
| Secrets | Values marked { secret } are generated, injected once and masked in status, logs and audit. API keys stored as SHA-256 hashes with a lookup prefix only |
| Encryption | TLS for all API, MCP, CLI and dashboard traffic; provider encryption at rest for volumes and databases |
| Access control | Team-scoped tenancy with owner, admin and member roles; per-key policies for concurrency, size, registry, TTL and spend |
| Logging | One audit row per authenticated request, with key id, action, target, duration and cost |
| Deletion | Destroying a briq destroys its machine and volume; logs are not retained after destroy |
| Operations | Operator access to provider consoles and machine metadata is limited to running the service and is logged |
| Resilience | Provider calls run in background jobs so a timeout cannot leak a machine; a reconciler enforces TTLs and destroys orphans every 30 seconds |
Annex III — sub-processors
| Sub-processor | Purpose | Location | Transfer basis |
|---|---|---|---|
| Infrastructure provider | Compute, volumes, logging, and hosting of briq itself | Paris (cdg); corporate parent incorporated in the USA | EU processing; EU-U.S. Data Privacy Framework and SCCs for any US access |
We identify each sub-processor by name on request, so that you can complete your own transfer assessment or object to a change under section 3. Write to legal@briq.run.
Payments, error tracking and an email provider are planned. None is connected today, and each will appear here with 30 days' notice before it is.