OpenAI API Key Expiry Needs a Rotation Plan

OpenAI gave project API keys an expiration date on September 10, 2026. That turns credential rotation into scheduled production maintenance: an unattended agent now needs an owner, a replacement window, and a verification step before its key runs out.

The change is a deadline, not automatic rotation

An API key is the secret an application sends to prove it may use the OpenAI API. Teams often place one in a secret manager, point a scheduled worker at it, and leave the worker alone until something breaks.

OpenAI now lets you set an expiration date when you create a project API key. An administrator can also set a maximum key lifetime in Platform settings at the organization or project level. If that policy exists, newly created keys must expire within the allowed lifetime.

These controls do different jobs:

The parent rule matters. A project setting cannot make a key live longer than the organization policy permits. The project has to stay inside that boundary.

This is not an automatic rotation system. OpenAI's production guidance tells you to create a replacement before expiry, update the applications, verify the replacement, and only then revoke the old key. Your team still owns every handoff in that sentence.

Rotate now after a leak

Verified October 23, 2026: The October 21 disclosures from Railway and LiteLLM require an incident response even when a key has no expiration date. Check exposure now; the scheduled maintenance plan below does not justify leaving a leaked credential active.

• Railway: Its security disclosure says an unauthorized party may have accessed encrypted customer environment variables and decrypted some. Railway says it will email customers as it confirms affected accounts, but recommends that all users immediately rotate all stored environment variables, including API keys, plus private registry credentials, and inspect service logs. No email is not an all-clear.
• LiteLLM: Compare installation records and container digests with its incident report. On October 21, compromised litellm==1.107.0 wheels were available on PyPI from 11:39:51 to 13:23 UTC. Container tags v1.107.0, latest, main-latest, and main-stable were affected on Docker Hub from 11:46:56 to 14:20 UTC; the affected GHCR tags were unavailable by 13:51 UTC, after exposure began at 11:46:56 UTC. Treat installation or execution of an affected artifact as compromise. LiteLLM says earlier versions and its private enterprise registry were unaffected by this incident.

Contain the environment before giving it new secrets. LiteLLM recommends rebuilding affected images and environments; starting Python, including pip, can rerun the malware. Rotate every provider key in the proxy database and other reachable credentials, including proxy master and virtual keys. Replacing only the OpenAI key is insufficient.

For a contained environment where a prompt handoff is possible, use this order. If abuse is active or a safe deployment is blocked, revoke the exposed key immediately and accept the interruption.

1. Create the new key. In the correct OpenAI project, create a replacement with a policy-compliant expiry. For an unattended service, use a project service account, a machine identity, and restrict its key permissions to what the application needs. The OpenAI API key setup guide covers the creation flow.
2. Deploy and verify it. Put the replacement in the clean deployment's secret store, update every worker and scheduler, and confirm a real request succeeds. Keep this overlap brief.
3. Revoke the old key. Delete the exposed credential as soon as the replacement works. OpenAI's project-key deletion API also handles service-account-owned keys without deleting the service account or its other keys.
4. Watch usage. Inspect OpenAI's Usage page and application logs for unexpected activity. Review spend controls: alerts notify; hard limits stop affected traffic after tracked spend reaches the cap, with possible overshoot while enforcement propagates. Neither replaces revocation.

Anthropic: In Claude Console, create a key, deploy it through ANTHROPIC_API_KEY, verify requests, then delete the old key; watch the Console's Usage charts.

Google: Create a replacement in Google AI Studio or Cloud Console, deploy and verify it, disable or delete the old key, then audit API usage and billing logs in Cloud Console.

The business change is a maintenance budget

The feature does not change token prices. It changes the labor and interruption math around every scheduled job that authenticates with a project key.

Here is a simple planning model. These are workload assumptions, not OpenAI limits.

Assume one project has an agent scheduled every 15 minutes, or 96 runs per day. A planned rotation takes 30 minutes of operator time. If the team chooses a quarterly schedule and values loaded operator time at $75 per hour, rotation costs $37.50 each and $150 per project per year. Ten projects turn that into a visible $1,500 annual maintenance line.

Now assume a key expires unnoticed and the interruption lasts 4 hours. That window contains 16 scheduled starts. If each missed run takes 10 minutes to inspect and replay, recovery takes 160 minutes, or 2 hours 40 minutes. At the same $75 rate, labor alone is $200, before delayed customer work, missed reports, or lost revenue enter the calculation.

That is the consequence. Expiration reduces the time a forgotten credential can remain valid, but it converts a hidden security risk into a recurring operating task. The task needs time in the budget and a named person on the calendar.

