Scoped API key design
Long-lived root keys are the single biggest blast-radius risk in any LLM gateway. This recipe shows how Meridian customers issue narrowly scoped, short-lived keys that bind a caller to one project, one model family, and one spend ceiling — without giving up the ergonomics of a single bearer token.
1. Model the scope as data, not as code
A scope is a tuple of project_id, model_glob, daily_usd_cap, and expires_at. Store it on the key row itself so the gateway can authorize a request in a single lookup — no per-request join, no policy engine in the hot path.
2. Enforce at the edge, account at the core
The Worker that fronts the gateway rejects scope violations before the request ever touches an upstream model. Spend accounting happens asynchronously against the core ledger so a slow Stripe write never adds tail latency to a chat completion.
3. Rotate without breaking callers
Issue the new key with overlapping validity, return both in the rotation response, and let the customer roll deployments at their pace. The old key auto-expires — no Slack ping required.
{
"key_id": "msk_8f3a91b2",
"project_id": "proj_acme_prod",
"model_glob": "azure/gpt-4*",
"daily_usd": 25.00,
"expires_at": "2026-07-27T00:00:00Z",
"issuer": "platform@acme.io"
}