Data Processing Agreement Addendum: Docs Interactive Sandbox

Between: [CONTROLLER NAME] (“Controller”) And: Maelstrom AI Pty Ltd ATF Maelstrom AI Holding Trust, trading as Provii (“Processor”)

Effective Date: [DATE] Version: 1.0 Draft (Pending Legal Review)

1. Purpose and scope of this addendum

This Addendum supplements the Standard DPA and the Enterprise DPA (together, the “Principal DPA”) between the parties, by documenting the additional processing activities introduced when the Controller, or the Controller’s developers acting on the Controller’s behalf, use the Provii docs interactive sandbox at docs.provii.app/api/* and the styler iframe origin at preview.docs-sandbox.provii.app (together, the “Docs Sandbox”).

This Addendum does not amend the production processing arrangements documented in the Principal DPA. It applies in addition to them, only for the duration of the Controller’s use of the Docs Sandbox, and only to the extent the Controller’s developers, integrators, or evaluators interact with the Docs Sandbox.

Where there is a conflict between this Addendum and the Principal DPA, this Addendum prevails for the Docs Sandbox processing only.

2. Definitions

Capitalised terms not defined in this Addendum have the meaning given in the Principal DPA. The following terms are defined for this Addendum:

3. Processing details specific to the Docs Sandbox

3.1 Subject matter

The Processor operates the Docs Sandbox as a developer onboarding surface that allows the Controller’s Developers to exercise the sandbox issuer and verifier APIs through interactive widgets and an embedded API explorer, without provisioning a Controller-owned backend and without distributing production credentials.

3.2 Duration

This Addendum applies for as long as the Controller’s Developers retain access to the Docs Sandbox, and in any event until termination of the Principal DPA. Server-side state created by Docs Sandbox activity is bounded by the retention table at Section 3.5.

3.3 Nature and purpose of processing

The Processor processes personal data through the Docs Sandbox solely for the following purposes:

(a) Pre-contractual evaluation: enable the Controller’s Developers to evaluate Provii’s API contract before entering, or while extending, a commercial relationship.

(b) Sandbox session continuity: maintain session state for rate limiting, credential allowlist enforcement, and bearer-token binding through the strictly-necessary __Host-docs_session cookie.

(c) Abuse prevention: enforce per-bearer quota and abuse controls including poll ceilings, credential mint caps, Cloudflare managed challenge re-verification on bearer rotation, and Cloudflare Super Bot Fight Mode bot scoring.

(d) Operational telemetry and security audit: maintain audit and security telemetry as structured JSON log lines emitted via Cloudflare Workers Logs to Grafana Loki, with HMAC-SHA-256 redaction of sensitive identifiers performed by the gateway log_sanitizer module before any console.log emit.

(e) Legal compliance: comply with applicable laws and legal obligations.

3.4 Categories of personal data

The Docs Sandbox does not process: real dates of birth (schema-rejected at the gateway boundary), names, email addresses, identity documents, biometric data, financial information, cross-site tracking identifiers, or behavioural analytics beyond Cloudflare-managed bot scoring. The Docs Sandbox accepts only Fixture Identifiers as input for any DOB-shaped field.

3.5 Retention

These retention periods are documented in the Data Retention and Disposal Policy.

3.6 Categories of data subjects

External Developers acting on behalf of the Controller during sandbox evaluation, design, implementation, or integration maintenance. Not end consumers; not children; the Docs Sandbox is a developer-facing surface and is not directed at, or held out as suitable for, child users.

4. Lawful basis and Article 35 DPIA

4.1 Lawful basis

For Australian Developers, processing is handled in accordance with the Australian Privacy Principles (APPs), in particular APP 3 (collection only where reasonably necessary), APP 5 (notification of collection), and APP 11 (security of personal information).

4.2 DPIA

GDPR Article 35(3) mandatory criteria are not met for this surface; the Processor has nonetheless conducted a DPIA as a matter of good practice. The DPIA is published at Docs Sandbox DPIA. A child-focused DPIA assessing alignment with the UK Children’s Code is published at DPIA. Children’s Code Standard 2 (Docs Sandbox).

5. Sub-processors specific to the Docs Sandbox

The Docs Sandbox introduces or extends use of the following sub-processor services. All are operated by the Processor’s existing master sub-processors as listed at Sub-Processors.

The sub-processor relationships listed above are governed by the existing Cloudflare Data Processing Addendum referenced in the Principal DPA. The Controller is deemed to have given general written authorisation under SCC Module 2 Clause 9(a) Option 2 to the sub-processors listed in Sub-Processors. The Processor will provide at least 30 days’ advance notice of changes per the procedure documented in that page.

6. Cross-border transfers

Docs Sandbox traffic is served through Cloudflare’s global edge network and is handled at the data centre nearest the requesting Developer. Cloudflare processes this data as the Processor’s data sub-processor under the Cloudflare master DPA, which incorporates the EU Standard Contractual Clauses (Decision 2021/914, Module 2: controller to processor) for transfers out of the EEA, and the UK International Data Transfer Addendum for transfers out of the UK. The supplementary technical and organisational measures described in Section 6 of the Privacy Policy apply unchanged to the Docs Sandbox surface.

The cross-border transfer risk for Docs Sandbox processing is documented in the Risk Register under entry RISK-2026-DOCS-L01 and is reflected in the Docs Sandbox DPIA at risk R-8.

7. Security measures specific to the Docs Sandbox

The Processor implements the technical and organisational measures documented in:

• Docs Sandbox DPIA Section 4
• Statement of Applicability, in particular the ISO 27701:2019 Annex A extension section
• Unified Control Matrix entry UC-186 (Sandbox Environment Isolation: Build, CI, Runtime)
• Asset Register entries for the docs gateway surfaces and key material (CRYPTO-006, CRYPTO-007, INFRA-006, INFRA-007, KV-006, KV-007)

Key measures include strict-prefix isolation in production middleware, disjoint sandbox key material in the Cloudflare Secrets Store namespace 6e32e830825542ef86170c1b634df9e6, session cookie hardening (__Host- prefix, HMAC-signed, kid-prefixed rotation, 4-hour hard cap), schema rejection of real DOBs at the gateway boundary, CORS partitioning of the styler iframe origin via ALLOWED_DOCS_ORIGINS, Cloudflare bot protection on credential-mint endpoints, HMAC-SHA-256 hashing of source IP addresses at ingest, and a 90-day audit retention ceiling (critical security event logs are retained for up to 365 days).

8. Developer-facing transparency

The Processor publishes a Developer Privacy Notice covering Docs Sandbox processing. The Cookie Policy discloses the strictly-necessary __Host-docs_session cookie alongside the existing Cloudflare bot protection cookie disclosures. The Privacy Policy Section 2 has been updated with a sandbox developer-onboarding processing activity. ROPA Activities 2.6 (Cloudflare bot protection cookies on the docs origin) and 2.7 (Docs Gateway Session State) in the Records of Processing document the corresponding processing on the sandbox surface. Administrator-plane processing through Resend (transactional email) and Logto (administrator authentication) is recorded separately under ROPA Activities 2.8 and 2.9 respectively; those activities sit outside the Docs Sandbox boundary and are not reached by this Addendum.

9. Incident response

The incident response procedures in the Principal DPA apply to Docs Sandbox incidents. Sandbox-specific procedures, including the documented docs-sbx-* and mwallet-sbx-* KV-sweep response and the rollback runbook for sandbox-production isolation breaches, are documented in the Incident Response Playbook. The KV-sweep procedure is exercised quarterly as part of the standard sandbox issuer identity rotation rehearsal.

10. Term and termination

This Addendum takes effect on the Effective Date and continues until termination of the Principal DPA. The Controller may at any time withdraw its Developers’ access to the Docs Sandbox by written notice to the Processor; on receipt, the Processor will trigger the documented KV-sweep procedure for any session, credential, and challenge state attributable to the withdrawing Controller’s Developers.

11. Cross-references to ISMS artefacts

Document control

Status: This Addendum is published in draft as part of the Phase 0A docs sandbox uplift. Final wording is pending legal counsel review before the docs sandbox is enabled for public production traffic.