GDPR — Art 28 DPA + Art 30 RoPA published EU data plane — Hetzner Nuremberg HIPAA BAA available PCI DSS v4.0 — out of scope (SAQ-A)

Built for trust.
Provable, not just promised.

Every CloakAPI claim is backed by an artefact you can read, an attestation an auditor signed, or a cryptographic receipt your finance team can verify offline. This page is the index.

Need the full trust packet?

Available now, no NDA required: the GDPR Article 28 DPA template, the HIPAA BAA template, our Article 30 record of processing and data map, the signed SBOM, and cryptographic response receipts you can verify offline. For enterprise procurement questions, a CAIQ, or custom contract edits, contact trust@cloakapi.io.

01 — Compliance posture

Where we stand — honestly.

CloakAPI's compliance story rests on architecture you can inspect and artefacts you can verify, not badges we haven't earned. The controls are built into the design; the documents below are real and available today. We publish what exists and we don't imply certifications we don't hold.

GDPR / EU
Documents published
BasisArticle 28 DPA + Article 30 RoPA
Data planeEU-only (Hetzner Nuremberg)
Verifiable receipts
Live now
WhatEvery response signed (ECDSA P-256)
ProofVerify offline against public JWKS
HIPAA
BAA available
StatusTemplate BAA available now
NoteStructurally not BA*
PCI DSS v4.0
SAQ-A — out of scope
StatusOut of CDE by construction
WhyNo cardholder data (PAN) stored — Stripe is the card processor
Next stepNone unless we ever store PAN (not planned)

* CloakAPI offers a Business Associate Agreement template for healthcare customers. Because plaintext PHI is tokenised before reaching CloakAPI infrastructure (the structural-non-BA argument), the BAA is offered for contractual completeness even though we don't process PHI in the regulatory sense. Counter-signature flow: download → mark up → email signed PDF to legal@cloakapi.io. Read the structural argument →

If your purchasing process needs a specific artefact we don't list here — a completed CAIQ, a custom DPA edit, or an audit-letter request — contact trust@cloakapi.io and we'll work it against your decision timeline. We won't claim an attestation we don't have.

01b — Structural advantages

The thirty moats, in full.

CloakAPI's defensible advantages — properties a customer can verify cryptographically or operationally, and that competitors can't cheaply copy without rebuilding their architecture or business model. Legal characterisations are structural arguments you should evaluate with your own counsel — not legal advice.

01 · Token-level redaction at your edge

Prompts are tokenised in your perimeter — desktop, extension, chat, or the local proxy for the SDK — before they leave. On those client-side ways CloakAPI never sees plaintext PII: what crosses the wire is already redacted.

02 · No cloud AI needed to keep PII off the wire

Structured PII — emails, cards, IDs, IBANs, phones, IPs — is caught deterministically and offline on your machine, with zero AI. The privacy layer never phones home, while you still call frontier models directly.

03 · Names caught on-device

Free-form personal names are the hardest PII to pattern-match. A multilingual NER model runs on your device and catches them locally, so names never reach the wire — across the languages your team writes in.

04 · Local LLM-as-judge on your hardware

On the desktop app, an optional on-device LLM-as-judge inspects the tokenised prompt for contextual identifiers pattern-matching might miss — before any byte leaves your machine, on your hardware only, never on our gateway.

05 · Files and images extracted on-device

Documents and images are converted to text on your device — OCR plus an on-device image captioner — then tokenised like any other prompt. Raw file bytes are never uploaded.

06 · A blind relay — mathematically

Since the pure-relay flip, the gateway holds no re-identification map at all. Nothing server-side can turn tokens back into your data — not a policy promise, a property of the design.

07 · No map, no recovery

The token→value map is generated on your device and never leaves it. No one — not CloakAPI, not an upstream provider, not anyone on our infrastructure — can reverse your tokens without you. Sole custody, by construction.

08 · Complete-local: air-gap ready

Run the model on your own hardware and nothing leaves the machine — no prompts, no tokens, no metadata. The strictest environments get the same tooling and workflow with zero egress.

09 · Signed receipts on every call

Every call — successful or failed — returns an ECDSA-P-256 signed receipt over hashes, never bytes. Verifiable offline with the public JWKS. Your auditor needs no CloakAPI account.

10 · Two-party receipts: client-signed, gateway-countersigned

Every shipped client — desktop app, browser extension, portal chat and the local proxy — signs a content-free attestation of exactly what left the device (hashes and counts, never your text) with a key that never leaves that device. The gateway verifies that exact attestation, countersigns it and anchors its hash. Both signatures and the hash binding verify offline — the device signature from the receipt's own embedded key, the gateway countersignature against the published gateway key (fetch once, cache it, and every later check is fully offline). Flip a single byte on either side and verification fails.

