Why one key is a catastrophic amount of exposure
A leaked cloud credential used to mean someone spun up a few servers, bounded by account quotas that took a support ticket to raise. A leaked AI key is a different shape of risk entirely: there is no natural capacity ceiling. A script — or a bug in a retry loop — can issue thousands of expensive completions a minute against your account with nothing to slow it down except your own provider-side limits, which are usually set generously enough to support real traffic, not tightly enough to stop abuse. Leak a key at 2am and the invoice by morning reflects real conversations you never authorized and real money you can't claw back.
Provider-side spend alerts don't fix this because they're lagging and coarse by design: they fire hours later, against a monthly aggregate, well after the damage is already sitting in a database. By the time a human reads the email, the incident is over — the only thing left to do is count the cost.
Bound the blast radius before it happens, not after
The fix isn't better alerting. It's a hard ceiling enforced on the request path, before a provider is ever called, evaluated in a fixed order so a more specific cap always trips before a more general one gets the chance to matter less:
- Per run — an agent-loop-scoped cap, declared with a single header on a multi-step task. The moment cumulative spend for that run exceeds the declared ceiling, the run stops — before the overage can spill into the key's own budget.
- Per key — each application, environment, or teammate gets its own daily and monthly dollar cap. A leaked or runaway key stops at its own limit; the rest of the organization never notices anything happened.
- Per organization (and per workspace) — a hard daily and monthly ceiling across everything that key holder controls, so no combination of keys inside one org can exceed what was budgeted for it.
- Platform-wide — a single global guardrail sitting behind every customer and every key: the last line of defense against one very bad day turning into one very bad invoice for the whole platform.
A tripped cap returns HTTP 402, not a generic error, with response headers naming exactly which tier tripped, the window it applies to, the limit, and — for daily/monthly windows — a Retry-After telling the caller precisely when the door reopens. Run-scoped caps deliberately omit Retry-After: an agent-run window has no clock-based reset, so promising one would be a lie the client would rely on incorrectly.
Fair-share: the quota that only bites when it needs to
Hard caps solve the catastrophic case, but a purely hard cap can also punish an org that legitimately has ten API keys and wants them to share capacity fluidly when nine are idle. NeuroRoute's fair-share layer sits above the hard caps and is work-conserving: below 85% utilization of an org's pool, nothing is ever denied — a key over its arithmetic "fair share" still gets served as long as headroom exists. Only past that contention threshold does a key that's over its share start seeing 429s, while a key that's under its share keeps sailing through. It's the practical equivalent of deficit round-robin scheduling, without the queues or per-key deficit bookkeeping a synchronous gateway can't afford to hold.
The pool itself can be measured two ways, chosen per organization: a dollar basis, which reuses the org's existing daily or monthly budget cap rather than inventing a second number to configure, or a throughput basis measured in requests-per-minute and tokens-per-minute, tracked independently so a burst of many small requests and a burst of a few huge ones both get caught. The two bases also use different reset clocks — the dollar basis resets at UTC midnight, the throughput basis every minute — because "how much have you spent today" and "how many requests did you just send in the last sixty seconds" are genuinely different questions with different natural windows. And ordering matters here too: a hard budget cap is always evaluated first and returns its own 402 before fair-share is ever consulted, so a tripped hard limit can never be masked or second-guessed by the fairness layer sitting above it.
What actually comes back on a 402
A blocked request isn't a bare error code. The response carries X-Budget-Tier (which of the four levels tripped — run, key, org, or platform), X-Budget-Window (daily or monthly), and, for the key and org tiers, X-Budget-Limit and X-Budget-Spent so a client can show a real number to a real user instead of a generic "try again later." A well-behaved integration reads these headers and backs off intelligently — surfacing "your team's daily cap is exhausted, resets in 6 hours" instead of a raw 402 with no context — which is the whole point of returning structured headers instead of just a status code.
The rest of the security posture that makes quotas trustworthy
- HMAC-signed request auth with a ±300-second timestamp window and nonce replay protection, alongside short-lived ECDSA JWT sessions for the dashboard — two independent auth paths, not one shared secret doing double duty.
- Scoped service keys: a key can be issued with a restricted set of allowed actions, so a key handed to a read-only integration literally cannot be used to spend money on completions even if it leaks.
- An audit log of every privileged action — key creation, tier changes, override grants — queryable after the fact, because "we can bound the damage" and "we can show exactly what happened" are two different guarantees and you need both. When a key leaks, the audit trail is what tells you whether it was created legitimately and later exfiltrated, or whether the creation itself was the compromise — a distinction that changes what you fix afterward.
- Rate limiting on top of dollar caps: Redis-backed sliding-window RPM/TPM limits mean a leaked key can't even attempt the request volume that would be needed to approach its dollar cap before the rate limiter itself intervenes.
A leaked key, walked through
Say a CI pipeline accidentally logs an API key to a public build artifact at 1am, and by 1:15am something has scraped it and is issuing completions against your account. Without tiered caps, the next signal you get is a monthly invoice line item weeks later. With them: the key has its own daily dollar cap, set when it was created, so the abusive traffic hits that ceiling and starts returning 402 well before it can meaningfully affect the organization's own budget — the incident is bounded to one key's limit, automatically, in the minutes it takes to trip rather than the weeks it takes to notice. The audit log shows exactly when the key was created and by whom, which tells you where to start the actual remediation — rotating the key and fixing the pipeline that leaked it — while the rate limiter and fair-share layer have already been quietly absorbing the abusive request volume the whole time, so "how bad did this actually get" is a number you can pull immediately, not a guess.
None of this requires predicting the future or catching an anomaly in real time. It requires deciding, in advance, what the worst acceptable outcome is — and enforcing that number on every single request, automatically, before the provider is ever dialed.