Leaked OpenAI API key? What to do in the first hour

Leaked OpenAI API key — what to do? Delete the key on the API keys page now, before you investigate anything else. Then work out which project it belonged to and what it could reach, read the usage for that key alone, replace it everywhere it was deployed, put a project spend limit and an IP allowlist in place, check whether an Admin API key leaked with it, and contact OpenAI Support. OpenAI's own guidance for a compromised key is short: delete it, review your usage and keep the details, contact support¹.

An OpenAI key is a bearer credential. Anyone holding a copy can bill your organization until the key stops working, and nothing about the request tells OpenAI it is not you. The rest of this runbook is the first hour in order, with the dashboard pages and endpoints OpenAI documents for each step.

The first hour at a glance

Steps overlap. The order that matters is the first one: nothing else waits for the investigation.

1. Delete the key

Delete the affected key through the API key dashboard¹. Do it even if you are not sure it was used: a key you are unsure about has to be replaced anyway, and every minute it exists it can be spent.

Two things to know:

• OpenAI may already have disabled it. OpenAI says that "When OpenAI detects an API key on the public internet, or leaked inside an app in an app store, the API key is disabled immediately"¹. GitHub's secret scanning lists OpenAI API keys as a partner pattern, so a key pushed to a public GitHub repository is reported to OpenAI². A key that leaked privately, through a breached third-party tool, a log file or a shared laptop, is not covered by either, so check the key's status yourself.
• Revoking first means downtime for whatever used the key. For routine rotation OpenAI recommends creating the replacement, updating applications and revoking the old key once the new one works³. For a key you believe is in someone else's hands, the order flips: revoke, then restore service. If an outage is unacceptable, create the replacement in the same minute and deploy it as fast as you can, but do not leave the old key alive while you do.

2. Find which key, which project, what it could reach

Write down the key's name, its project, who created it and when it was last used. A project key belongs to one project, so the project tells you which traffic, limits and members the key shares.

Then check the key's permissions. A user-owned key can be All (the default), Restricted to chosen endpoints with None, Read or Write per resource, or Read Only; service account keys are created by users with service-account management permissions, typically organization or project owners⁴. A key with All permissions could do more than run models in that project: it could read or write the project's other resources, such as files and stored assistants. Record that, because it decides what else you have to review.

3. Check the usage

Open the Usage Dashboard. You need to be an organization owner or hold the Usage Dashboard permission. It has its own project selector, independent of the project selected elsewhere in the platform, and its data is in UTC, which matters when you compare it with your own logs. Usage detail pages accept a 1-minute interval for tokens per minute⁵.

For a per-key view, the organization Usage API (GET /organization/usage/completions) accepts group_by values including api_key_id and project_id, with bucket_width of 1m, 1h or 1d; the reference examples call it with an Admin API key⁶.

curl "https://api.openai.com/v1/organization/usage/completions?start_time=$START_UNIX&bucket_width=1h&group_by=project_id&group_by=api_key_id&group_by=model" \
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

Look for traffic on the leaked key outside your own hours, models your code never calls, and volume out of proportion to your workload; signs your key is being abused lists the patterns. Keys created before 20 December 2023 did not have usage tracking enabled by default, and their earlier usage appears as "Untracked"³. Keep screenshots and exports: OpenAI asks for the details when you report it.

4. Rotate everywhere

Create the replacement with an expiration date. OpenAI "strongly recommends" an expiry on project keys and a regular rotation process³. Give it the narrowest permissions the workload needs.

Then find every copy of the old key, because the leak has told you that your inventory of where it lived was incomplete:

• Secret manager entries and the services that read them
• CI/CD secrets and deployment variables
• .env files on servers and developer machines
• Third-party tools that were given the key: IDE assistants, coding agents, notebooks, hosted consoles
• Other projects or organizations where someone may have pasted the same value

Confirm the old key now fails, and that nothing in production still sends it. A service that keeps retrying a deleted key is noise in your error logs and hides real failures.

