How to store AI API credentials safely

Where should an AI API key live?

An AI API key should live in a secrets manager or in a server-side environment variable, and nowhere else. OpenAI tells customers not to put keys in code or public repositories, and to load them through environment variables or a secret management service. Anthropic gives the same advice: store keys in a secrets manager and rotate them on a schedule.

A secrets manager is a service that holds passwords and keys, controls who can read each one, and logs every request. The OWASP Secrets Management Cheat Sheet lists the basics: never hard-code a secret, never send one in plain text, and record what each secret is for and where it is kept.

Places a key should never appear:

• Source code or a committed .env file.
• Chat messages, support tickets and shared documents.
• Browser or mobile app code that ships to customers.
• Build logs that print environment variables.
• Docker images. OWASP specifically advises against passing secrets through Docker ENV and ARG settings.

Who should hold the keys?

Keep keys with the smallest group that needs them, and tie each key to one project. OWASP’s least-privilege rule says to limit which people and systems can read or change each secret.

Both vendors support this in their settings:

Control	OpenAI	Anthropic
Separate environments	Separate projects for staging and production, each with its own rate and spend limits	Separate workspaces for development, staging and production
Key ownership	Governance settings can restrict keys to service accounts, or to user-owned project keys, or block new keys	Personal keys, service account keys, and legacy workspace keys
Who can create keys	Admin settings control key types and maximum lifetime	Workspace roles: Developer roles can create keys, User role cannot

Anthropic recommends a personal key for your own scripts and a service account key for anything shared or automated. A personal key stops working when its owner leaves the organisation, so it does not outlive the person. Anthropic now treats workspace keys as legacy. Review workspace membership on a regular schedule, as the Workspaces documentation recommends.

How do you limit the damage if a key leaks?

Set an expiry date on each key and a hard spend cap on the account. These two settings put a ceiling on how long a leaked key works and how much it can cost.

• Expiry. OpenAI advises setting an expiry date when you create a project key, then rotating by creating a replacement, updating applications and revoking the old key. Anthropic offers expiry presets of 3 hours, 1 day, 7 days or 30 days, or a custom duration. Anthropic notes that expiry limits how long a leaked key stays usable but does not replace good storage habits.
• Spend alerts. OpenAI’s alerts tell you when monthly spend crosses a dollar figure. They do not stop traffic.
• Hard spend limits. OpenAI’s spend limits can be set for the organisation or a single project, and return a 429 error once reached. Anthropic lets you set a monthly limit on the Billing page, below its tier cap, and set separate limits per workspace.

Hard limits can switch off a live product, so set them above your normal peak and alert well before the cap. If a key does leak, follow the first-hour checklist for leaked AI API credentials.

How often should you rotate AI API keys?

Rotate on a fixed schedule, and immediately when you suspect exposure. OWASP says to automate rotation where possible, revoke secrets no longer needed, and set expiry dates where you can. It treats suspected compromise as a trigger for immediate rotation.

A simple routine for a small team:

1. Put a calendar reminder on every key’s expiry date.
2. Create the new key, deploy it, and confirm requests succeed.
3. Delete the old key. Anthropic’s Delete is permanent, while Disable can be reversed if something breaks.
4. Remove keys belonging to people who have left.

Can you avoid long-lived keys altogether?

Often yes, if your software runs on a major cloud platform. Anthropic’s Workload Identity Federation lets a workload on AWS, Google Cloud, Azure, GitHub Actions or Kubernetes exchange its platform identity for a short-lived token. There is no static key to store, copy or leak. Anthropic points out that the setup is only as strong as the identity provider behind it.

For iOS and macOS apps that call the API directly, Anthropic offers App Attest, which issues short-lived tokens to verified installs of your app, so no key ships inside it.

What is a quick storage checklist?

Use this list to review your current setup in about ten minutes.

1. List every AI API key your team holds, and who created each one.
2. Check that none sit in code, chat or shared documents.
3. Confirm each key belongs to one project or workspace.
4. Set an expiry date on each key that does not have one.
5. Switch on a hard monthly spend limit and a spend alert.
6. Remove keys that belong to former staff or retired projects.

What catches a leak you missed?

GitHub’s secret scanning recognises OpenAI and Anthropic key formats, and push protection is supported for them. GitHub notes that push protection covers only the most recent token versions, so older key formats may not be blocked. Switch the feature on for every repository your team uses, and keep reading usage dashboards as the second check. The full list is in GitHub’s supported patterns.

A stolen key can also be used to pull large volumes of answers out of a model. What a distillation attack is explains how that works and why the bill reaches the key’s owner.