DPIA: Docs Interactive Sandbox

Assessment Overview

1. Description of Processing

Nature

The docs interactive sandbox is the developer onboarding surface attached to docs.provii.app. It allows external developers to exercise the sandbox issuer and verifier APIs through interactive widgets embedded in the documentation, without provisioning their own backend or distributing real production credentials. The surface is composed of:

• Gateway endpoints under docs.provii.app/api/*, hosted on the provii-demos/demo-web-provii-agegate Worker with a narrowed DocsEnv binding set (no DEMO_TOKEN_SECRET, no playground KVs).
• Credential generators. POST /api/credentials/issuer and the verifier-credential mint route. that provision sandbox-scoped issuer and verifier client IDs into the SANDBOX_DOCS_ISSUERS allowlist.
• API explorer. Scalar-rendered interactive API reference embedded in the docs site, calling sandbox endpoints with bearer tokens issued by the gateway.
• Styler iframe at preview.docs-sandbox.provii.app, a separate origin that renders interactive sandbox widgets and is governed by a dedicated ALLOWED_DOCS_ORIGINS CORS list.

The sandbox is deliberately disjoint from production. Production middleware rejects any docs-sbx-* prefix across body, path, query, and authorisation headers. The gateway issues a strictly-necessary __Host-docs_session cookie that binds session state to the requesting browser.

Scope

Context

Developers interact with the sandbox to learn the API contract before integrating their own backend against the production verifier. The sandbox accepts fixture IDs only (11 named synthetic test users) for any DOB-shaped input. Real DOB strings submitted to /v1/register-test-issuer-client are schema-rejected and the rejection is logged as a suspicious event. By design, there is no intended path by which production end-user PII can enter the sandbox.

The gateway sits behind Cloudflare bot protection (Bot Fight Mode, Cloudflare managed challenge on credential-mint routes), which sets __cf_bm and conditionally cf_clearance cookies. These are processed by Cloudflare as an infrastructure sub-processor under the existing DPA and SCCs.

Purpose

Enable developer onboarding without distributing production credentials, without provisioning per-developer backends, and without exposing the production attestation seed. Provide an interactive learning surface that mirrors the production API contract closely enough to support real integration work.

Data Processed

Data NOT processed:

• Real dates of birth. schema-rejected at the gateway boundary.
• Names, email addresses, identity documents, biometric data, financial information.
• Cross-site tracking identifiers.
• Behavioural analytics beyond Cloudflare-managed bot scoring.

2. Necessity and Proportionality

Article 35(3) Threshold Assessment

Conclusion: GDPR Art. 35 mandatory criteria are not met. This DPIA is conducted as good practice because the gateway introduces a new (albeit minor) processing activity, a new cookie under Maelstrom AI’s first-party origin, and a new credential issuance surface that warrants documented risk treatment.

Lawful Basis

Data Minimisation

• The gateway accepts fixture IDs only for any DOB-shaped input. Real DOB strings are schema-rejected.
• The session cookie carries only session_id and the HMAC; no profile, no identifier beyond what is needed to bind state to the browser.
• The narrowed DocsEnv binding excludes DEMO_TOKEN_SECRET and the playground KVs, so the gateway has no access to production credentials or playground state.
• Cloudflare bot cookies are processed by Cloudflare with their own retention; Maelstrom AI does not duplicate or persist them.

Storage Limitation

Purpose Limitation

Sandbox-issued credentials are designed not to reach production. The production middleware rejects docs-sbx-* prefixes across all input surfaces (body, path, query, authorisation header). Sandbox attestations are signed by DOCS_ATTESTATION_ED25519_SEED, which is distinct from every production attestation seed. No key material is shared between sandbox and production by design.

3. Risk Assessment

Risk treatment for the docs sandbox is tracked in the Risk Register under the RISK-2026-DOCS-* series and aligned to the relevant SOA controls. The control matrix tracks the docs sandbox gateway under UC-186 (Sandbox-Production Isolation). See the related sandbox isolation requirements in the docs gateway entries of the Asset Register.

4. Measures to Address Risks

Technical Measures

1. Strict-prefix isolation. Production middleware in the verifier API rejects any inbound request whose body, path, query, or Authorisation header contains a docs-sbx-* or mwallet-sbx-* prefix. The check runs before any handler-specific validation and is covered by negative tests.

2. Disjoint sandbox key material. DOCS_ATTESTATION_ED25519_SEED is held in the Cloudflare Secrets Store (internal namespace), distinct from every production attestation seed. The seed is never materialised as a JS string; it is held only within the AttestationSigner closure at src/docs/attestation-signer.ts.

3. Session cookie hardening. The __Host-docs_session cookie uses the __Host- prefix (path=/, secure, no domain attribute), is HMAC-signed by DOCS_SESSION_HMAC_KEY with a kid prefix supporting rolling rotation, and binds session state to a 4-hour hard cap.

4. Schema rejection of real DOBs. The /v1/register-test-issuer-client endpoint enforces a schema that accepts only fixture IDs (fix-1 … fix-11). Submissions matching DOB shapes (ISO 8601 dates, YYYY-MM-DD strings, integer dob_days outside the synthetic range) are rejected with 400 and logged as suspicious.

5. CORS partition. The styler iframe at preview.docs-sandbox.provii.app is governed by ALLOWED_DOCS_ORIGINS, distinct from the playground CORS allowlist. No cross-allowlist origin is permitted to authenticate against the docs gateway.

6. Bot protection. Cloudflare Bot Fight Mode plus Cloudflare managed challenge on credential-mint endpoints. Per-IP and per-session rate limits enforced via the gateway’s KV-backed rate counters.

7. IP hashing. Developer IP addresses are hashed with HMAC-SHA-256 keyed by PII_HASH_KEY at the ingest boundary. Raw IPs are not persisted.

8. Audit retention ceiling. 90-day audit retention applies to all gateway request logs, key-use events, and credential-mint events; critical security event logs are retained for up to 365 days. KV TTL enforces deletion.

Organisational Measures

1. Quarterly key rotation. DOCS_SESSION_HMAC_KEY and DOCS_ATTESTATION_ED25519_SEED rotate on a 90-day cadence, coordinated with the shared sandbox issuer identity rotation tracked under asset CRYPTO-003.

2. Compromise response procedure. KV-sweep documented for both docs-sbx-* and mwallet-sbx-* prefixes via wrangler kv:key list --remote --prefix <prefix> followed by sweep delete. Response procedure tested as part of the quarterly rotation rehearsal.

3. Schema-rejection log review. Suspicious DOB-shape rejection events are surfaced into the weekly audit review queue; clusters of rejections are escalated as potential developer privacy issues.

4. Developer-facing privacy notice. A separate developer privacy notice is published at /legal/developer-privacy-notice (drafted; pending legal counsel review before production launch). The main privacy policy gains a sandbox developer-onboarding processing activity. The cookie policy discloses __Host-docs_session alongside the existing Cloudflare cookie disclosures.

5. DPIA review trigger. This DPIA is reviewed annually, on material change to the gateway surface, on engagement of a new sub-processor, and on any incident touching the sandbox-production boundary.

5. Consultation

Data Protection Authority Consultation

Article 36 prior consultation is not required. No high residual risks remain after mitigation. The processing is small-scale, pseudonymous, and developer-facing, with disjoint key material and strict schema rejection of real DOB inputs.

Stakeholder Consultation

1. Developers (data subjects): Will be informed via the developer privacy notice and the cookie banner on the docs site disclosing the strictly-necessary __Host-docs_session cookie alongside the Cloudflare bot protection cookies.
2. Cloudflare (sub-processor): Existing DPA covers the bot protection cookies and the Workers infrastructure hosting the gateway. No new sub-processor relationship is created.
3. Internal. ISMS Owner, Security Lead, docs DX team. Reviewed as part of Phase 0A of the docs DX uplift programme.

6. Conclusion

The docs sandbox gateway introduces a low-risk developer onboarding surface that processes pseudonymous developer session state, hashed IP addresses, and Cloudflare-managed bot protection cookies. Real personal data is excluded by design through schema rejection of DOB inputs, fixture-only credential synthesis, and disjoint sandbox key material.

Key findings:

• GDPR Art. 35(3) mandatory DPIA criteria are not met. This DPIA is conducted as good practice.
• All identified risks (R-1 through R-11) reduce to Low or Medium residual after mitigation. No high residual risks remain.
• The sandbox-production boundary is enforced both at the protocol layer (strict-prefix middleware) and at the cryptographic layer (disjoint Ed25519 seeds).
• Developer-facing transparency is delivered through a dedicated privacy notice and an updated cookie policy.

Determination: Processing may proceed. No prior consultation with the supervisory authority is required under Article 36.

Reassessment Triggers:

• Material change to the gateway surface (new endpoints, new cookies, new credential prefixes)
• Engagement of a new sub-processor on the docs origin
• Any incident touching the sandbox-production boundary
• Regulatory change affecting developer-data processing under GDPR or the Australian Privacy Act
• Material change to fixture-input rejection logic

Document Information