Security Model

A KeyVault Edge token (kvt_...) is a signed, encrypted envelope. It carries your provider key encrypted, together with the token's policy (allowed hosts, endpoint scope, rate limits, cost cap, expiry). Nothing in it is readable without the proxy's keys, and any change to it breaks the signature.

Because the key travels inside the token, treat tokens as credentials: keep them in environment variables or a secrets manager, use one per environment, and revoke any that leak. The host check below is what makes a leaked token far less useful.

Each token gets its own random 256-bit Data Encryption Key (DEK). The payload, including your provider key, is encrypted with the DEK using AES-256-GCM; the DEK is then wrapped with a master key (also AES-256-GCM). The whole envelope is signed with a separate HMAC-SHA256 key.

The master and HMAC keys are held as encrypted secrets in the Cloudflare Worker that runs the proxy; they are not stored with your data. Provider keys you add in the dashboard are stored encrypted the same way. Decryption happens in Worker memory per request. If decryption fails transiently, the Worker may reuse a key it decrypted recently in the same isolate, held in memory only.

Rotation without redeploying (when enabled). Newer tokens can reference your provider key instead of carrying it. The edge then reads the current key, stored encrypted in Cloudflare Workers KV under a separate key derived from the master key, and caches it in memory for up to 60 seconds. Rotating the key in the dashboard updates every such token within about a minute, with no new tokens to deploy. If the edge can't load the key, the request is refused rather than sent without it. Tokens issued before this is enabled keep working as before and still need to be re-issued when you rotate.

Each token lists the hosts allowed to use it: exact hostnames or wildcards like*.yourdomain.com. You must list at least one. After verifying and decrypting the token, the proxy compares the caller's Origin (or Referer) hostname with that list.

If the host doesn't match, the request is refused with 403, the key is not forwarded, and a breach event is recorded. This works best for browser traffic, where the browser sets Origin. A server-side attacker who has the token can send any Origin header, so for leaked tokens rely on revocation, rate limits, cost caps and endpoint scoping as well.

Every refused request (bad signature, host not allowed, expired, revoked, endpoint not permitted, rate limit exceeded) creates a breach event with the caller's IP, attempted host, location and user agent, and can trigger email, Slack and webhook alerts.

Even if an attacker tries a token from an authorized origin (e.g. they have also compromised your domain), anomaly detection watches for unusual request rates, model usage, and geographic origin shifts. Alerts fire at configurable thresholds.