If the real concern is runaway API spend, key expiry is the wrong control. The separate AI Agent API Budget Controls guide covers that boundary. A budget cap and a credential deadline can both interrupt work, but they solve different problems and need different recovery plans.

Who needs this workflow

A solo founder with an unattended SaaS agent

A founder running a support summary, document processor, or data-enrichment job should attach the credential to an owner, even if that owner is the founder. Record which scheduler, deployment, and secret entry use the key. Start the replacement while the current key still works, then watch a real scheduled run finish on the new secret.

The payoff is continuity. The rotation becomes a small planned release instead of a customer reporting that yesterday's work never arrived.

An agency operations lead with client projects

An agency can give each client project its own rotation record: project, key owner, deployed jobs, expiration, replacement status, and verification result. That makes the labor countable. It also stops one forgotten client automation from hiding inside a shared credential nobody wants to touch.

The payoff is margin protection. Rotation time can enter delivery planning, and the account lead knows which client jobs need checking before the old secret disappears.

A platform team setting the organization rule

A backend or platform team should decide the organization maximum first, then let individual projects adopt a limit that stays inside it. The team can use a shorter project policy where the workload or risk calls for one, but it cannot use a longer project lifetime to escape the organization ceiling.

The payoff is consistent governance. The same team should publish the replacement procedure at the moment it publishes the lifetime rule. A deadline without a handoff is just a future incident with a date attached.

A security administrator cleaning up older credentials

A security administrator should treat the new-key policy and the old-key inventory as two tracks. Enforce the maximum lifetime for newly created keys, then separately find existing project credentials and assign owners. The published scope does not promise that those older keys will expire on their own.

The payoff is an honest rollout. The organization improves new credentials immediately without confusing a forward-looking policy with a completed cleanup.

Rotate one key without creating a gap

For planned expiry, the exact deployment buttons depend on your host and secret manager. The handoff sequence does not.

1. 1

   Confirm the policy and the owner

   Check the organization maximum and the project's maximum before creating the replacement. If API Key Governance blocks the required key type or new key creation, involve the administrator before the rotation window. Record the current key's project, every job that uses it, the person responsible, and the point when the replacement work begins.

2. 2

   Create the replacement early

   Create a new project API key while the old key is still valid. Give the replacement an expiration that complies with the active policy. Do not put it in source code or a public repository.

3. 3

   Stage it through the secret store

   Save the replacement as a new version in the environment variable or secret-management path your application already uses. Update one controlled worker or test path first. OpenAI also supports separate staging and production projects when you need stronger isolation between testing and live work.

4. 4

   Verify the deployed job

   Run the application through its real authentication path. Check the request result, the job output, the queue, and the worker logs. OpenAI's Usage page can provide another signal once key tracking is enabled, but a dashboard view does not replace checking the business result.

5. 5

   Roll forward, then retire

   Update every deployment, scheduler, CI secret, and long-running worker that used the old credential. Confirm that the new key works across those jobs. Revoke the old key only after that verification is complete.

What the feature still leaves with you

Use your account's policy and the documented limits of the key-creation or update method you use. For example, the project-key update API caps expires_in_seconds at 31,536,000 seconds; a stricter organization or project policy still applies. Your team still owns the reminder and replacement rollout.

The setting also cannot tell you where a secret was copied. It does not know that a developer pasted the key into a CI system, a serverless environment, a local machine, and a backup script. Inventory is the part most teams will underestimate.

Verification is the other hard part. A successful test request proves that the replacement is valid. It does not prove that every scheduled worker received it. That is why the job list belongs in the rotation record and why, during planned rotation, the old key stays valid until the list is checked.

What to do this week

Act now if a scheduled agent, batch worker, customer automation, or backend service uses a project API key and your organization plans to enforce a maximum lifetime. Put the rotation workload in the operating budget before the policy creates the first deadline.

You can wait on a full scheduled-expiry rollout if no maximum lifetime is enabled, no current project key has an expiration date, and there is no suspected exposure. Still inventory the credentials and owners now. The new control makes the eventual direction clear, and OpenAI already recommends regular rotation.

Existing keys are not described as retroactively expiring, so there is no basis for claiming every old deployment suddenly has a September deadline. That is not a reason to ignore them. It is a reason to inspect them separately instead of trusting the new policy to clean up the past.

On Monday, choose one production project. Assign the credential to an owner, stage a replacement while the current key still works, check every deployed job on the new key, and then retire the old one. That four-part handoff is the rotation plan.

For more plain-language operating notes like this, join the newsletter.