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

URL: https://infro.io/blog/leaked-openai-api-key
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> If an OpenAI API key is leaked, delete it on the API keys page first, then find which project it belonged to and what permissions it had, review usage for that key in the Usage Dashboard or the Usage API, replace it everywhere it was deployed, set project spend limits and an IP allowlist, check whether an Admin API key was exposed too, and contact OpenAI Support with the details. OpenAI disables keys it detects on the public internet, but do not rely on that.

Key takeaways:
- Delete the key first: OpenAI's guidance for a compromised key is to delete it in the API key dashboard, review usage and contact support.
- Find the blast radius from the key's project and permissions, then read usage for that key alone, in UTC, at a fine interval.
- Replace the key everywhere it lived: secret managers, CI, environment files, laptops and every third-party tool that held a copy.
- Set a project hard spend limit and an IP allowlist so the next leaked key is worth less; hard limits return 429 and are not instantaneous.
- Treat a leaked Admin API key as a separate, worse incident: it can create and delete keys, projects and users.

**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[1].

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

| When | Step | Where |
| --- | --- | --- |
| Minute 0–5 | Delete the exposed key | API keys page in the OpenAI dashboard |
| 5–15 | Identify the key's project, owner and permissions | API keys page, project settings |
| 15–30 | Read usage for that key and project | Usage Dashboard, Usage API |
| 15–45 | Deploy a replacement everywhere the old key lived | Your secret manager, CI, hosts, tools |
| 30–50 | Set a project hard limit, alerts and an IP allowlist | Limits page, Settings → Security |
| 45–60 | Check admin keys and the audit log; contact support | Admin keys page, Audit Logs API, Help Center |

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[1]. 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"[1]. 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[2]. 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[3]. 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[4]. 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[5].

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[6].

```bash
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](https://infro.io/blog/signs-ai-api-key-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"[3]. 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[3]. 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"[7].
- **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[1].
- **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[8].
- **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[3].
- **Separate keys per feature, team or project**, so usage per key means something[1].

## 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[9][10]. 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[9]. 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](https://infro.io/blog/provider-admin-key-least-privilege) 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[1]. For a compromised account or key there is also an Unauthorized Activity webform, with the option "Report unauthorized activity involving my account"[11]. OpenAI's Services Agreement requires customers to "promptly notify OpenAI if it becomes aware of unauthorized access to the Account"[12], 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](https://infro.io/blog/ai-api-key-theft-bill-refund) 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[1].

> **Example: One key, one project, one hour**
> At 09:12 an engineer finds a project key in a public gist. At 09:14 the key is deleted. The API keys page shows it belonged to the `support-bot` project with All permissions. The Usage Dashboard, filtered to that project at a 1-minute interval, shows a reasoning model the bot never calls running since 03:40 UTC. The team ships a new Restricted key with a 90-day expiry by 09:40, sets a project hard limit and an IP allowlist for its two egress ranges, confirms no admin key existed outside the secret manager, and sends support the export at 10:05.

## 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](https://infro.io/docs/providers)). 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](https://infro.io/docs/org/spend-controls) 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](https://infro.io/docs/cost/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.

## Questions

### What should I do first if my OpenAI API key is leaked?

Delete the key on the API keys page of the OpenAI dashboard. OpenAI's own guidance for a compromised key is to delete it, review your API usage for unexpected activity and keep the details, then contact OpenAI Support.

### Does OpenAI automatically disable leaked API keys?

OpenAI says that when it detects an API key on the public internet, or leaked inside an app in an app store, the key is disabled immediately. GitHub also reports OpenAI keys found in public repositories to OpenAI. Neither covers a key leaked privately, for example from a breached tool or a log file, so revoke it yourself.

### How do I see what a leaked OpenAI key was used for?

Open the Usage Dashboard, select the key's project with the dashboard's own project selector, and narrow the interval; times are in UTC. For a per-key breakdown, the organization Usage API accepts group_by=api_key_id with an Admin API key.

### Will OpenAI refund charges from a stolen API key?

OpenAI does not publish a refund policy for unauthorized usage, and its Services Agreement makes the customer responsible for all activity under its account. Report it through support or the Unauthorized Activity webform with the details; any adjustment is OpenAI's decision. See our guide on stolen API key charges.

## Sources

1. Keeping your OpenAI account secure — OpenAI Help Center. https://help.openai.com/en/articles/8304786-how-can-i-keep-my-openai-accounts-secure (accessed 2026-10-21)
2. Supported secret scanning patterns — GitHub. https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns (accessed 2026-10-21)
3. Production best practices — OpenAI. https://developers.openai.com/api/docs/guides/production-best-practices (accessed 2026-10-21)
4. Assign API Key Permissions — OpenAI Help Center. https://help.openai.com/en/articles/8867743-assign-api-key-permissions (accessed 2026-10-21)
5. Reviewing API usage and costs — OpenAI Help Center. https://help.openai.com/en/articles/10478918-api-usage-dashboard (accessed 2026-10-21)
6. Completions usage (API reference) — OpenAI. https://developers.openai.com/api/reference/python/resources/admin/subresources/organization/subresources/usage/methods/completions (accessed 2026-10-21)
7. Spend limits — OpenAI. https://developers.openai.com/api/docs/guides/spend-limits (accessed 2026-10-21)
8. IP allowlisting for OpenAI API — OpenAI Help Center. https://help.openai.com/en/articles/20001201-ip-allowlisting-for-openai-api (accessed 2026-10-21)
9. Admin and Audit Logs API for the API Platform — OpenAI Help Center. https://help.openai.com/en/articles/9687866-admin-and-audit-logs-api-for-the-api-platform (accessed 2026-10-21)
10. Admin APIs — OpenAI. https://developers.openai.com/api/docs/guides/admin-apis (accessed 2026-10-21)
11. I'm seeing unrecognized activity on my OpenAI account — OpenAI Help Center. https://help.openai.com/en/articles/8485685-im-seeing-unrecognized-activity-on-my-openai-account (accessed 2026-10-21)
12. Services Agreement — OpenAI. https://openai.com/policies/services-agreement/ (accessed 2026-10-21)