What we defend. What we don't.
Every security tool has a threat model. Most vendors don't publish theirs because it's easier to sell a vague promise. Here's ours, in plain English, with nothing omitted.
What KeyVault Edge defends against
API keys leaking into public source code
The real provider key never needs to be in your code, CI or app config: only an encrypted token is. If a token leaks, requests from hosts outside its allowlist are refused, and you can revoke it without rotating the provider key.
Keys leaking from browser bundles, mobile apps, and desktop software
Tokens are only honoured for requests whose Origin matches an allowed host. A token copied out of a web page can't be used from another site in a browser. A server-side script can spoof Origin, which is why the controls below exist too.
Single stolen credentials being used at scale
Tokens can carry per-minute, per-hour and per-day rate limits, a monthly cost cap and an endpoint scope. Refused requests are logged as breach events and can alert you by email, Slack or webhook.
Lost control after a compromise
Revoking a token in the dashboard adds it to the edge's revocation list, after which the proxy refuses it. A break-glass kill switch revokes every token for an organisation at once.
What it does not defend against
Being explicit about limits is what separates a security tool from security theatre. These are the adversaries and scenarios we do not claim to stop.
A compromise of the running client that authored the request
If an attacker controls the browser tab or mobile app that holds a valid KeyVault Edge session, they can make legitimate calls from it. We make key theft less valuable; we cannot replace endpoint security.
A compromise of the upstream API provider
If OpenAI, Stripe, or GitHub is breached, your data at that provider is affected independently of us. KeyVault Edge protects the credential, not the provider.
A server-side attacker who has a token and knows an allowed host
Host-binding checks the Origin/Referer header. A server can set those to anything, so a leaked token used from a script that spoofs an allowed host gets through. Rate limits, cost caps, endpoint scoping, anomaly alerts and revocation are the controls for that case.
A compromise of our edge master key
Tokens carry the provider key encrypted under keys held as Cloudflare Worker secrets. Someone who obtained those secrets and your tokens could decrypt them. Customer-managed keys, which would remove us from that path, are on the Enterprise roadmap and not live yet.
Determined nation-state attackers with physical access to edge hardware
Our encryption is strong against software adversaries. We do not claim hardware-level protection against adversaries who can physically seize edge nodes.
Key hierarchy
Where each piece of cryptographic material lives, who can touch it, and how they relate. No step trusts the one below it more than it must.
Provider API key (plaintext)
Sent once from the dashboard to our server over TLS when you add it.
Encrypted on the server with AES-256-GCM before it is stored. It is never shown again or logged.
Data key (DEK)
Generated per token (Web Crypto, 256-bit random).
Encrypts the token payload (provider key + policy) with AES-256-GCM, then is itself wrapped by the master key.
Master key
An encrypted secret in the Cloudflare Worker (and the dashboard's server environment).
Wraps every DEK with AES-256-GCM. Not stored in the database. Customer-managed keys (KMS) are on the Enterprise roadmap.
Token (kvt_...)
Issued to you in the dashboard; sent by your app in the X-KV-Token header.
Version byte, wrapped DEK, nonces and encrypted payload, signed with HMAC-SHA256 under a separate HMAC key. Cannot be altered without the HMAC key. Treat it as a credential.
Request flow
What the edge proxy does on every request, in order. Request bodies are forwarded unchanged and not logged; JSON responses are read off the response path only to meter token usage for cost caps.
- 1Accept the TLS connection; read X-KV-Token and X-KV-Target (must be a public https URL).
- 2Verify the token's HMAC-SHA256 signature. Reject and log tampered tokens.
- 3Unwrap the token's DEK with the master key and decrypt the payload (AES-256-GCM, in Worker memory).
- 4Check the request's Origin/Referer host against the token's allowed hosts, then its expiry. Reject and log if either fails.
- 5Check revocation, endpoint scope, rate limits and the monthly cost cap.
- 6Strip X-KV-* and CF-* headers, set the provider's auth header with the real key, and forward.
- 7Record usage: org, token ID, provider, method and path, status, latency and edge location. No request bodies.
- 8Refusals are recorded as breach events with IP, attempted host, user agent and approximate location.
Cryptographic primitives
| Purpose | Algorithm |
|---|---|
| Key encryption (DEK → provider key) | AES-256-GCM |
| Key wrapping (KEK → DEK) | AES-256-GCM |
| Token signing | HMAC-SHA256 |
| Transport | TLS 1.3 |
| Random | CSPRNG |
Some items describe the target architecture on our security roadmap. Status of each component is tracked on the trust center.
Found something wrong?
If a piece of this model is weaker than we've described, or the implementation doesn't match what's documented, we want to know. We publish scope, timelines, and credit publicly.
Responsible disclosure policy →