Data Processing Agreement
Version 2.7 · Last updated 2026-09-14 · supersedes v2.6 (2026-09-03)
Between TUARA KURI LIMITED (Processor) and Customer (Controller).
Effective: upon execution of a paid AgenticRail subscription.
1. Definitions
"Controller" means the Customer — the entity that determines the purposes and means of processing personal data through the AgenticRail service.
"Processor" means TUARA KURI LIMITED, a New Zealand registered company trading as AgenticRail.
"Subprocessor" means any third party engaged by the Processor to process personal data on behalf of the Controller. Current subprocessors are listed in Section 8.
"Personal Data" means any information relating to an identified or identifiable natural person, as defined in Article 4(1) of the GDPR.
"Service" means the AgenticRail API (sequence enforcement, receipt generation, compliance reporting).
"GDPR" means Regulation (EU) 2016/679.
2. Scope and Purpose of Processing
The Processor processes personal data solely for the purpose of providing the Service:
- Receiving API requests at the Wrapper endpoint
- Authenticating API keys against the Processor's database
- Evaluating enforcement decisions via the Core Worker + Durable Object
- Writing cryptographic receipts to R2 tamper-evident storage
- Generating compliance reports on request
The Controller determines what data is sent in API request payloads. The Processor does not inspect payload data beyond what is necessary for enforcement evaluation, and does not retain it except as set out in Section 7.
Type of personal data and categories of data subject
Stated here because the chapeau of Article 28(3) requires a processing contract to set out the type of personal data and the categories of data subject.
| Category of data subject | Type of personal data |
|---|
| The Controller's own personnel and end users, where the Controller chooses to include them | Whatever the Controller places in a sequence_id, in inputs, or in attestation. The Service requires personal data in none of these fields and the Processor recommends that none is sent. |
| The Controller's authorised users of the Service | Email address, API key identifier and subscription status, processed by the Processor as controller of its own account records rather than on the Controller's instruction. |
No special categories of personal data under Article 9, and no criminal-offence data under Article 10, are required by the Service or expected in any field.
3. Duration
This DPA is effective for the duration of the Controller's paid AgenticRail subscription. Upon termination, at the Controller's choice, the Processor will delete or return all personal data within 90 days and delete existing copies, unless retention is required by applicable law, in accordance with the retention schedule in Section 7. The Controller may exercise this choice by written notice to hello@agenticrail.nz prior to or at termination; absent such notice, the Processor will delete the personal data.
4. Processor Obligations
The Processor shall:
- Process personal data only on documented instructions from the Controller, including with regard to international transfers, unless required to do otherwise by applicable law (in which case the Processor will inform the Controller of that legal requirement before processing, unless the law prohibits such notice)
- Immediately inform the Controller if, in the Processor's opinion, an instruction from the Controller infringes the GDPR or other applicable data protection law
- Ensure persons authorised to process personal data are committed to confidentiality
- Implement appropriate technical and organisational measures as described in Section 6
- Assist the Controller in fulfilling data subject requests (access, rectification, erasure) where possible
- Assist the Controller in ensuring compliance with its obligations under Articles 32 to 36 of the GDPR, including conducting data protection impact assessments and prior consultation with a supervisory authority where relevant
- Notify the Controller without undue delay, and in any event within 48 hours, upon becoming aware of a personal data breach
- Make available to the Controller all information necessary to demonstrate compliance
5. Controller Obligations
The Controller shall:
- Ensure a lawful basis exists for processing personal data through the Service
- Not include special categories of personal data in API request payloads unless a specific derogation applies
- Provide necessary notices to data subjects regarding the processing
- Ensure API keys are stored securely and not exposed in client-side code or public repositories
6. Technical and Organisational Measures
The Processor implements the following measures:
| Measure | Implementation |
|---|
| Encryption in transit | TLS 1.3 for all API endpoints |
| Access control | Bearer token authentication per API key. Timing-safe comparison on all credential checks. |
| Infrastructure isolation | Enforcement core is air-gapped (no public URL). Accessible only via authenticated service bindings between Cloudflare Workers. |
| Audit trail | Ed25519-signed cryptographic receipts on every enforcement decision. Tamper-evident R2 storage, with sealed receipts copied to an independently held write-once archive. |
| Availability | Deployed on Cloudflare's global network (330+ data centers). Durable Objects provide consistent state. |
| Incident response | Personal data breaches notified to the Controller without undue delay and within 48 hours of detection (Section 4). |
7. Data Retention and Deletion
| Data | Retention | Automatic Deletion |
|---|
API request payloads (inputs) | Duration of enforcement evaluation only. The field itself never enters the Receipt. The Receipt carries payload_hash, a SHA-256 of the whole request body, and none of its content | N/A — not stored |
The attestation field | Stored verbatim inside the signed Receipt and reproduced in the compliance report. It is evidence, so it is deliberately readable rather than hashed. A demo- sequence's report needs no key, which makes anything placed there publicly readable | Follows the Receipt it forms part of |
| Enforcement receipts | Retained to preserve the integrity of the verifiable receipt chain; no tiered or automated deletion schedule currently applies | None currently — no R2 lifecycle policy is applied to production receipts; a specific retention/deletion arrangement can be agreed by contract |
| API keys (hashed) | Duration of subscription + 30 days | D1 record deletion |
| Usage logs | 90 days | Wrapper cron job (daily) |
| Client account data | Duration of subscription + 30 days | D1 record deletion |
The 90-day deletion commitment in Section 3 applies to personal data. Enforcement receipts retained beyond that period contain only enforcement metadata — cryptographic hashes, nonces, step labels, decision codes, and timestamps — and do not contain personal data from Controller payloads, which are never persisted. Where a Controller's chosen identifiers (for example, a sequence_id) could themselves constitute personal data, the Controller is responsible for avoiding the inclusion of personal data in such identifiers.
8. Subprocessors
| Subprocessor | Service | Location | Processing |
|---|
| Cloudflare, Inc. | Workers, Durable Objects, R2, KV, D1 | Global (data processed at edge) | Hosts the Service infrastructure. All enforcement execution, receipt storage, and API authentication. |
| Stripe, Inc. | Payment processing | Global | Processes subscription payments. Receives customer email and payment details. |
| Resend, Inc. | Transactional email | Global | Delivers API key welcome emails. Receives customer email address only. |
Report content. The enforcement summary in a verification report is composed by the Processor's own code from the enforcement data in the receipts. It involves no third party and no external service call, so the summary adds no subprocessor to the list above and discloses nothing beyond what the receipts already record.
The Processor will notify the Controller of any intended changes to subprocessors at least 14 days in advance. The Controller may object on reasonable data protection grounds. The current authoritative subprocessor list is the version of this DPA in force at the time of any given enforcement decision; the document fingerprint at the bottom of this page identifies that version cryptographically.
Subprocessor obligations and liability. The Processor shall impose, by written contract, data protection obligations on each subprocessor that are no less protective than those set out in this DPA, in particular the obligation to implement appropriate technical and organisational measures meeting the requirements of the GDPR. Where a subprocessor fails to fulfil its data protection obligations, the Processor remains fully liable to the Controller for the performance of that subprocessor's obligations.
9. International Data Transfers
The Processor is established in New Zealand, which has been recognised by the European Commission as providing an adequate level of data protection (Commission Implementing Decision 2013/65/EU, confirmed in the Commission's January 2024 review of the eleven adequacy decisions adopted under Directive 95/46/EC). Cloudflare processes data at the edge — the data center closest to the Controller's users. For EU-based Controllers, data is processed within the EU where possible. Where data is transferred internationally, it is protected under Cloudflare's Data Processing Addendum, which incorporates the EU Standard Contractual Clauses (SCCs) where applicable.
10. Audit Rights
The Controller may audit the Processor's compliance with this DPA by:
- Requesting the Processor's most recent security documentation
- Verifying enforcement receipts independently through the public verification portal at
report.agenticrail.nz
- Requesting a remote audit (no more than once per 12-month period, at the Controller's expense)
The Processor will provide reasonable cooperation for any audit required under Article 28(3)(h) of the GDPR.
11. Governing Law
This DPA is governed by the laws of New Zealand. Any dispute arising from this DPA shall be subject to the exclusive jurisdiction of the courts of New Zealand.
12. Execution
This DPA is incorporated into the AgenticRail Terms of Service and takes effect upon the Controller's first paid API call to the Service. No separate signature is required.
Document Fingerprint — SHA-256 — v2.7
ad2fcdbec9d6eade1cb522aec191bf13204e043da33e4a34a860d4e27c508969
Reproducible independently using any SHA-256 implementation over the pipe-delimited canonical string below.
Canonical string (UTF-8, no trailing newline):
Data Processing Agreement|2.7|2026-09-14|TUARA KURI LIMITED|GDPR|Cloudflare,Stripe,Resend|no tiered retention; receipts retained to preserve chain integrity|Ed25519|k2_2026-06-07_ed25519|New Zealand|automatic on first paid API call|AgenticRail Terms of Service v1.9
Version: 2.7 · Effective date: 2026-09-14 · Operator: TUARA KURI LIMITED · Supersedes v2.6 (2026-09-03)
v2.7 (2026-09-14): corrects how the Section 7 retention table describes the inputs field. The row said a one-way hash of it is written into the Receipt. No hash is taken of that field: inputs never enters the Receipt at all, and the Receipt carries payload_hash, a SHA-256 computed over the whole request body. The retention position itself is unchanged and was always correct, in that the values are not persisted, but the old wording attributed the hash to the field, which is the reading a data subject or a supervisory authority would take from it. The identical wording in the v2.5 note below is corrected with it, because the change log is carried forward into every later version rather than frozen at the version that wrote it. No change to processing activities, subprocessors, retention, transfers or any party's obligations. This fingerprint supersedes the v2.6 hash 26d98e4936beb9cf6da348eab8412e25876882b560d45568fe795fd7d5b6ac84.
v2.6 (2026-09-03): corrects the New Zealand adequacy citation. Section 9 cited it as “Adequacy Decision, 2012”; the European Commission's own reference is Implementing Decision 2013/65/EU, signed in December 2012 and adopted as a 2013 instrument. The claim was right and the pointer was wrong, which is the failure mode a reader cannot check around. The January 2024 review is now named for what it was. The same sentence appeared in the Privacy Policy and was corrected there at v2.9; the Section 12 cross-reference is updated to that version accordingly. No change to processing activities, subprocessors, retention, transfers or any party's obligations. This fingerprint supersedes the v2.5 hash 1ffa1f8a511289004b669327e5edab9b11ed3f83b6056c7c941b0d521d327522.
v2.5 (2026-09-03): two corrections from a fact-check sweep run against Article 28(3) itself. (1) Section 2 now states the type of personal data and the categories of data subject, which the chapeau of Article 28(3) requires a processing contract to set out and which this Agreement did not specify at all. It also records that no Article 9 or Article 10 data is required or expected. (2) Section 7 said API request payloads are not persisted. That is true of inputs, which never enters the Receipt, and was not true of attestation, which is stored verbatim inside the signed Receipt and reproduced in the compliance report by design. It now has its own row saying so, including that a demo- sequence's report needs no key. No change to processing activities, subprocessors, retention or any party's obligations: both entries describe behaviour already in place. This fingerprint supersedes the v2.4 hash 412facb064f9cdd2163cd9b13e2834dcb93e25a507988f271a1d00b9710bba41.
v2.4 (2026-09-03): updates the Section 12 cross-reference and the canonical string to Terms of Service v1.9. That version corrected three statements in the Terms and nothing in this Agreement changes as a result, but the canonical string names the Terms by version, so leaving it would have fingerprinted a reference to a superseded document. No change to processing activities, subprocessors, retention, security measures, or any party's obligations. This fingerprint supersedes the v2.3 hash 444bc856228ceadc5f227e29745025031b956980a329164cf0bac389e268eed2.
v2.3 (2026-09-02): updates the Section 12 cross-reference to API Terms of Use v3.0, which corrected a Section 9 statement that no self-serve pricing tier exists. Also narrows the canonical string's retention field from “no tiered plans” to “no tiered retention”. That field has always sat in the retention slot and always described retention, matching the Section 7 row (“no tiered or automated deletion schedule currently applies”), which is unchanged and remains true. With a published price tier now in existence the shorter phrase could be misread as a claim about pricing, which it never was. No change to processing activities, subprocessors, retention, security measures, or any party's obligations. This fingerprint supersedes the v2.2 hash 1bc5ac284ef664870ac31919a1dd0d7cc742f260232e6c46ba0ca6a3c4f96b87.
v2.2 (2026-08-11): removes the registered street address and the NZBN from the Section 1 "Processor" definition, the execution block, the fingerprint metadata and the canonical string. TUARA KURI LIMITED remains the named Processor and remains identifiable on the public New Zealand Companies and NZBN registers; notices under this DPA are given by email to hello@agenticrail.nz. Updates the Section 12 cross-references to their current versions (Terms of Service v1.8, API Terms of Use v2.9, Privacy Policy v2.8). No change to processing activities, subprocessors, retention, security measures, or any party's obligations. This fingerprint supersedes the v2.1 hash 7670894b957e20f5fefae9fbaffcf76162ef80cb9a8fad096c57df73b7dd1ecc.
v2.1 (2026-08-08): removes the AI Provider subprocessor. Verification report summaries are composed by the Processor's own code from the enforcement data in the receipts; no language model or external service is involved, so Google (Gemini API) is no longer a subprocessor and the category is retired rather than reassigned. The subprocessor list is now Cloudflare, Stripe and Resend. No change to processing activities, retention, or any party's obligations, and no personal data was ever within the removed category's scope. This fingerprint supersedes the v2.0 hash 2b43a67a3da4bd3280cd2c12235644b34c3f24a9a0bf99d5047efe31b6313498.
v2.0 (2026-07-24): corrects the description of receipt storage. Two clauses described R2 as "immutable storage", which overstates the guarantee: the primary receipt store is tamper-evident, meaning an alteration is detectable through the signature and the hash chain, and it is not write-protected. Only the independent archive bucket carries a write-once lock rule. Both clauses now say tamper-evident, and the audit-trail row records the independently held archive copy of each sealed receipt. No change to processing activities, subprocessors, retention, or any party's obligations. This fingerprint supersedes the v1.9 hash 33976762fd264192febb6828b6d73d73ea3f89251b0963dd3736b04ee9229491.
v1.9 (2026-07-08): (1) completes the v1.8 NZBN correction — the Section 1 "Processor" definition still cited the superseded NZBN after v1.8 shipped; corrected in the body text itself, not just the fingerprint block. (The NZBN was removed from this document entirely at v2.2.) (2) Removes the tiered (Free/Growth/Scale/Enterprise) receipt retention schedule from Section 7 and the "R2 lifecycle policy" automatic-deletion claim — neither exists in the deployed system. Replaced with an accurate statement: receipts are retained to preserve chain integrity, no automated tiered deletion currently applies, and a specific schedule is available by direct agreement. (3) Updates the Terms of Service / API Terms of Use cross-references (Section 12/Execution) to their current versions (v1.6 / v2.7). This fingerprint supersedes the v1.8 hash 9a9c40bf04fc8a2bd06d8844e19a56d0a90236e52fc8b6a8a77c773c1a4405f5.