CloakAPI is a privacy-preserving AI gateway. The architecture — client-side tokenisation, signed receipts, zero-payload server logging — is what does the regulatory work. This page describes only the controls and artefacts that exist right now, not certifications we haven't engaged. For audit roadmap and per-framework status, see the Trust Center.
PCI DSS v4.0 is out of scope (SAQ-A) — Stripe processes cards, so no cardholder data touches CloakAPI. The GDPR Article 28 DPA is available now. On the client-side ways, plaintext PHI is tokenised on the customer's device before the prompt reaches us and the gateway is a blind token relay that forwards only those tokens (it does not inspect or tokenise content on our servers), so detected PHI is already pseudonymised before it reaches our infrastructure. Detection is best-effort — undetected text still crosses in the clear — and CloakAPI is a data-minimisation tool, not a HIPAA-compliance product.
Every claim below is backed by an artefact you can read or a control you can exercise from a customer account today. Where a formal certification is the only way to satisfy a control, we say so explicitly rather than implying coverage.
For each common audit ask, here is the artefact or feature that satisfies it now — and the path you'd cite in a procurement questionnaire.
| Audit ask | What CloakAPI ships | Where |
|---|---|---|
| PII / PHI redaction | Client-side tokenisation on the user's device (Rust/WASM regex + structured-ID engine plus on-device name matching — a name dictionary today, with an optional downloadable on-device model; native Rust in the desktop app and local proxy). The gateway is a blind token relay: it forwards only the client's tokens and never inspects or tokenises content on our servers. Configurable detector packs per tenant; deterministic re-detokenisation on the device. | privacy model |
| Cryptographic non-repudiation | Every gateway response carries a receipt signed under ECDSA P-256. Public JWKS published; offline verifier requires no CloakAPI account. | spec · verifier |
| Key-rotation transparency | Per-tenant append-only seed feed (JSONL, signed under the same P-256 keys). Lets any verifier confirm we never silently rotated a tenant's signing key or shadow-swapped routing policy. | GET /v1/transparency/seeds.jsonl |
| Audit trail & export | Append-only, tenant-scoped audit log of every staff and customer action against the gateway and portal — insert-only (update/delete triggers reject writes), SHA-256 hash-chained, daily ECDSA-P256 anchor. Personal fields are stored only as AES-256-GCM ciphertext under a per-data-subject key; erasure destroys the key (crypto-shredding) and is itself appended as new chain events, so tamper-evidence survives erasure. Operator break-glass reads are console-only, require a stated reason and named operator, and are recorded in the chain before any disclosure. CSV export from the admin console. | app.cloakapi.io/admin/audit |
| Data residency | Gateway, signing infrastructure, billing metadata and audit log run in Hetzner Nuremberg (DE). Cloudflare edge is EU-pinned. Upstream model providers carry their own DPAs and Article 28 clauses. | Trust → Sub-processors |
| Sub-processor change notice | 30-day advance email notice of any sub-processor addition or replacement; subscribe to the list at trust@cloakapi.io. | /legal/subprocessors |
| Incident response & status | Per-region, per-component health page. SEV-3+ incidents trigger a public postmortem within 5 business days. Coordinated vulnerability disclosure programme with safe-harbour terms and public hall of fame. | status.cloakapi.io · security.cloakapi.io |
| Business continuity / DR | Architecture, backup strategy, RTO 4h / RPO 6h, annual DR drill. Plan published openly. | /legal/bcp |
| CSA self-assessment | CAIQ-lite mapped to Cloud Controls Matrix v4 across 50 controls. Updated on each architectural change. | /legal/caiq |
The components that decide whether your data ever leaves the device — detection, tokenisation, receipt signing — run on your own device where you can inspect them, or are openly specified. You don't have to take CloakAPI's word for what they do.
Direct-identifier detection and tokenisation run entirely on the user's device — a Rust/WASM regex + structured-ID engine (native Rust in the desktop app and local proxy) plus on-device name matching — a name dictionary today, with an optional downloadable on-device model — before any network egress. The gateway is a blind token relay: it forwards only the tokens your device produced and never inspects, detects, or tokenises content on our servers. Configurable recognisers for direct identifiers, named entities, financial PAN, healthcare codes.
P-256 ECDSA-signed receipts with canonical hash chaining. Independent verifier hosted at signedreceipts.org. The spec and public JWKS are published; reference-implementation source distribution is in preparation at signedreceipts.org/source.
Compliance is one slice of the trust story. The Trust Center has the full picture — attestations roadmap, sub-processors, transparency log, incident history. Procurement-style questionnaires (CAIQ, SIG-lite, custom RFP) go to trust@cloakapi.io.
Attestations roadmap, sub-processors, receipts, transparency log, incident response and the legal artefact index.
CAIQ-lite, custom DPA edits, audit-letter requests, sub-processor questions.