CloakAPI is a privacy-preserving AI gateway. The architecture means we structurally cannot see prompts, responses, or model output. This page is the legal articulation of that position.
CloakAPI's gateway is a blind token relay. Personal data is tokenised on your own device — for CloakAPI Chat and the browser extension in in-browser WebAssembly, in the desktop app and the local proxy in native Rust — before the request ever reaches us, so the gateway forwards only opaque tokens and cannot see your PII in the clear. The gateway does not inspect, detect, or tokenise content on our servers; it relays what your device sends. If you point a bare SDK straight at the gateway it will blind-relay whatever you send — to keep tokenisation on your own machine with a plain SDK, run the local proxy (see the docs, Quickstart Option C). Responses are de-tokenised on your device with the per-tenant token vault that never leaves it.
Some CloakAPI suite products go further and process entirely on your device, making zero server calls while they do so. cloak-redact, for example, detects and redacts a document wholly inside your browser tab: the document is never uploaded, no request reaches our gateway during redaction, and a device-signed receipt attests that nothing left your machine. This is distinct from — and stronger than — the gateway blind-relay described above: for the on-device redaction flow there is no relay, because there is no request. (Optional actions such as subscribing to a paid plan do contact the gateway for billing only, and never carry your document.)
This means we do not collect, store, or process the substantive content of your AI traffic. We do collect the metadata required to bill, audit, and operate the service.
Zero-payload logging invariant. Our middleware refuses to write any byte of prompt or response to disk. This is enforced at the middleware layer and verified in CI on every commit. The build will not pass if a logger emits a payload field. See /trust for the technical specification.
2. What we collect
2.1 Account & billing data
Account email, organisation name, country code, billing address, VAT/tax ID.
Stripe customer reference; we do not store card numbers — Stripe is the PCI processor.
Invoice history, usage counters (tokens in/out, per provider, per API key), balance.
Prompt text or response text. The middleware will reject the request if a payload-bearing field is present in a log call.
The tenant’s token vault. It is generated client-side, encrypted with a tenant-derived key, and synced to E2E-encrypted storage that we cannot decrypt.
Biometric, special-category, or special-situation data outside what you voluntarily place in your account profile.
2.4 Website analytics
We run a self-hosted Plausible instance at analytics.cloakapi.io, located on our EU (Germany) server alongside the rest of the platform.
Plausible is cookieless and does not use cross-site identifiers, fingerprints, or persistent device IDs. Aggregated, non-personal counts only — no individual visitor profile is built.
No data leaves our infrastructure. There is no transfer to Google Analytics, Meta, or any third-party tracker.
3. Legal basis (GDPR Art. 6)
Processing
Basis
Reference
Operating the gateway under your agreement
Contract
Art. 6(1)(b)
Issuing invoices & tax reporting
Legal obligation
Art. 6(1)(c)
Fraud detection on log-in events
Legitimate interest
Art. 6(1)(f) — LIA on file
Marketing emails
Consent (opt-in)
Art. 6(1)(a) — withdraw any time
Security incident response
Legal obligation + legitimate interest
NIS2 + Art. 6(1)(c)/(f)
4. Retention windows
These windows are enforced in code by scheduled prune jobs and per-category audit-retention policies. For the full picture of every category we hold, why, and for how long, see our data map & record of processing.
Receipts & receipt chain: 7 years (tamper-evident audit anchor; legal-hold, pseudonymised on erasure).
Authentication, security, billing & privacy audit logs: 7 years, tamper-evident archive. Personal data in these rows is stored only as ciphertext under a key unique to each data subject; on erasure that key is destroyed (crypto-shredding) and only an opaque pseudonym, the action and the timestamp stay readable.
Operational (ops-category) audit logs: 90 days.
Usage metering (token counts) & raw request rows: 90 days.
Application / structured logs: 30 days (14 days for the legacy application log).
Idle dashboard & API tokens: revoked after 30 days idle.
Multi-turn tokenisation maps: 30-day sliding TTL (restarts on reuse), then purged (opt-in gateway-managed mode only; otherwise the map stays client-encrypted).
Buffered responses (tokenised): purged hourly at expiry.
Invoices & financial records: 5 years (Bokføringsloven statutory minimum + legal-hold), pseudonymised on erasure.
Signed erasure receipts: 7 years (accountability, GDPR Art. 5 + audit-trail).
Closed-account residuals: 30 days, then erased; bookkeeping rows pseudonymised.
5. Sub-processors
The full live list (14 sub-processors) and 30-day change-notification subscription is at /legal/subprocessors.
6. International transfers
The CloakAPI gateway runs in Hetzner Nuremberg (EU). We use third-country providers (Anthropic, OpenAI, etc.) as sub-processors when a user routes traffic to them; transfers are covered by SCCs (2021/914/EU module 2) and supplementary measures including client-side tokenisation on the customer's device that strips identifiers before the request reaches the gateway or any provider.
7. Data-subject rights
Under GDPR Articles 15–22, you can request access, rectification, erasure, restriction, portability, or object to processing. Registered users can run self-service export (Art. 15) and erasure (Art. 17) — each verified out-of-band and, for erasure, returning a cryptographically signed, independently-verifiable deletion receipt. Erasure in the audit log is performed by destroying your per-subject encryption key rather than by rewriting records, and because encrypted backups are retained for 30 days it is fully effective 30 days after the key is destroyed — the date stated on your receipt. See how to exercise your rights. You can also email dpo@cloakapi.io. We respond within the 30-day statutory window. The supervisory authority of record is Datatilsynet (Norway).
8. Security
Detailed security controls, key custody, encryption, vulnerability disclosure, and audit attestations are at /legal/security and security.cloakapi.io.
8a. What CloakAPI does NOT protect against
CloakAPI tokenises detected personal data before it reaches the AI provider — a real but bounded guarantee. Being explicit about its limits is part of the product. The following are out of scope; evaluate them against your own threat model. The full technical threat model is public at docs.cloakapi.io/security/threat-model.
1. The AI's own generated output. Tokenisation protects what you send. It cannot control what the model writes back, hallucinates, or reproduces from its own training data. If a model was trained on data about you, it may surface that regardless of how your prompt is tokenised.
2. The structure and context of your request. The shape, length, topic and surrounding context of a prompt still reach the AI. Higher privacy tiers redact and scramble more, but some structural / contextual signal is inherent to getting a useful answer.
3. Data outside the detector coverage. The engine covers a defined set of entity types (names, emails, phone numbers, national IDs, cards, IBANs, addresses, organisations, and similar). Sensitive data outside those categories can pass through as plaintext.
4. What the upstream AI provider does with a request. Signed receipts prove what CloakAPI did; they cannot prove an upstream provider did not log the (tokenised) request, and we cannot enforce a provider's retention policy. Review each provider's DPA, and use BYOK or complete-local mode where that matters.
5. A compromised customer device or browser. Malware, a malicious browser extension, or XSS with full DOM access can observe data before tokenisation. Tokenisation runs in your own browser context and cannot defend a device that is already compromised.
6. OS-level keyloggers or screen capture. Software that reads keystrokes or screen pixels sits below the application layer and is outside CloakAPI's threat boundary.
7. A compromise of CloakAPI's own infrastructure. CloakAPI is a trusted intermediary; a compromise of the gateway or key-management systems would break these guarantees. Customers who cannot accept that dependency can pursue a self-hosted deployment (roadmap).
8. “harvest-now, decrypt-later” quantum attacks. Current transport and signature cryptography (TLS 1.3 / ECDSA P-256) is not post-quantum secure; post-quantum migration is on the roadmap.
9. Transparency log participation is opt-in. Receipts are always cryptographically signed, but only appear in the public transparency feed if the account has opted in.
9. Changes to this policy
Material changes are announced 30 days in advance to the registered account email and at /changelog. The version history is public.