API key hygiene for AI apps: the gateway pattern, rotation, and blast radius
Provider API keys are the payment instrument, trade secret, and single point of failure of most AI apps — and key handling is where audits of maker-built apps find their fastest wins. This is the editorial companion to the audit-scope thread: what good key hygiene looks like at solo-maker scale, without enterprise tooling.
The three questions that define your posture
1. Where can a key physically appear? The only acceptable answers: your server's secret store, and the provider's dashboard. Every audit season produces the same findings elsewhere — keys in client bundles (view-source visible), in committed .env files (git history remembers), in system prompts (extractable), in logs (the sleeper — request logging that captures auth headers ships keys to your log vendor).
2. What can each key spend or reach? One key for everything means one leak is total. The cheap discipline: separate keys per environment (dev keys with tiny budgets, prod keys never on laptops), provider-side spend caps on each, and — where your provider supports it — scoped keys that can only call the models you actually use.
3. How fast can you rotate? The test is an hour, not a policy document: if a key leaked right now, how long until it's dead and replaced everywhere? If the answer involves remembering which services embed it, you have rotation debt. Fix: keys live in exactly one secret store; services read from there; rotation is one change plus restarts. Practice once — an unrehearsed rotation during a real leak is how downtime gets added to breach.
The gateway pattern, right-sized
The enterprise version puts a dedicated proxy in front of providers. The solo-maker version is simpler and captures most of the value: your backend is the gateway. Clients never hold provider keys — they call your API, authenticated as themselves; your server holds the one real key, enforces per-user metering, rate limits, and logging, then calls the provider. This single decision eliminates the entire client-side leak class, gives you the abuse-metering point the rate-limit thread keeps referencing, and centralizes rotation to one place. If you take nothing else from this post: no provider key ever ships to a client. Browser extension, mobile app, desktop app — same rule, no exceptions, and yes, that means some architectures need a backend they were hoping to skip.
The blast-radius worksheet
Write down: every key you hold; where each physically lives; its spend cap; what breaks when you rotate it; and who's alerted on anomalous spend. Five columns, one afternoon — it's the key section of your future audit, pre-answered, and the honest basis for the security notes buyers increasingly read.
Which column is currently blank for your app? That's the useful confession this thread is for.
Replies (4)
Follow-up from maker intake: "Git history remembers — I committed a key eight months ago and rotated it. Do I need to scrub history too?"
Rotation was the load-bearing fix: a dead key in history is an embarrassment, not a vulnerability. Scrubbing (history rewrite) is worth doing when the repo may change hands — acquirers' scanners will flag historical secrets, and each hit becomes a diligence conversation about your practices even if every key is dead. So: private repo staying private, low priority; repo headed for sale or open-sourcing, scrub before it's scrutinized. And add the pre-commit secret scanner either way — the pattern that matters is not doing it twice.
Follow-up from maker intake: "What anomalous-spend alerting is realistic without building a monitoring stack?"
Layered on what you already have: (1) provider-side budget alerts at 50/80/100% of a monthly cap — five minutes to configure, catches the catastrophic case; (2) a daily spend query in a scheduled job that messages you when today exceeds trailing-average by 2-3x — an hour to build with the usage endpoint most providers expose; (3) per-user token metering in your gateway (you built the gateway, right?) with a 'top spender today' line in that same message. That's the whole stack at solo scale. The failure mode it prevents arrives as a four-figure invoice with a two-week-old timestamp.
A note on why this thread exists in the audit category: of everything security, key hygiene has the best ratio of buyer-visible risk reduction to effort. When an acquirer's technical diligence starts, the key section is where sloppiness is cheapest to spot (history scans, bundle inspection, one rotation question) and most damaging to trust — because unlike a subtle injection risk, everyone in the room understands a leaked key. The worksheet in the post is genuinely the same table our diligence-prep material asks for. Do it once while nothing's at stake.
Follow-up from maker intake: "Where should the one secret store actually be for a typical solo stack — env vars on the host, the platform's secret manager, or a dedicated vault?"
Your hosting platform's secret manager, almost always: it's the option you'll actually maintain, it keeps secrets out of images and repos, injects as env vars at runtime, and every mainstream platform has one. Plain env vars hand-set on a host lose to it on auditability and rotation; a dedicated vault product wins on paper and then becomes the unmaintained extra system at solo scale — adopt one when you have a team or compliance driver, not before. The rule that outranks the tool choice: exactly one authoritative location, everything else reads from it.
Threads are permanent — locked, not deleted, once resolved. New posts go through a submission form and are published by moderators, usually within 1 business day.