Keys
BYOK: your provider keys stay yours
You bring your own provider API keys. They are sealed with envelope encryption before they touch a disk, bound cryptographically to one tenant and one provider, and exist in plaintext only in memory, only while a provider client is being built.
What envelope encryption means here
Every stored secret gets its own 256-bit data key (a DEK), minted fresh for that secret by a managed key-management service (KMS) — disclosed by function and region on the subprocessor page, like every other processor. The secret is encrypted with the DEK using AES-256-GCM from the Go standard library. The DEK is then wrapped by a KMS master key and only the wrapped form is persisted. The plaintext DEK is never written down.
So the database holds three things per secret: the ciphertext with its authentication tag, the KMS-wrapped data key, and the GCM nonce — plus a record of which master key version wrapped it, for rotation audit. A copy of the database, on its own, is inert. Opening any secret requires a live, authorised call to KMS.
What binds a secret to one tenant
Two independent bindings, both cryptographic rather than conventional. tenant_id|provider is the AES-GCM associated data of the payload, so a data key cannot open a payload that was sealed for a different pair. The same tenant_id|provider is the KMS encryption context of the DEK wrap, so the KMS itself refuses to unwrap the key under a different pair — the rejection happens inside the key-management service, not in our code.
The practical meaning: a bug in Wakemark that fetched the wrong tenant's row would not yield a usable key. It would fail to decrypt. Cross-tenant access is a cryptographic error rather than a policy check that someone could get wrong.
What Wakemark can and cannot see
| Wakemark holds | |
|---|---|
| Your provider key | Ciphertext only. In plaintext it exists in process memory, for the duration of building a provider client, and is zeroed before return. It is never logged, never placed in an error, never written to the ledger. |
| Any fragment of the key | Nothing — not a prefix, not a suffix, not a masked hint. A display fingerprint was built once and then withdrawn, because it put part of a customer secret outside the envelope for the first time. |
| Your provider bill | Nothing. Inference is billed by the provider to your account. Wakemark never sees an invoice, a balance, or a spend total. |
| Which provider you connected | Yes — the provider name, the KMS key version, and when the credential was added or rotated. That is what the dashboard shows. |
Rotation and removal
Rotating a credential replaces the sealed secret and records the new master-key version. Disconnecting deletes the row. On account deletion, provider credentials are purged immediately at request time rather than at the end of the grace period — a key that can spend your money is not something to hold for thirty days while you reconsider.
Check this yourself
Nothing on this page should have to be taken on our word. Each of these settles part of it, and none of them requires trusting the sentence above it.
- Security & Trust, “Credential custody” — the same two bindings, stated as a commitment rather than as documentation.
- Data processing agreement — BYOK credentials as encrypted custody, and what happens to them on termination.
- Subprocessors — the key-management service disclosed by function and region, with the itemised list available under the DPA.
- Privacy Policy, “What we never do” — no plaintext provider keys at rest, in logs, or in error messages — as a term.