5. Put limits in place

These make the next leaked key worth less:

• A project hard spend limit. When it is reached, affected requests return 429 with project_spend_limit_exceeded; an organization limit covers every project. OpenAI notes that enforcement "is not instantaneous, so recorded spend can slightly exceed the configured amount", and that spend alerts "do not enforce a cap"⁷.
• Spend alerts at several thresholds, such as 90% and 95% of a monthly budget, sent to a mailing list or incident tool rather than one person¹.
• An IP allowlist under Settings → Security → IP allowlist, at project or organization level, up to 50 addresses or CIDR ranges. Requests from other addresses fail with 401 and ip_not_authorized even with a valid key; changes can take up to 15 minutes, and OpenAI is clear it does not prevent every form of misuse⁸.
• Key governance. Admins can enforce a maximum key lifetime at organization or project level, and allow only service-account keys or only user-owned project keys; these settings apply to new keys only³.
• Separate keys per feature, team or project, so usage per key means something¹.

6. Check whether an admin key leaked too

If the leak came from somewhere that also held an Admin API key, such as a FinOps tool, a CI pipeline that manages projects, or a breached vendor, treat it as a separate and worse incident. Admin keys are created by organization owners and can manage invitations, users, projects, service accounts, API keys and admin keys; they cannot call model endpoints⁹¹⁰. An attacker with one does not need your inference key: they can create their own.

Delete any admin key that may be exposed and create a new one with only the scopes the integration needs. Then read the audit log: OpenAI's Audit Logs API records the lifecycle of API keys, users, service accounts and projects, login failures and organization setting changes⁹. Look for keys, service accounts or members created during the exposure window. Audit logging has to be enabled in organization settings before events are recorded, so if it is off, switch it on now. Least privilege for provider admin keys covers how to hold one safely.

7. Contact OpenAI Support

Open a chat from any Help Center page and include the activity you did not perform or authorize¹. For a compromised account or key there is also an Unauthorized Activity webform, with the option "Report unauthorized activity involving my account"¹¹. OpenAI's Services Agreement requires customers to "promptly notify OpenAI if it becomes aware of unauthorized access to the Account"¹², so report even if the usage looks small.

Include the key's name and project, the time window in UTC, the models and volumes you believe are not yours, and what you have already done. Whether any charges are adjusted is OpenAI's decision; what the terms say about stolen-key charges explains why prevention is the only protection you control.

If the leak also exposed a dashboard login, change the password, log out of all sessions (on Platform, Your Profile → Security → Log out of all devices) and turn on multi-factor authentication¹.

How INFRO handles a leaked OpenAI key

If your OpenAI key is connected to INFRO, step 4 has one more stop: replace the credential on the connection in the console or through the management API. INFRO seals the key with AES-256-GCM on arrival and never shows it again, and replacing it takes effect on the next request; it does not revoke the old key at OpenAI, which you still do yourself (see Connect a provider). Your applications use INFRO gateway keys rather than the OpenAI key, so a leaked application credential is an INFRO key you can revoke, rotate with an overlap window, restrict to IP ranges, and cap with budgets checked before OpenAI is called.

INFRO's controls govern traffic that goes through INFRO. A copy of the OpenAI key itself, wherever it leaked from, including from a platform like INFRO that holds it, can be used directly against OpenAI, and no INFRO budget, allowlist or alert sees that traffic. That is why steps 1, 5 and 7 happen at OpenAI. On the Business plan, with usage access on, reconciliation reads OpenAI's own usage per key and can show traffic that did not pass through INFRO.

Summary

Delete the key first. Then find its project and permissions, read its usage per key in UTC, replace it everywhere it lived, cap the project at OpenAI and allowlist your egress addresses, rule out an admin key exposure through the audit log, and report it to OpenAI with the details. The limits you set in step 5 are what make the next leak an incident instead of an invoice.