I leaked an OpenAI API key: what to do, from OpenAI's own docs
Short answer: OpenAI's guidance for a key you think has leaked is to rotate it immediately from the API Keys page: delete the exposed key with the trash can icon, create a replacement, and check your usage. Revocations take effect within a few seconds, so any application still using the old key will fail until it has the new one. Set a hard spend limit so a future leak is bounded.
This is the OpenAI page for the leaked-key playbook. Every instruction below is quoted or closely paraphrased from OpenAI’s own documentation, linked at each point; we did not exercise OpenAI’s dashboard ourselves. OpenAI’s sources were read on 2026-11-01.
What OpenAI says to do when a key leaks
From OpenAI’s best practices for API key safety (point 7): “If you believe your key has been leaked, rotate your key immediately from the API Keys page… Contact us through help.openai.com for further investigating.”
For ordinary rotation, the same article (point 2) gives an order: “create a replacement, update your applications to use it, and revoke the old key once you’ve verified that the replacement works.” For a suspected leak, OpenAI says to rotate immediately; it does not prescribe a different order, so use your judgment: if you see abuse, delete first and accept the outage; if you don’t, create and deploy the replacement before deleting.
Delete the exposed key
OpenAI’s help article on API keys: “To delete a key, select the trash can icon next to it on the API key page; deleted keys cannot be used, so applications that rely on them may stop working.” The keys page is platform.openai.com/api-keys.
How fast does it take effect? OpenAI’s API reference says: “Revocations of an API key take effect within a few seconds.”
Create the replacement, with less power
From OpenAI’s help article on project API keys: go to organization settings, select the project, then open API Keys and select + Create new secret key; or select the edit icon next to an existing key to change its permissions. Permissions are All, Restricted or Read Only, so give the new key only what the application needs.
One thing to plan for: “a full secret key is only shown when you create it” (the API keys help article), so copy it straight into your secrets store, not into a file or a chat.
Prefer project keys with an expiration date: OpenAI’s best-practices article says requests from keys past their expiration “will be rejected,” and its production best practices “strongly recommend setting an expiration date.” For automation, those guides also recommend service accounts (Members, then + Service account, scoped to projects) and workload identity federation instead of long-lived keys, where your platform supports it.
Cap the damage: a hard spend limit
OpenAI’s spend limits guide is clear that “spend alerts alone don’t stop API traffic.” To enforce a cap: open your organization’s limits page, choose Edit spend limit, set a Monthly spend limit, select Enforce a hard limit and Save. The same exists per project under Project settings, Limits. With a hard limit in place, requests that exceed it get an HTTP 429 with organization_spend_limit_exceeded or project_spend_limit_exceeded. A hard limit stops traffic, including your own, so review the guide before turning it on in production.
Check what the key did
Use the Usage page for the window since the key was exposed. One caveat from OpenAI’s production best practices: keys created before December 20, 2023 don’t have usage tracking enabled by default, and untracked usage appears as Untracked, so older keys may give you less to go on.
After OpenAI is fixed: every other copy
Deleting the key at OpenAI is half the job. The same value is usually also in other services, a CI variable, a teammate’s .env or another vault. With Dynv you can preview one operation that finds each copy it knows about (including the same value under another name) and replaces them together: pipe the new value in so it never lands in shell history, for example pbpaste | dynv rotate OPENAI_API_KEY --leaked --stdin --dry-run, then run it again with --yes (the plan also suggests copies under other names, which you add with --also SERVICE:KEY). --leaked means “everywhere, no fallback, no stages; the old value stops working now.” Dynv only knows copies stored in Dynv; search repositories, CI and chat for the old value’s prefix yourself. The generic order of operations, with evidence on how fast leaked keys are used, is in the 15-minute playbook.
Limits of this page
- Not verified by us or in OpenAI’s documents: the live dashboard layout and any confirmation dialog when you delete a key; the exact error an application receives when it uses a deleted key; and whether OpenAI detects keys leaked on the public internet. We make no claim about any of them.
- If the key was in a repository, rotating it is the fix; cleaning Git history is housekeeping (how).
- If a chat or an agent saw the key, see what to do.
Facts last verified . Spotted an error? Tell us.