CloakAPI is a blind token relay: on the standard client-side paths, the personal data our on-device detectors identify in your AI prompts and responses is tokenised on your device before it reaches us, and the gateway never sees those values in the clear. (Detection is dictionary- and model-bound, so free-form names outside the on-device dictionary can be missed — structured identifiers such as IDs, card numbers, IBANs, phone numbers, emails and dates are the deterministic lane.) So the honest answer to “what do you hold about me?” is a small, mostly-non-sensitive footprint — account and auth, billing and wallet, token-count metering, receipt metadata (hashes, not content), hashed or short-lived logs, and org/partner records. This page maps every category, and doubles as our GDPR Article 30 record of processing.
Controller: CloakAPI AS, Org no. 933 720 411 (Norway) · DPO: dpo@cloakapi.io · Derived from code (retention windows are enforced by scheduled jobs)
The one-line summary
On the standard client-side paths, your AI prompt and response content is tokenised on your device before it reaches our gateway — we never receive raw personal data in it. On that architecture, many customers conclude we are not a processor of that content — evaluate this with your own counsel (not legal advice). Zero-payload logging is enforced in code — the structured logger throws before it can write a prompt, message, body or content field. The only content-adjacent state we hold is transient and either client-encrypted or tokenised, auto-purged within 30 days (multi-turn maps) or hourly (buffers).
Legend.no personal data counts / config / crypto material. pseudonymous hashed or opaque reference, re-identifiable only with information held separately. personal data identifies or relates to a person.
1. Account, identity & authentication
Category
What it is
Why
Retention
Class
User account
Name, email, password hash, company, country code
Account, login, invoicing identity
Account lifetime; anonymised on erasure
personal
Password reset tokens
Email + token
Password reset
Short-lived; deleted on erasure
personal
Sessions
User id, IP, user-agent, last activity
Web session
Session lifetime; deleted on erasure
personal
Dashboard / API tokens
Hashed personal-access tokens
Portal auth
Revoked after 30 days idle; deleted on erasure
pseudonymous
API keys
Key hash only (never plaintext), prefix, permissions, rate limits, allow-lists
Opaque request id, SHA-256 of the erased user id, counts/booleans, signed envelope. Never stores plaintext PII.
Article 17 deletion proof
7 years (accountability + audit trail)
pseudonymous
5. IP, request & audit logs (hashed or short-lived)
Category
What it is
Why
Retention
Class
Application / structured logs
Structured JSON. Zero-payload enforced — the logger throws before writing any body / payload / content / prompt / message field.
Observability
30 days (14 days for the legacy application log)
no personal data
Audit logs
Readable in clear: an opaque pseudonym (subject_id, e.g. user:3248), action, resource type/id, result, retention category, timestamp and the chain fields. No plaintext personal data is stored — user id, IP address, user-agent, external resource id and metadata are sealed into a single AES-256-GCM ciphertext under a random per-data-subject key, the corresponding plaintext columns are NULL, and a database trigger rejects any insert that tries to set them. Hash-chained + anchored. The residual pattern of who acted when (the pseudonymous “behavioural shadow”) is deliberately retained — it is what keeps the log usable as a security log.
Security / compliance audit trail
Per category: auth / billing / security / privacy / default 7 years (tamper-evident archive); ops 90 days. Erasure is crypto-shredding: the subject’s key is destroyed, the stored row bytes never change, and the ciphertext becomes permanently unopenable by anyone including us. The erasure itself is recorded as two new appended chain events; nothing is rewritten. Because backups are retained 30 days, a shred is fully effective 30 days after the key is destroyed, and the erasure receipt states that effective-completion date.
personal
Rate-limit / signup-risk IP use
IP used transiently for rate-limit key + signup risk; signup stores a salted SHA-256 hash, never plaintext
Abuse prevention
Cache TTL / hashed
pseudonymous
Marketing / campaign analytics
ip_hash (salted SHA-256 — never plaintext IP), UA family/OS, UTM; outreach targets (email), suppression hashes
Cold-outreach + attribution
Email deleted / anonymised on erasure; suppression hashes retained as a lawful-basis record
personal (target email); IP hashed
6. Org, partner & tenant data
Category
What it is
Why
Retention
Class
Organisations & membership
Org name/slug/plan/settings; members, role assignments, invitations (email), permissions
Multi-tenant / team access
Org lifetime; self-service deletion + grace; invitations deleted on erasure
personal (invite emails)
Partner / reseller
Partner accounts, sub-orgs, commission ledger, settlements, tax forms, agreement-signed IP
Partner programme
Commission / settlement + tax = financial legal-hold class
We would rather over-disclose than let “we hold no content” read as an absolute it is not. Two gateway-side stores can touch content, and both are strictly transient: the map uses a 30-day sliding TTL (restarts on reuse); the buffer is purged hourly:
Store
What it holds
Retention
Class
Multi-turn tokenisation maps
Token↔value maps for multi-turn tokenisation. In client_held mode only an opaque client-encrypted ciphertext is stored. In the opt-ingateway_managed mode the value is stored AES-256-GCM encrypted (not in the clear at rest).
30-day sliding TTL (restarts on reuse), then purged
Tokenised response text held for async retrieval — the gateway never sees decrypted PII
Purged hourly at expiry; deleted on erasure
Tokenised (no clear PII)
Neither is populated with clear PII on the standard pure-relay paths. The gateway_managed mode is opt-in only; unless you choose it, multi-turn maps stay client-encrypted and we cannot read them.
8. Public transparency log (hashes only)
The public transparency log stores a SHA-256 of the tenant id (never the tenant id in the clear), seed HMACs, and chain material. No personal data.
You can export everything we hold about you (Article 15) or have it erased (Article 17) — registered users can do both self-service, verified out-of-band. Erasure runs within the 30-day statutory window and produces a cryptographically signed, independently-verifiable deletion receipt. Financial records are retained under legal-hold (7 years) in pseudonymised form. Audit records are retained too, but your personal data in them is erased by crypto-shredding — the per-subject encryption key is destroyed rather than the record rewritten. Because encrypted backups are retained 30 days, that shred is fully effective 30 days after the key is destroyed; the receipt states that date. Everything else is deleted or anonymised. See how to exercise your rights.
11. GDPR Article 30 — record of processing activities
This section is CloakAPI's Article 30 record for the processing it carries out as a controller of the operational data above. (For customer AI content on the standard paths, that content is tokenised client-side and does not reach us in the clear; on that architecture many customers conclude CloakAPI is not a processor of it — evaluate this with your own counsel, as this is not legal advice.)
Art. 30 element
Record
Controller
CloakAPI AS, Org no. 933 720 411, Norway
Data protection contact
dpo@cloakapi.io
Purposes of processing
Providing the AI gateway under contract; authentication and account management; metering and billing; issuing statutory invoices; tamper-evident audit and receipts; security incident response and abuse prevention; consent-based marketing; enterprise compliance features
Identity/contact (name, email, company); authentication material (hashes, tokens); billing/wallet records + Stripe refs + card fingerprint; token-count metering (no content); receipt and audit metadata (hashes); IP addresses (sealed under a per-data-subject AES-256-GCM key in the security audit trail — never stored there in plaintext; hashed elsewhere); org/partner records incl. signed-agreement IP and tax identity. No special-category data is required; AI prompt/response content is tokenised client-side and out of scope on the standard paths.
Categories of recipients
Sub-processors on the published list (payment processor Stripe; hosting; email; GRC evidence tools). See sub-processors.
Third-country transfers
Gateway hosted in Hetzner Nuremberg (EU). AI providers act as sub-processors only when a user routes traffic to them; transfers covered by EU SCCs (2021/914 Module 2) + UK IDTA, with tokenisation as a supplementary measure. See EU regulatory applicability.
Retention periods
As per the retention schedule in section 9.
Technical & organisational measures
Client-side tokenisation before the gateway; code-enforced zero-payload logging; hashed/short-lived IP handling; encryption at rest for the opt-in gateway-managed map; hash-chained tamper-evident audit logs and receipts (ECDSA-P256), with audit-log personal data sealed under a random per-data-subject AES-256-GCM key and erased by crypto-shredding that destroys the key rather than rewriting the record; a reason-and-operator-logged break-glass read path that records its own audit event before disclosing anything and returns SHREDDED after an erasure; Sanctum-authenticated portal; per-category retention with scheduled prune jobs; signed erasure receipts stating the 30-day effective-completion date. Full detail in the security overview.