Data processing agreement

Data processing agreement

This agreement covers the personal data we handle for you when you use massrelay. You are the controller of that data and we are the processor. It is built on the European Commission's standard contractual clauses between controllers and processors, Implementing Decision (EU) 2021/915. Those clauses apply word for word, with nothing added inside them and nothing removed. If anything else in our terms conflicts with them on data protection, the clauses prevail.

You accept this agreement by accepting our terms of service, or by signing a copy. We send a copy for signature on request to [email protected].

The options we chose

The clauses leave some choices to the parties. Ours are:

• Docking clause (Clause 5): kept, so your affiliates can join this agreement by signing an annex.
• Sub-processors (Clause 7.7): general written authorisation. We give you 30 days' notice of any change, and you may object within that time.
• How we notify you of a sub-processor change: by e-mail to your data-protection contact, and by updating the list on this page under Annex IV.
• Audits (Clause 7.6): we give you documentary evidence first. If you still need more, you may carry out at most one on-site audit a year, on 30 days' notice and at your cost, unless a supervisory authority requires otherwise.
• Assistance (Clause 8): we help with data-subject requests and impact assessments within 10 business days of your request.
• International transfers (Clause 7.8): the Commission's 2021/914 standard clauses, Module 2 (controller to processor). For the United Kingdom, the UK Addendum to those clauses.
• Personal data breach (Clause 9): we tell you without undue delay, and within 48 hours of becoming aware, at the contact you give us.
• End of processing (Clause 10): within 30 days of the end of the agreement we return or delete your data, and we confirm it in writing on request.
• Liability: subject to the limitations of liability in the main agreement.

Annex I – the parties

Controller

The customer named in the order form or account that accepts this agreement. The name, address and data-protection contact are those in the order form or account. The signature and date are the customer's, and the date is the day the customer accepts.

Processor

• Name: PT Behire International Indonesia (NIB 0711250095413)
• Address: Ruko Jalur Sutera Timur 6B No. 03, Kelurahan Kunciran, Kecamatan Pinang, Kota Tangerang, Banten 15144, Indonesia
• Data-protection contact: [email protected]
• Signed by: Nicholas Andrea Sujitno, Director. The date is the day the customer accepts this agreement.

Annex II – the processing

• Whose data: your workspace members and invited people, such as employees, contractors and partners, and people named in the content you send through rooms, tasks and model calls, such as your own customers. We adjust this to your order form.
• What data: account details (name, work e-mail, sign-in identity); the content you or your bots send, such as messages, files, task data and connector data; usage and metering records (who called what, when, and the cost); and audit-log entries about actions.
• Special categories of data: not permitted unless we agree in writing. We do not ask for such data. Where a field is configured as sensitive, it is masked for people without the right clearance.
• What we do with it: receive it, store it in your own tenant, send it to a model provider or a connector's vendor on your instruction, return the result, meter the use and record an audit entry.
• Why: to provide the massrelay services you subscribe to under the agreement, and nothing else.
• How long: for the term of the agreement, then return or deletion as described above.
• Where it is stored: the hosting region and provider are stated in your order form. A change is notified in the same way as a sub-processor change.
• Where it goes next: to the model provider that handles a call, to a connector's vendor for the tasks you set up, and across our network provider. All are listed in Annex IV.
• Backups: their location, retention and encryption are stated in your order form. A change is notified in the same way as a sub-processor change.
• Retention and erasure: content and records stay for the term. The usage ledger and the audit log can only be added to and are chained so that tampering shows, so we do not erase their rows one by one. We meet an erasure request by removing or masking the personal data they carry where the design allows, and we respect any legal hold. A model provider keeps data under its own policy, shown in Annex IV.

Annex III – security measures

We list each measure by how far it is in place today. We describe the gaps in full so you can judge them.

In place

• Tenant separation: every database transaction runs inside a helper that scopes it to one tenant, and the build fails if code opens one any other way. Row-level security in the database is a second wall.
• Access control: access depends on role together with clearance, domain and organisational unit. Clearance is applied when data is read, so a move changes what a person sees on the next request.
• Sessions: sessions and tokens can be revoked, and are re-checked on each request where it matters.
• Confidentiality: sensitive fields are masked on every read by someone without privileged access. A room reply is written for the lowest clearance among its current members, and a bot answers with the lower of its own clearance and the requester's.
• Secrets: secrets are stored hashed or encrypted under a key held on the server, never in plain form. Tool output is scanned for secrets.
• Outbound traffic: calls to outside services are denied by default and allowed per tenant.
• Audit: security-relevant events are logged in a hash-chained record that shows tampering, and the chain cannot fork when several writers act at once. Reads by privileged roles are logged, and erasure respects legal hold.

Partly in place

• Scanning and redaction of instructions hidden in tool results (indirect prompt injection).
• Recognition of personal data in free text beyond listed patterns such as secrets.
• Denial by default for a tenant that has not been configured.
• Role administration as a gated, audited route with two-person approval.
• A gate on every route or tool that changes data, with an audited separation-of-duties check.
• Roles derived afresh from the scope of each request.
• Re-checking redirects against the allowed list at every hop.
• A full verification chain and a dependency audit on every code change.

Not yet in place

• Encryption in transit enforced with HSTS across all traffic. Public traffic uses HTTPS through our network provider, but we do not yet claim this measure as complete.
• A tested runbook for every class of incident.
• Automatic opening of one incident per time window when injection attempts or refused outbound calls surge.
• A checked guarantee that cache keys are always scoped to a tenant.
• A guarantee that a fact brought in from a source never gets wider clearance than that source.
• Narrowing of tool grants by the clearance of the agent using them.

Annex IV – sub-processors

You give general written authorisation to the sub-processors below. We update this list and give 30 days' notice before a change.

Model providers

A request is routed to a provider only if your routing policy allows it. What a provider keeps is its own policy.

• OpenAI (United States): keeps data for 30 days; does not train on inputs.
• Anthropic (United States): keeps data for 30 days; does not train on inputs.
• Groq (United States): provider default retention; does not train on inputs.
• Google (United States): provider default retention; trains on inputs. Not used for your data unless you accept this.
• Cohere (Canada): keeps data for 30 days; trains on inputs. Not used for your data unless you accept this.
• DeepSeek (China): provider default retention; trains on inputs. Not used for your data unless you accept this.

Any other model provider, including those whose retention terms we have not yet recorded, is not enabled for your data until its terms are recorded.

Network edge

• Cloudflare, Inc. and its group: the network edge and tunnel that carry public traffic. It operates a global network and is headquartered in the United States. Its terms are the Cloudflare Data Processing Addendum, and it publishes its own list of sub-processors.

The other components we run on our own hosting do not pass your personal data to any third party, so they are not sub-processors.

International transfers

• From the European Economic Area: where we or a sub-processor are outside it and no adequacy decision applies, the Commission's 2021/914 standard clauses, Module 2 (controller to processor), apply. You can read them in the official text.
• From the United Kingdom: the UK Addendum to the 2021/914 clauses.
• Onward transfers to the providers in Annex IV: each provider's own terms and transfer mechanism. Where a provider is certified under an adequacy framework, that applies. Otherwise the 2021/914 standard clauses do.

Law and disputes

This agreement is governed by the law of the Republic of Indonesia. The District Court of Tangerang has jurisdiction over disputes under it. Liability is subject to the limitations of liability in the main agreement.