Skip to content

Build on CloakAPI

CloakAPI is API-first privacy infrastructure. You don’t have to use our consumer surfaces (chat, extension, desktop) — you can build your own app or skin on top of CloakAPI and have your end users inherit the same guarantee: sensitive data is tokenised on their device, the gateway is a blind relay, and every answer carries a signed receipt anyone can verify.

This section is for the builder: the developer or company shipping a product on CloakAPI. If you just want to use CloakAPI yourself, start with the Quickstart instead.

The proposition

A product built on CloakAPI can offer its own users verifiable privacy it did not have to invent:

  1. Client-side tokenisation — personal data is replaced with realistic surrogates on the end-user’s device, before anything is sent.
  2. Blind relay — CloakAPI’s gateway forwards traffic to the upstream model (Anthropic, OpenAI, Google Gemini, xAI, DeepSeek). It never inspects or stores content, and it holds no re-identification map.
  3. Signed receipts — every response is signed with an ecdsa-p256-sha256 OpenReceipt v3 envelope, verifiable offline months later against a public key. Your users can check the evidence themselves; they don’t have to trust you or us.

You inherit all three by embedding one of the platform build-surfaces (below) — you do not re-implement the tokeniser, the detection rules, or the crypto.

The honest wording (read this before you write marketing copy)

CloakAPI’s guarantees are deliberately precise. If you build on the platform, your copy must stay inside the same lines — a “Verified by CloakAPI” build is held to them.

  • “CloakAPI never inspects or stores content.” This is always true. The gateway is a pure relay with no server-side detection engine and no content persistence. You may say this about any integration.
  • “No raw PII reaches CloakAPI.” This is true only when the client tokenised — i.e. Level-1 below. It is not true of the Level-2 convenience mode. Don’t say it unless you’re on Level-1.

Level-1 is the default. Level-2 is a labelled exception.

  • Level-1 — client-side embed (the platform story). Tokenisation runs on the end-user’s device before data leaves it — via the drop-in proxy, an SDK/WASM/ FFI, the hosted MCP server, or the starter-kit. Raw PII never egresses to your server or to CloakAPI. Build on Level-1 by default.
  • Level-2 — server-side tokenise (convenience, lower assurance). If you send raw text to a tokenising endpoint, the raw text reached a server before it was tokenised. This is offered only as an explicitly-labelled, lower-assurance convenience — never as your headline, and never described with the “no raw PII reaches CloakAPI” wording (see our platform architecture decision, ADR-0014 §2).

Enforcement vs detection — two different guarantees

These are treated differently on purpose, and your copy should reflect it:

  • Enforcement — “can a builder send raw text past the tokeniser?” Pushed to ~100%. The engine is sealed, the gateway holds key-custody, and a gateway version/hash gate means the only door to the relay is through the current current, allowlisted tokeniser. This is the strong guarantee.
  • Detection — “did the tokeniser catch every piece of PII?” This is best-effort and fail-closed. Natural-language PII detection is inherently probabilistic, so it is accepted to be asymptotically below 100%. No crypto fixes this. The engine fails closed on high-stakes secrets (it refuses to send rather than risk a leak) — but you must never claim “100% safe” or “100% detection”. That claim is itself a user-safety hazard.

Next steps

© 2026 CloakAPI · Made in the EU · Privacy · Terms · Security · Status · Trust