OpenAI added API key expiration to its API platform on September 10, 2026. Project API keys can now carry an end date, and administrators can require every new key to expire within a set limit. Five days later, OpenAI added controls over who can create keys at all.
Until now, a leaked OpenAI key stayed valid until someone noticed and revoked it. Agencies carry that risk many times over. An agency may hold keys for a dozen client sites, stored in plugin settings, .env files and CI secrets. Many of those keys were created once and never touched again.
This piece walks through what OpenAI shipped, how to set an expiration date on a key, how the organization and project limits work, what happens when a key expires, and how service account keys differ from user keys. It ends with a rotation routine built for agencies managing many client projects.
The short version: set a maximum lifetime at the organization level, move production integrations to service account keys, and put every key’s expiry date on a calendar. Expiry turns a forgotten key into an outage instead of a standing risk. API key expiration is worth that trade, but only if you plan the replacement before the date arrives.
What OpenAI shipped on September 10 and 15
The OpenAI API changelog lists two separate entries.
The September 10 entry reads: "You can now set expiration dates when creating project API keys." It adds that administrators "can also enforce a maximum key lifetime at the organization or project level in Platform settings, requiring newly created keys to expire within the configured limit."
The September 15 entry covers key creation governance. Administrators can now "allow only service-account keys, allow only user-owned project keys, or disable all new API key creation." Organization restrictions take precedence over project settings. The entry also states that existing API keys are unaffected.
Both entries point to the API keys section of OpenAI’s production best practices guide. That guide now says OpenAI strongly recommends setting an expiration date on each project key and establishing a regular rotation process.
None of this changes how keys authenticate. Requests still send the key the same way. With API key expiration, a key can now stop working on a date you choose.
How to set API key expiration on a new key
In the dashboard, keys are created per project. OpenAI’s help article on managing projects says you create and manage API keys "for each project on that project’s settings page." The expiration date is set in the same creation step.
Two points matter here. First, API key expiration is set at creation. OpenAI’s documentation does not describe extending a key after it is issued. Plan on replacing keys rather than stretching them. Second, the expiry applies to project keys. The changelog does not mention legacy keys.
Through the Administration API, API key expiration is a number of seconds. The reference for creating a project service account includes an optional expires_in_seconds parameter. It accepts values from 1 to 31,536,000, which is 365 days. If it is omitted, the reference says the key "does not expire unless the effective organization or project policy requires an expiration."
Admin API keys take the same parameter with the same range. Key objects in the Administration API reference include an expires_at timestamp, or null for a key with no end date. They also include last_used_at, which helps when you audit old keys.
Setting a maximum lifetime for an organization or project
The maximum lifetime is the control that matters most for an agency. Per-key API key expiration depends on whoever creates the key remembering to set it. A maximum lifetime makes it the default.
According to the production best practices guide, administrators set it "at the organization or project level in Platform settings." Once set, new keys must comply with the configured limit.
A few practical choices follow from that.
- Set it at the organization level first. That covers every project, including ones a colleague creates next month for a new client.
- Tighten individual projects where needed. A project for a pilot or a short campaign can carry a shorter limit than production work.
- Pick a period your team can actually keep. A 90-day limit you rotate on time is safer than a 30-day limit that causes outages and then gets raised.
OpenAI has not published a recommended lifetime. The 365-day ceiling on the Administration API parameter is the only hard number we found in the documentation.
What happens at API key expiration
The rule is simple. OpenAI’s help center article on API key safety says project keys "can be created with an expiration date after which any requests from those keys will be rejected."
The documentation describes no grace period for API key expiration. Several details are also missing as of late September 2026:
- Neither the help article nor the best practices guide mentions email reminders before a key expires.
- Neither page names the HTTP status code or error message an expired key returns.
- Neither describes extending or renewing a key after creation.
Treat all three as unknown until OpenAI documents them. In practice, assume an expired key fails like a revoked key. The chatbot on a client’s site stops answering. The plugin that drafts summaries in the CMS returns an error. A nightly job quietly fails.
OpenAI’s own guidance on the handover is direct. Before a key expires, "create a replacement, update your applications to use it, and revoke the old key once you’ve verified that the replacement works." The routine later in this piece is built around that sequence.
Service account keys, user keys and admin keys
Agencies will meet three kinds of OpenAI key. The differences decide which one belongs in a client’s production site.
| Key type | Owned by | Used for | Notes |
|---|---|---|---|
| User-owned project key | A person in the project | API requests within one project | Permissions can be All, Restricted or Read Only |
| Service account key | A service account in the project | API requests within one project | Not tied to a person; permission controls not shown at creation |
| Admin API key | The organization | Administration endpoints only | Only organization owners can create one |
OpenAI’s projects article describes a service account as "a pseudo-user designed for system access, distinct from individual user accounts." Service accounts are scoped to a single project. That makes them the natural home for a production integration. The key does not depend on one staff member.
User-owned keys do depend on their owner. The Administration API’s project key object includes an owner_project_access field, which reports "whether the API key’s owner currently has effective access." When a developer leaves the agency, check which keys they own before removing them from projects.
Permissions differ too. OpenAI’s article on API key permissions lists All, Restricted and Read Only for user-owned keys. It also notes that "the key-creation dialog does not show these permission controls for service account keys."
Admin keys are a separate category. The Administration API overview states that "Admin API keys cannot be used for non-administration endpoints." They manage projects, users and keys. They should never sit in a client website.
Restricting who can create keys at all
The September 15 governance controls address a different problem. API key expiration limits how long a key lives. Governance limits which keys get created in the first place.
The three options are:
- Service-account keys only. Staff cannot create personal keys in the project. Every key belongs to a service account.
- User-owned project keys only. The reverse, useful where every request should trace back to a named person.
- No new keys. Nobody can create keys until the setting changes.
For client production projects, "service-account keys only" fits most agencies. It stops a developer from creating a personal key during a late-night fix and leaving it in a config file. For a client project that has been handed off or paused, "no new keys" is a clean way to freeze it.
As with API key expiration, the changelog says existing keys are unaffected. Turning on "service-account keys only" does not remove the personal keys already in the project. You still have to find them and revoke them.
Where an agency’s keys actually live
Before you can rotate keys, you need a list of every place one is stored. For agencies serving nonprofits, associations and universities, the usual locations are few but scattered.
WordPress plugin settings. Many AI plugins ask for the key on a settings screen. Unless the plugin reads a constant or environment variable instead, that value usually ends up in the database. That makes it readable to anyone with database access or a backup file. Our guide to moving WordPress secrets into environment variables covers the alternative. Sites on Pantheon can also use platform-level secrets for WordPress.
Drupal’s Key module. The Drupal AI module requires the Key module for provider credentials. Key supports configuration, file, environment and external providers. The module’s own page labels the configuration provider "development only," because it stores the key in the database. Check which provider each site uses.
Environment files. A .env file on a server is better than the database, but copies spread. Local machines, staging servers and old deploy artifacts often hold the same value.
CI and deployment secrets. GitHub Actions secrets and similar stores are the safest of the four. They are also a target. Our coverage of the npm worm that harvests CI credentials showed attackers now look for AI provider keys by name.
Developer tooling. Workflow builders, agent frameworks and local tools often hold keys too. We argued in our Langflow vulnerability analysis that this class of software is a credential store in practice.
Rotation routine, part one: inventory and policy
The routine assumes one OpenAI project per client, which keeps billing, limits and access separate. Each step includes a check, so you know it worked before moving on.
-
Inventory every key. List keys per project in the dashboard or the Administration API. Record the owner,
last_used_atandexpires_at. Check: every key maps to one known site, pipeline or tool. -
Revoke keys nobody can place. A key with no known location and no recent use is a liability. Check: nothing reports an error afterward.
-
Set the organization’s maximum lifetime. Choose a period your team can keep, then tighten client projects if needed. Check: a test key in any project cannot exceed the limit.
-
Limit new keys to service accounts. Apply it to client production projects. Check: those projects no longer allow a personal key.
Rotation routine, part two: swap each key without an outage
-
Create the replacement before the old key expires. Use a service account named after the client and site. Check: one test request with the new key succeeds.
-
Update the key in every location. Change the plugin setting, Key module entry,
.envfile or CI secret. Check: the feature works on the live site, and the new key’slast_used_atupdates. -
Revoke the old key. Do it only after step 6 checks out. Check: the site still works.
-
Put the next API key expiration on a calendar. Add a reminder two weeks before each
expires_at. Check: every active key has a dated reminder and an owner.
Two habits make this sustainable. Rotate every client in the same week, so it becomes a scheduled task rather than a scramble. And turn on audit logging if it is not already on. OpenAI’s admin and audit logs article says logs track "the lifecycle of API Keys," including creation, updates and deletion. Once audit logging is enabled, it cannot be disabled.
Replacing stored keys in CI with workload identity
For pipelines, there is an option that removes the stored key entirely. The help center now recommends using "workload identity federation instead of storing a long-lived OpenAI API key" for supported workloads.
OpenAI’s workload identity federation guide lists supported providers. They include GitHub Actions, AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure, Kubernetes, X.509 certificates and SPIFFE. The workload presents a short-lived token from its own provider. OpenAI exchanges it for a short-lived OpenAI access token.
The principal is a Platform service account in a specific project. For GitHub Actions, the workflow needs the id-token: write permission. Mappings can check the repository, branch and workflow file before OpenAI issues a token.
This does not help a WordPress or Drupal site on shared hosting, which still needs a stored key and still benefits from API key expiration. It does remove one of the most exposed copies: the key sitting in CI secrets for a build or test job.
One more control is worth a look for production. The help center describes IP allowlisting, where requests from addresses outside the list "are rejected," even with a valid key. For a client site with a fixed server address, that turns a leaked key into a much smaller problem. Combined with a short lifetime, it limits both how long and from where a stolen key works, which matters given the infostealer campaigns targeting AI accounts. Authentication is only one layer, as the first MCP flaw in the KEV catalog showed.
Frequently Asked Questions
When did OpenAI add API key expiration?
The OpenAI API changelog dates API key expiration and the maximum key lifetime setting to September 10, 2026. The controls over who can create keys followed on September 15, 2026.
Does API key expiration apply to existing OpenAI keys?
No. According to the changelog, the maximum lifetime applies to newly created keys, and the governance controls leave existing keys unaffected. Keys created before September 10 keep working until you revoke them.
What happens when an OpenAI API key expires?
OpenAI’s help center says requests from an expired project key are rejected. As of late September 2026, OpenAI had not documented a grace period, a reminder email or the exact error returned.
Can I extend an API key expiration date?
OpenAI’s documentation does not describe extending a key after creation. Plan to create a replacement before the date, switch your application to it, then revoke the old key.
What is the longest expiration I can set?
The Administration API accepts up to 31,536,000 seconds, which is 365 days, for service account and admin keys. OpenAI has not published a separate cap for the dashboard, so confirm there when you create a key.
Should a client website use a service account key or a personal key?
A service account key, in most cases. It is not tied to a staff member, so it keeps working when people change roles or leave. It is also scoped to a single project.
Can an admin API key call models?
No. OpenAI’s Administration API overview says admin keys cannot be used for non-administration endpoints. They manage projects, users and keys, and only organization owners can create them.
Where do WordPress and Drupal sites usually store the key?
WordPress AI plugins often save it in the database through a settings screen. Drupal’s AI module uses the Key module, which can read from configuration, a file, an environment variable or an external service.
How often should an agency rotate OpenAI keys?
OpenAI does not recommend a specific period. Pick one your team can keep across every client, set it as the maximum lifetime, and rotate all clients in the same week.
Can CI pipelines avoid storing an OpenAI key at all?
Yes, for supported platforms. Workload identity federation lets GitHub Actions, major clouds and Kubernetes exchange their own short-lived identity token for a short-lived OpenAI access token tied to a service account.
