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 runs in your perimeter — typically in the browser, the desktop client, or a server-side SDK before the request leaves your infrastructure. The mapping table (<EMAIL_482> → alice@…) lives in your local store; we never see it.

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-eu-west-2026-04, gw-eu-west-2026-07, …). Old keys remain in the JWKS so historic receipts continue to verify.

What we publish

• Public JWKS at /.well-known/cloakapi-receipt-pubkeys.jwks
• Public PEM at /.well-known/cloakapi-receipt-pubkey.pem
• Tokeniser binary attestations at /.well-known/openapi.json
• security.txt and disclosure policy at security.cloakapi.io
• Build provenance (planned, post-GH-org) at /.well-known/slsa-provenance.intoto.jsonl