How do you limit the damage from a stolen API key? Decide its blast radius before it leaks. Give every workload and environment its own provider key in its own project or workspace, set a hard spend limit on that scope at the provider, restrict keys by network where the provider allows it, give applications gateway keys instead of provider keys, enforce budgets that refuse before the provider is called, and watch provider usage per key. Then a leak is a bounded, visible loss instead of an open-ended one.
No control here prevents a leak. Keys end up in repositories, laptops, CI logs, browser bundles and third-party tools that store them for you. On 2026-10-17 OpenCode disclosed that provider keys saved in its Console had been exposed; BleepingComputer reported users describing unauthorized charges from several hundred dollars to more than $1,700 overnight, and some said Google suspended their projects for "abusive activity consistent with hijacked resources"1. The OpenCode incident write-up covers what is known. This guide is about the part you control: how much any one key can do once someone else has it.
The rule that decides everything else
Controls in your gateway govern traffic that goes through your gateway. A provider key stolen from anywhere, including from a gateway or platform that stores customers' provider keys, can be sent straight to the provider. It bypasses every gateway budget, allowlist, guardrail and alert. Only the provider's own controls apply to it: how the key is scoped, the spend limit on its project or workspace, network restrictions the provider enforces, revocation at the provider, and the provider's usage reports.
So the layers below split in two. Layers 1 to 3 bound a provider key used anywhere. Layers 4 and 5 bound what flows through your gateway, including a leaked gateway key. Layer 6 is how you find out.
Layer 1: one provider key per workload and environment
A key shared by five services and two environments cannot be revoked without breaking all of them, and its usage cannot be told apart. Give each workload its own key, in its own provider scope:
- OpenAI: a project per workload and environment. Project hard limits apply only to traffic billed to that project2.
- Anthropic: a workspace per workload and environment, with keys scoped to that workspace. A single-workspace key can only act in its workspace3.
- Google: a project per workload, with each key restricted to the APIs it needs. Google recommends setting both API restrictions and application restrictions, and calls unrestricted keys insecure4.
- Amazon Bedrock: prefer short-term API keys, which last up to 12 hours and inherit the permissions of the IAM principal that made them; AWS recommends long-term keys only for exploration5.
The same applies to keys you hand to third parties. A coding agent, an evaluation vendor or a BYOK platform gets a key of its own, in a scope of its own, so you can revoke it without touching anything else.
Layer 2: a hard limit on every scope that holds a key
With one key per scope, the scope's limit is the key's limit. OpenAI enforces hard limits per project and organization and returns 429 project_spend_limit_exceeded at the limit, noting that enforcement is not instantaneous2. Anthropic workspaces take their own monthly spend limit, except the Default Workspace3. Which providers refuse and which only alert, and how late each acts, is in AI provider spend limits compared.
Set each limit from the workload's normal month, not from the account's. An evaluation pipeline that spends a few hundred dollars a month needs a limit near that, not the organization's ceiling. Keep the Default Workspace and any project without a limit free of keys.
Layer 3: restrict where a key works
A key that only works from your servers is worth little to someone who copies it. Support differs:
| Provider | Restriction you can put on an API key | Documented response when blocked |
|---|---|---|
| OpenAI | IP allowlist per organization or project, up to 50 addresses or CIDR ranges; a project list overrides the organization list | 401 ip_not_authorized |
| Google (Gemini API, Cloud APIs) | Application restriction by IP address (one restriction type per key), plus API restrictions | Not stated on the cited page |
| Anthropic | IP allowlisting is documented for Claude Enterprise plans; the article does not say it covers Claude API keys | Not documented for API keys |
| Amazon Bedrock | No network setting on the API keys page; IAM policies control who may create and use keys, including a deny on bedrock:CallWithBearerToken | Not stated on the cited page |
OpenAI's allowlist applies only to API requests, takes up to 15 minutes to apply, and "does not replace secure API key storage, key rotation, or account security"6. Check the address the provider sees: NAT gateways and proxies change it. Google's IP restriction "specifies the servers or cron jobs that can use the key", and only one application restriction type can be set per key4. Anthropic's IP allowlisting article is for Enterprise plans and lists chats, projects and similar Claude surfaces without stating that Claude API requests are covered7; do not count on it for API keys without confirming with Anthropic. On Bedrock, AWS documents IAM actions that control generating and using API keys, including a deny on CallWithBearerToken5.
Where the provider cannot restrict by network, the remaining layers carry more of the weight.
Layer 4: applications hold gateway keys, not provider keys
The fewer places a provider key exists, the fewer places it can leak from. Put a gateway between your applications and the providers, store the provider key there, and give each application a gateway key scoped to one service and one environment. A leaked application key is then:
- Revocable without touching the provider. You revoke one gateway key; the provider key and every other service keep working.
- Narrow. It reaches only the providers, models and networks its gateway key allows.
- Bounded by the gateway's limits, which refuse before the provider is called.
This concentrates provider keys in one system, which makes that system a target. Hold it to the standard in BYOK credential architecture: provider keys sealed with authenticated encryption, never returned after saving, and still scoped and limited at the provider as if they might leak. They might. AI gateway keys: environments, limits, rotation covers running the gateway keys themselves.
Layer 5: budgets that refuse before the call
A gateway budget that records cost after a request completes can be passed by everything already in flight. One that admits a request only if its worst-case cost fits the room left cannot. Put a limit on each gateway key, sized for that service, and a blocking budget on each project and on the organization. For a leaked gateway key, the key's limit is the exposure. For a runaway agent using a legitimate key, the same limit is what stops it. LLM spend limits compared explains when each gateway counts spend.
Layer 6: know within hours, not at the invoice
Every layer above bounds the loss. Detection decides how much of the bound is used. Three signals, in order of speed:
- Gateway alerts on a key, project or organization spending outside its usual day. Fast, but blind to traffic outside the gateway.
- Provider usage per key. OpenAI and Anthropic both report usage grouped by API key through their admin APIs. Traffic on a provider key that your gateway never sent is a leaked key or shadow usage; detecting gateway bypass shows the comparison with a script.
- Provider spend alerts on each project or workspace, set below the hard limit.
Then make revocation fast. Write down, for every key, where it is revoked and who can do it; the AI credential inventory has a template. Rehearse it once. A key you cannot find in the provider console at 2 a.m. is a key that keeps spending.
A worked example
The last line is the reason for the order of this guide. Gateway controls make the common leak small; provider controls make the worst leak bounded.
How INFRO bounds a leaked key
INFRO is an AI control plane in front of provider accounts you connect. For traffic through it:
- Gateway keys (
sk_infro_, stored as a SHA-256 digest) can be limited to chosen providers and to IP ranges; a request from outside them returns403 ip_not_allowedbefore any budget check or provider call. Rotation copies every setting and offers an overlap of none, 1 hour, 24 hours or 7 days; after a leak, use none. See Authentication. - Environments: each gateway key belongs to one environment and never reaches a connection outside it.
- Budgets per organization, project, member and key are checked before the provider is called; a request that does not fit returns
402. See Spend controls. - Provider credentials are encrypted with AES-256-GCM under a key held outside the database, bound to their organization and connection, and never shown again after saving.
- Spend alerts flag a scope whose day departs from its usual day, by email, Slack, Teams, PagerDuty or webhook. See Alerts.
None of that applies to a provider key used directly against the provider, including one taken from INFRO itself. For that case, keep the provider-side layers: a key per connection in its own project or workspace, a provider spend limit on it, network restrictions where the provider offers them, and revocation at the provider. On the Business plan, INFRO's reconciliation with usage access on reads OpenAI's and Anthropic's usage by provider key and can name traffic that did not pass through INFRO; without usage access it reports "not checked".
Blast-radius checklist
- Every provider key belongs to one workload and one environment, in its own project or workspace.
- Every project or workspace that holds a key has a hard spend limit at the provider, sized to that workload.
- No key lives in the Default Workspace or in a project without a limit.
- OpenAI projects that call from fixed addresses have an IP allowlist; Google keys have IP and API restrictions.
- Bedrock uses short-term keys in production.
- Applications hold gateway keys scoped to one service and environment, each with its own spend limit.
- Gateway budgets block before the call at key, project and organization level.
- Provider usage is reviewed per key at least daily for keys that carry production traffic.
- Each key has a written revocation path and an owner, and revocation has been rehearsed.