API key management for LLM APIs is the set of rules for who gets a key, what each key can reach, where it is stored, and how it is rotated and revoked. The pattern that holds up in production is one project, one key: each workload gets its own project, and that project's key carries its own model list and budget. Below are three ways a shared key fails, an issuance pattern, a table of where the key lives in each environment, and a 30-day migration runbook.
Three ways a shared key goes wrong
The offboarded contractor
A contractor builds the retrieval prototype with the company's only API key in a local .env file, then leaves on a Friday. The same key also runs the support bot, the nightly summarization job and an internal Slack assistant. Revoking it that afternoon breaks all three. Leaving it means a former contractor still holds a working key. Most teams choose "rotate next sprint", and the sprint fills up.
With one key per project, the contractor only ever had the key for their sandbox project. You revoke it and nothing else changes.
The key in a public repo
Someone commits a config file with the key to a public repository. Whoever finds it can send traffic that lands on your bill, and because every service sends the same credential, their requests look exactly like yours in the usage data. The fix is the same as the contractor case, with the same outage attached.
The spike nobody can attribute
The monthly bill doubles. The provider dashboard shows which model grew, but every request carries the same key, so nobody can say which product caused it. Finance asks for a breakdown by product; engineering spends two days matching timestamps across service logs.
What the vendors recommend
OpenAI's best practices for API key safety ask for a unique API key per team member, rotation and expiry, and never putting keys in client-side code. OpenAI also recommends separate projects for staging and production, each with its own limits (production best practices). Anthropic lets you scope an API key to a single Console workspace. Vercel AI Gateway keys can carry a budget and an expiry, which suits a contractor key with a fixed end date (Vercel budgets).
Per-person keys solve offboarding for humans. A production service should not run on a person's key, because removing that person then stops the service. The working split is personal keys for personal sandboxes and a project key for each deployed workload.
The issuance pattern
- One project per workload and environment.
support-bot-prodandsupport-bot-stagingare separate projects with separate keys. - One key per project for services. People who experiment get their own sandbox project.
- Name keys after service, environment and month of issue, for example
support-bot-prod-2026-10, so a key found in a log or a repo points to its owner. - Move the secret straight from the console into the secret manager. Never paste it into chat, tickets or docs.
- Rotate by overlap: issue a new key in the same project, deploy it, confirm traffic has moved, then revoke the old one.
Where the key lives in each environment
How ATP Token keys work
ATP Token has a four-level tree: organization, workspace, project and key (set up your organization). A key belongs to exactly one project and inherits that project's allowed models and credit balance. Model access is set per project, never per key, so two keys in the same project can always call the same models.
The Create key wizard asks for a name, the workspace and project, and optionally some starting credits. Keys start with atp-, are 92 characters long, and the full secret is displayed once; afterwards only the prefix is visible (managing API keys). The API keys page lists every key in the organization across all workspaces and projects, searchable by name or prefix. A revoked key stops working immediately and stays in the roster for audit.
For attribution, the Usage page shows credits and tokens by model and by key, and request logs record each call with its model, status, token counts and request ID (usage and logs). Request logs are kept for 7 days, so review a suspect key soon after an incident. The gateway strips your atp- key before forwarding a request, so upstream providers never see it (how it works).
Who can do what is set by role: an Admin manages members, resources, keys and credit allocation, and a Member uses what they have access to (team and roles).
Migration runbook: from one shared key to project keys
The runbook pairs well with a budget per project, so a leaked or looping key also hits a cap. See AI API spending limits compared.
Quickstart: create a project key
