How privacy works

CloakAPI’s threat model assumes the gateway operator is also a potential adversary. So the gateway is designed so that even a fully-compromised gateway cannot reveal customer plaintext, because the plaintext was never delivered to the gateway in the first place.

Where tokenisation happens

Tokenisation happens on your own device — on the client-side ways: the browser chat, the desktop app, the browser extension, and the local proxy. Personal data never leaves your machine; the gateway receives only opaque tokens. The gateway itself is a blind token relay: it forwards what your device sends and never inspects, detects, or tokenises content on our servers. That also means a bare OpenAI/Anthropic SDK pointed straight at api.cloakapi.io is blind-relayed as-is — it is NOT tokenised by us. To tokenise with a plain SDK, run the local proxy (see Quickstart Option C) so tokenisation happens on your own machine before the request reaches us.

Way	Entry point	Where PII is tokenised	Receipt & billing today
Local proxy (SDK drop-in)	`http://localhost:8799/v1`	Your machine (gateway-locked: tokenised request relays through the gateway)	CloakAPI receipt + markup
Desktop app	app UI	Your machine (native Rust engine)	via gateway
Browser extension	in-page (claude.ai, chatgpt.com, gemini.google.com, grok.com)	Your machine (in-browser WASM)	via gateway
Browser chat	app.cloakapi.io	Your device (in-browser WASM + NER)	CloakAPI receipt
Bare SDK → gateway	`https://api.cloakapi.io/api/v1`	Not tokenised by us — blind-relayed as-is (use the local proxy for on-device tokenisation)	CloakAPI receipt + markup

On every path the gateway is a blind token relay: it forwards only what your device sends and does not inspect, detect, or tokenise content on our servers. When you use a client-side way, the gateway cannot see raw PII in the clear, because tokenisation happened on your device before the request ever reached us.

Names need a model; those paths fail closed. Structured PII — emails, phones, cards, national IDs, IBANs, IP addresses (~10 types) — is detected deterministically with no model, always on. Free-form personal names (and orgs/addresses) need a model: an on-device name dictionary today (with an optional downloadable model) for the chat and extension, an optional on-device mini-AI (e.g. Phi via Ollama) for the local proxy, and an optional local sidecar for the desktop app. By default, if that name model is unreachable the request fails closed rather than let a name leak.

The mapping table (<EMAIL_482> → alice@…) lives in your local store on the client-side ways; the gateway never receives it.

On the client-side ways the gateway only sees the structure of a request:

{
  "messages": [
    {
      "role": "user",
      "content": "Summarise the email from <EMAIL_482> about <PROJECT_19>."
    }
  ]
}

What we log

The gateway records the shape of every request — provider, model, token counts, latency, status — and a hash chain of receipts. We do not log:

request bodies,
response bodies,
tokenised content,
tokenisation maps.

Receipts are content-addressable hashes; a receipt does not let anyone reconstruct the underlying messages.

What we sign

Every response is signed with an ecdsa-p256-sha256 envelope chained to the previous response for the same tenant. The signing key is rotated quarterly (gw-prod-2026-q2, gw-prod-2026-q3, …). Old keys remain in the JWKS so historic receipts continue to verify.

What we publish

Public JWKS at https://api.cloakapi.io/api/.well-known/cloakapi-receipt-pubkeys.jwks
Public PEM at https://api.cloakapi.io/api/.well-known/cloakapi-receipt-pubkey.pem
OpenAPI spec at https://docs.cloakapi.io/openapi.json (and .yaml)
security.txt and disclosure policy at security.cloakapi.io
The OpenReceipt v3 specification, reference verifiers, and conformance suite at signedreceipts.org — see Reproducibility
Build provenance (planned — SLSA roadmap, see Reproducibility) at /.well-known/slsa-provenance.intoto.jsonl