Separate LLM API keys per environment and feature: a decision guide

Use at least one key per environment, and add a key per feature or team once the spend justifies it. Separate keys let you revoke one leak without an outage everywhere, set different limits on test and production, and see which feature caused a spike.

The problem with one key

A single key in every environment means a laptop, a CI job and production all hold the same credential. A leak from any of them forces a rotation that breaks all of them at once. Teams then delay the rotation, which is the opposite of what you want.

A shared key also hides cost. When the bill jumps, you cannot say whether it was the chat feature, a batch job or a test script left in a loop.

Three levels of separation

Level 1: environments. Development, staging and production each get their own key. Developer keys carry a low spend limit. Production carries the real one.

Level 2: features. The support chatbot, the document summarizer and the nightly batch each get a key. If one is abused or misbehaves, the others keep running.

Level 3: tenants or teams. Useful when you resell access or run internal showback. It gets heavy fast, so do it only if you need cost attribution or hard isolation per customer.

Use the provider's grouping if it has one

Some providers organize keys into projects or workspaces. One provider's documentation describes workspaces that hold their own keys, members, spend limits and rate limits, and suggests separate workspaces for development, staging and production. In that model, a key scoped to one workspace can only reach resources in that workspace, and limits you set per workspace cannot exceed the organization's limits. Check how your provider handles scope, as the details differ.

A short decision guide

• Under a few hundred dollars a month and one product: per environment is enough.
• Several features with different risk, such as a public chatbot and an internal tool: per feature.
• Customer-facing product with large customers: consider per tenant limits in your own proxy first, and separate keys only when a contract needs it.

Housekeeping that makes this work

1. Name keys by owner, environment and feature, so an alert about a key tells you where to look.
2. Store them in a secrets manager, not in repository files. See the key rotation guide.
3. Give humans personal keys with low limits, and give services their own.
4. Review the key list every quarter and delete what is unused.
5. Set a spend limit on each key or group. See setting LLM API spend limits.

What separation does not fix

If one service account can read every key, separation is cosmetic. Limit who and what can fetch each secret. And if the app's own users can drive unlimited requests, a separate key just contains the damage to one feature.

Safeguard can scan repositories for committed secrets and list where dependencies that call provider APIs live, which helps with the inventory step.

Quick check

Sources

• Provider documentation on workspaces, key scoping and per-workspace limits

Last reviewed: 19 October 2026.