Your provider keys are money now: BYOK without the foot-guns
A leaked database credential is a disaster you investigate. A leaked generative-media API key is a disaster that invoices you: it authorizes GPU spend, by the second, on some of the most expensive compute publicly for sale, and the person who found it on a paste site doesn't need your data — just your quota. As products stack more providers (image here, video there, voice on a third), the pile of these keys quietly becomes the most underprotected money-shaped object in the company.
The .env file that ate the budget
The default lifecycle of a provider key: created in a dashboard, pasted into .env, copied to CI, copied to a teammate's laptop, embedded in three services, and — the classic — committed to a repo that was private right up until it wasn't. Each copy widens the blast radius, and none of them offers an answer to the operational questions that eventually arrive: who can read this? Where is it used? When was it rotated? Can we revoke it without an outage?
The pattern held on anyway because keys used to gate data, and data leaks are abstract until they aren't. Media keys gate spend. The feedback is a number, and it compounds hourly.
Treat provider keys the way you treat payment credentials — because functionally, that's what they are.
Envelope encryption, in one paragraph
The storage-side fix is standard and worth demanding everywhere: envelope encryption. Each secret is encrypted with its own single-use data key; the data key is itself encrypted ("wrapped") by a master key that lives inside a KMS/HSM and never leaves it. Your database stores ciphertext next to wrapped keys — useless in a dump. Decryption happens per use, via an audited KMS call, so there's a log line every time a secret is actually opened, and revoking the master key is a kill switch for the whole vault. No plaintext at rest, no plaintext in logs, no "the backup had the keys in it."
What to demand from any platform holding your keys
Bring-your-own-key platforms — Wakemark included — concentrate exactly this risk: you hand over the credentials for every provider you use. Concentration can be safer than the .env diaspora or worse than it, depending entirely on the answers to:
- How is it stored? The only acceptable answer is envelope encryption with the master key in a real KMS — not "encrypted at rest" (a disk property) and not a secrets table with app-level crypto and the key in config.
- Where can plaintext appear? Only in memory, at the moment of provider dispatch. Never in logs, never in error payloads, never echoed back by any API — a key you can read back out is a key stored wrong.
- Is validation honest? The platform should verify a key on connect with a harmless call — and get the semantics right. We've seen providers reject valid restricted-scope keys with a different error than invalid ones; a sloppy validator reads both as "bad key" and makes you over-provision scopes to pass, which is the opposite of security.
- Can you rotate without downtime? Add new key, verify, atomically switch dispatch, revoke old — as a supported flow, not a support ticket.
- Is there a blast-radius limiter? Even a perfectly stored key authorizes spend when legitimately used by a runaway loop. Hard spend caps are a security control wearing a billing costume: they bound the damage of both compromise and bugs.
And from yourself: scope like you mean it
Per-provider hygiene still applies underneath any platform: one key per environment (the key that serves production should not be the key on laptops), minimum scopes the provider allows, and a calendar reminder that rotation exists. The pleasant surprise is that a BYOK control plane makes this easier — when dispatch goes through one place, "where is this key used?" finally has one answer, and the ledger under that place is your usage log per key, per job, per dollar.