Glossary

API key — a cloak_… token issued from the portal. Identifies a tenant and a capability scope.

Arbitrage — the gateway’s strategy of routing each request to the cheapest healthy provider that can serve the requested model class.

BYOK — Bring Your Own Keys. The tenant connects their own provider account; CloakAPI stores the upstream key encrypted and decrypts it in-memory only for the duration of a single request.

Capability — a fine-grained model allowlist scope (e.g. gpt-4o, claude-sonnet-4-6). API keys are issued with one or more capabilities.

Chain hash — sha256(canonical_json(previous_envelope)). Anchors each receipt to the previous one for the same tenant.

Detector — a tokeniser plug-in that recognises a specific PII pattern (email, phone, IBAN, …). The set of active detectors is part of the receipt — auditors can see which detectors fired.

JTI — JWT ID. Unique receipt identifier (random hex in v2 envelopes, UUID v7 in client-signed v3 envelopes).

JWKS — JSON Web Key Set. Public list of CloakAPI signing keys; served at https://api.cloakapi.io/api/.well-known/cloakapi-receipt-pubkeys.jwks.

KID — Key ID. Identifies which signing key sealed a receipt; matches a kid in the JWKS.

OpenReceipt — the open protocol for signed AI gateway receipts. Spec at signedreceipts.org. CloakAPI is the reference implementation.

Org / sub-org — top-level tenant; partner mode allows nested sub-organisations with their own quotas, rate limits, and balances.

Provider — an upstream LLM service (OpenAI, Anthropic, Google Gemini, xAI Grok, DeepSeek, self-hosted local via Ollama / LocalAI, or any provider you connect with your own key — BYOK — such as OpenRouter, Perplexity, or Mistral). The gateway routes requests across providers according to the routing table.

Receipt — a receipt envelope on gateway response (and, on the client-side ways, an on-device receipt can be issued). Verifiable months later — gateway receipts against the public JWKS; client-signed v3 receipts fully offline via the embedded attester key.

Tokenisation — substitution of customer-PII strings with opaque tokens (<EMAIL_482>) before requests leave the tenant’s perimeter. On the client-side ways (browser chat, desktop, extension, local proxy, SDK tokenise step) the mapping table lives in the tenant’s local store and is not sent to the gateway. The gateway does not tokenise: a request that was not tokenised on the client is refused, not tokenised for you.