11 · Signed status page

Status updates on status.cloakapi.io are signed and chain-linked with the same keys as the receipts, so incident history can't be silently rewritten after the fact.

12 · Zero payload retention

The gateway persists no request or response bodies — only hashes (in the receipt) and aggregate structure: provider, model, token counts. If residency matters, the default data plane runs EU-only (Hetzner Nuremberg).

13 · Zero-payload, CI-enforced

"We never log prompts or responses" is not a promise — it's enforced in middleware and verified by CI checks on every build. Re-tested on every change, not asserted once in a policy PDF.

14 · Strong data-protection jurisdiction

Operated under EEA law, so GDPR-grade statutory data protection applies by default — a structural foundation you can evaluate with your own counsel (not legal advice).

15 · Signed erasure receipts

Exercise the GDPR right to erasure and you get back a cryptographically signed erasure receipt — verifiable proof that the deletion ran, not a confirmation email.

16 · Not your HIPAA Business Associate

On the client-side ways — desktop, extension, chat, local proxy — calls are tokenised on your device before they reach us, so we hold no PHI, GDPR personal data, or regulated PII. A structural argument — evaluate with your own counsel, not legal advice.

17 · International PII coverage

Detectors cover identifiers across many languages and jurisdictions — national IDs, tax numbers, phone and banking formats — not just US patterns. Built for global teams from day one.

18 · Prompt-pool privacy on CloakAPI keys

On our pooled keys your prompts mix into aggregate upstream traffic — providers see "a CloakAPI call," not your individual usage pattern. We write up the honest residual risks in full.

19 · Open, auditable, no lock-in

The OpenReceipt spec is public; the reference implementation and the detector library are Apache-2.0. Verify receipts, audit the codepaths, even rebuild the gateway yourself.

20 · Same FIPS crypto at every layer

The same FIPS-compliant ECDSA-P-256 / SHA-256 stack signs at every layer — gateway, desktop, extension, SDKs, receipt-verifier embed, and the installer binaries. Verify any artifact with the same public-key tooling.

21 · Signed transparency reports

Per-tenant signed reports roll every receipt in a period into one artifact — usage, routing, chain checksum, downloadable manifest — signed by the same gateway key. Auditors verify against the public JWKS, no account needed. Generated automatically each quarter.

22 · Auditable invoices

Every invoice carries an evidence summary — receipt count, first/last receipt, chain root hash, a signed link to the full manifest. Each line item ties back to a real signed receipt.

23 · Cost-aware multi-provider arbitrage

Per-call routing across providers on your policy — cheapest, fastest, or EU-only. The receipt records which provider actually got the call, so it isn't a take-our-word claim. You keep the savings.

24 · Three flat rates. No tiers

15% on our pooled keys · 5% BYOK · 5% complete-local. No tiers, no subscriptions, no per-seat fees, no monthly minimums. Read the rate, plug in your volume, get an answer in 30 seconds.

25 · One vendor, no infra burden

One API, all providers, all current models. No GPU fleet, no model-update treadmill, no per-provider procurement chain, no DevOps team.

26 · Build on CloakAPI

Third parties build private-AI apps on top via a REST API, a hosted MCP server, an open (Apache-2.0) starter-kit, SDKs in eight programming languages, and a drop-in proxy — inheriting the same client-side tokenisation, blind relay and signed receipts. The REST API and proxy work today; the SDKs and hosted MCP publish to their registries at launch (build from source until then). Platform overview →

27 · Inheritable privacy — same receipts downstream

Every app built on CloakAPI ships the same OpenReceipt signed receipts — client-signed and gateway-countersigned — so a third party's end users get the same offline-verifiable proof, not a second-hand promise.

28 · Enforceable fix distribution

The gateway checks each call's declared engine version and hash against a configurable security floor — content-free metadata only, no payload inspection. Raising the floor rejects any downstream build still on an outdated tokeniser, forcing a fix through the single relay chokepoint.

29 · Metered-relay lock — the guarantee isn't optional

The SDKs, MCP server and drop-in proxy are gateway-locked to the metered relay at construction, so the privacy relay, the signed receipt and billing run on every call. A builder can't route around them to a free, unmetered, unreceipted path.

30 · Verifiable third-party builds

A public conformance suite makes a third-party integration's correctness falsifiable — does it tokenise client-side, emit and check receipts, label its assurance level honestly. Builds that pass may display a "Verified by CloakAPI" badge; issuance is self-attested and manually reviewed, not automated certification.

02 — Sub-processors

Who else is involved — and why none of them see your data.

