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
Developers who ship KeyVault Edge tokens instead of raw provider keys can commit their code publicly without exposing the real credential. A leaked token, on its own, cannot call the upstream API.
Keys leaking from browser bundles, mobile apps, and desktop software
Host-bound tokens only function when presented from an allow-listed origin. An attacker who extracts a token from a shipped client binary cannot reuse it from their own infrastructure.
Single stolen credentials being used at scale
Every token carries a rate and spend cap. Anomalous usage patterns trigger automatic throttling and alert the owner within seconds.
Lost control after a compromise
One-click rotation invalidates a token in under five seconds. A per-account break-glass kill switch revokes every token, everywhere, immediately.
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 compromise of a customer's own KMS or identity provider
In the bring-your-own-KMS mode, we cannot decrypt keys without the customer's KMS cooperating. If that KMS is compromised, so is the customer's posture.
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)
The user's browser, at key-creation time only.
Never transmitted to KeyVault Edge in plaintext. Encrypted in the browser using a per-session data key before upload.
Data key (DEK)
Generated in the browser (WebCrypto), used once per provider key.
Used with AES-256-GCM to encrypt the provider key. Immediately wrapped by the account key and discarded.
Account wrapping key (KEK)
Cloud HSM (non-exportable). Customer-managed on enterprise plans.
Wraps every DEK for the account. On enterprise plans, this key lives in the customer's own KMS and grants are issued per-request.
Host-bound token
Signed by an HSM-resident key; delivered to the user's application.
Signed JWT containing the account ID, allowed origins, rate caps, and expiry. Cannot be forged without the HSM key.
Request flow
What the edge proxy does on every request, in order. The body is treated as an opaque byte stream; we do not inspect, log, or transform it.
- 1Accept TLS connection from the client origin.
- 2Verify the host-bound token signature against the HSM-resident public key.
- 3Check that the request origin matches the token's allow-list. Reject if not.
- 4Check rate and spend caps against the token's live counters.
- 5Look up the wrapped provider key; request a decrypt from the KMS/HSM.
- 6Inject the plaintext provider key into the Authorization header and forward the request.
- 7Record only: timestamp, token ID, status code, byte counts, latency. No bodies. No headers beyond a hash.
- 8Zero plaintext key material in memory immediately after the upstream response begins streaming.
Cryptographic primitives
| Purpose | Algorithm |
|---|---|
| Key encryption (DEK → provider key) | AES-256-GCM |
| Key wrapping (KEK → DEK) | AES-256-KW |
| Token signing | EdDSA (Ed25519) |
| 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 →