Glossary

API key — a ck_live_… 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 proxies requests using the tenant’s credentials, never seeing the upstream key in plaintext.

Capability — a fine-grained model allowlist scope (e.g. gpt-4o, bedrock:claude). 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 (here, ULID). Unique receipt identifier.

JWKS — JSON Web Key Set. Public list of CloakAPI signing keys; served at /.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, Bedrock, Vertex, Azure, BYOK, …). The gateway routes requests across providers according to the routing table.

Receipt — an OpenReceipt v1 envelope sealed onto every gateway response. Verifiable months later using only the public JWKS.

Tokenisation — substitution of customer-PII strings with opaque tokens (<EMAIL_482>) before requests leave the tenant’s perimeter. The mapping table lives in the tenant’s local store; CloakAPI never sees it.