These are the vendors that keep the CloakAPI service running. None of them receive your prompt or response content. Structured PII is tokenised on your device before anything leaves; upstream model providers get only tokenised text with no re-identification map to recover it, and infrastructure vendors never see request payloads at all. Each vendor operates under its own published Data Processing Addendum / Article 28 terms, incorporated when we accepted its service terms — we don't claim a bespoke signed DPA we don't hold.

VendorWhat it does / what it never getsRegionTerms
Anthropic Upstream model inference (Claude), when your request is routed to it. Receives tokenised text only — never your raw prompt, and never the map that would re-identify the redacted PII. US / EU Art 28 terms ↗
OpenAI Upstream model inference (GPT), when routed to it. Receives tokenised text only — never the raw prompt or the re-identification map. US / EU DPA ↗
Google (Gemini API) Upstream model inference via the Gemini API (generativelanguage.googleapis.com), when routed to it. Receives tokenised text only — never the raw prompt or the re-identification map. US / global DPA ↗
xAI (Grok) Upstream model inference (Grok), when routed to it. Receives tokenised text only — never the raw prompt or the re-identification map. US xAI terms ↗
DeepSeek Upstream model inference (DeepSeek), when routed to it. Receives tokenised text only — never the raw prompt or the re-identification map. Hosted in China; disclosed here for transparency — only tokenised text ever reaches it. China (PRC) DeepSeek terms ↗
Stripe Billing, invoicing and card tokenisation. Receives billing and account data only — never your prompts or responses. No card numbers (PAN) touch CloakAPI. EU (Stripe Payments Europe) DPA ↗
AWS (SES) Transactional and inbound email only — Simple Email Service, an inbound-mail S3 bucket and mail-forwarder Lambdas. Handles email delivery; never prompt or response payloads. No AWS compute or hosting is used. eu-north-1 (Stockholm) DPA ↗
Cloudflare Authoritative DNS only (grey-cloud). Resolves our hostnames; no proxy, no CDN, no WAF, no TLS termination — connections go straight to the EU origin and TLS terminates there. Sees DNS lookups, never request content. Anycast DNS DPA ↗
Hetzner Hosts the blind relay gateway — receipt-signing, public JWKS, billing metadata, staff audit log. No customer prompts or responses: tokenisation runs on the device before egress and the zero-payload invariant is enforced in CI. Nuremberg, DE DPA ↗

This is the high-impact subset — the vendors that touch a live request path or hold account data. The full live sub-processor list, with region, purpose and 30-day change-notification subscription, is published at /legal/subprocessors. Customers can subscribe at trust@cloakapi.io for 30-day advance notice of any change.

03 — Receipts → independent verification

You don't have to trust us.

Every gateway response carries a cryptographic receipt signed under the OpenReceipt spec (ECDSA P-256). You — or your auditor — can verify any receipt offline using the public JWKS hosted by signedreceipts.org. No CloakAPI account required.

Verify a receipt

Paste any signed receipt JSON. The verifier checks the signature against the published JWKS, validates the canonical hash chain, and shows you exactly which upstream model was used, when, and under what privacy tier — without sending the receipt back to us.

04 — Transparency log

Per-tenant, append-only, public seed feed.

CloakAPI publishes a per-tenant transparency log: an append-only feed of cryptographic seeds that lets any verifier confirm CloakAPI never silently rotated a tenant's signing key, never silently changed routing policy, and never ran a "shadow" tenant against the published spec.

Live endpoint

The seed feed is JSONL, append-only, and signed under the same ECDSA P-256 keys as receipts. Tenants opt in or out per-environment from settings.

GET https://api.cloakapi.io/v1/transparency/seeds.jsonl

05 — Incident response & status

Live state, in public.

Service availability and incident postmortems are published openly. Vulnerability reports go to a coordinated disclosure programme with a public hall of fame.

Live status

Per-region, per-component health for the gateway, portal, desktop sync, and transparency log. SEV-3+ incidents trigger a public postmortem within 5 business days.

Vulnerability disclosure

Coordinated-disclosure policy, scope, safe-harbour terms, response SLAs, and a public hall of fame for researchers who help us harden the platform.

07 — Insurance

Cyber liability & E&O coverage.

Cyber liability and errors & omissions (E&O) insurance is not currently carried. If your procurement process requires a Certificate of Insurance, contact trust@cloakapi.io — coverage can be bound as part of an enterprise engagement. Full insurance status →

08 — Contact

Talk to a human.

Procurement, security review, custom DPA edits, or audit-letter requests — any of the addresses below reach a real person, not a queue.

Trust & compliance

DPA, HIPAA BAA, CAIQ, audit letters, sub-processor questions.

Legal & DPA

DPA counter-signing, contract redlines, data-residency commitments.