OpenAI Now Enforces API Key Expiration at the Org Level: What Gateway Operators Must Audit Today

On September 10, OpenAI shipped org-level and project-level enforcement for API key expiration. The feature is not a new concept — per-key expiry dates have existed for some time — but enforcement is new: an organization admin can now set a maximum lifetime, and any key created after that policy is active must expire within the configured limit. Keys cannot be created without an expiry, and project limits cannot exceed the org limit.

This lands about seven weeks after Anthropic made expiry dates mandatory at key creation — a different mechanic (Anthropic requires an expiry field, OpenAI sets a ceiling). Both of the two largest providers now enforce key rotation as policy, not just good practice.

How enforcement works: org limits cap project limits

The setting lives in Platform settings. Once an org admin sets a maximum key lifetime, every new project API key must carry an expiry that falls within that ceiling. Project-level overrides can tighten the ceiling but cannot loosen it — if the org sets 90 days, no project can issue a key that lives for 180 days.

The enforcement is forward-looking. OpenAI has not retroactively shortened existing keys. A key created before the policy was configured keeps its original expiry (or remains indefinite if it had none). The policy bites only when new keys are created.

What that means operationally: if you set the org-level maximum today and your team creates replacement keys tomorrow, every new key will comply. But the long-lived keys already sitting in your Kubernetes secrets, CI pipeline env vars, or gateway config file are untouched. You have to find and rotate them yourself.

What existing keys actually inherit — and what doesn't change

Three scenarios worth being explicit about:

A key with no expiry, created before the policy — still valid, indefinitely. Nothing has changed for it. The platform dashboard will not flag it as non-compliant or refuse it.

A key with an expiry that exceeds the new org maximum, created before the policy — also still valid. The key lives until its existing expiry date. The org ceiling does not retroactively shorten it.

A key created after the policy is set — must expire within the org maximum. Creating a key without an expiry, or with an expiry beyond the maximum, returns an error.

The practical risk window: organizations that set the maximum today will end up running a mixed fleet — new keys are bounded, old keys are not. That split fleet is the audit problem, not the policy itself.

Anthropic vs OpenAI: two different enforcement models

If your gateway proxies requests to both providers, you now have two key rotation requirements that work differently.

Anthropic's approach, introduced in July, requires an expiry date at the time of key creation. There is no org-level ceiling to set — the requirement is unconditional. Every new Anthropic key must have an explicit expiry. You cannot create an indefinite key regardless of admin settings.

OpenAI's approach is conditional on admin configuration. If no org admin sets a maximum, expiry dates remain optional for new keys. The enforcement only activates when an admin explicitly enables it. Organizations that have not touched the setting today are not automatically affected.

The difference matters for cross-provider key management automation. An Anthropic integration must always pass an expiry. An OpenAI integration might or might not need one, depending on whether your org admin has configured a ceiling. If you are writing shared key-issuance tooling for a multi-provider gateway, you need to query org settings before assuming OpenAI behaves the same way as Anthropic.

The direction is consistent across both providers: key rotation is becoming infrastructure, not a best-practice recommendation.

The gateway is the highest-risk point in your key inventory

Most AI gateways authenticate to upstream providers using a small number of long-lived API keys rather than short-lived credentials. Those keys typically live in environment variables, Kubernetes secrets, or a secrets manager — and they often exist outside the rotation disciplines applied to IAM roles or OAuth tokens, because until recently neither provider enforced rotation.

The structural problem: a gateway key is reused for every request forwarded to the provider. A single leaked gateway key exposes the full traffic volume routed through it, not just the requests from one user or one service. Gateway keys are high value and often receive less rotation attention precisely because they are shared infrastructure.

The three highest-risk patterns to look for in your inventory:

Keys that predate expiry enforcement — any API key created before a provider implemented expiry requirements. These keys have no expiry date and will remain valid indefinitely unless you manually revoke and rotate them.

Keys embedded in configuration files committed to version control — common in infrastructure-as-code setups where the key is rotated by updating a secret reference, but the committed history retains the previous value.

Keys shared across multiple services or environments — a gateway key used in both staging and production cannot be rotated on a per-environment basis without updating both, which increases the chance one environment is left on the old key.

Your operator audit checklist

Step 1: Inventory existing keys. In Platform settings → API keys, export or review all active keys. Note which ones lack an expiry date and when each was created. These pre-policy keys are your residual risk.

Step 2: Enable org-level enforcement if you haven't. Decide on a maximum lifetime appropriate for your rotation cadence — 30, 60, or 90 days are common choices. Setting this does not affect existing keys, but it prevents new keys from going indefinite.

Step 3: Rotate long-lived gateway keys first. New keys will comply automatically. Old keys require manual rotation: create a replacement, update the configuration in your gateway and any services that share the key, verify traffic, then revoke the old key.

Step 4: Update your key-issuance automation. Any tooling that creates OpenAI keys programmatically — Terraform providers, custom provisioning scripts, CI/CD onboarding flows — needs to pass an expiry date or will start failing after an org maximum is set.

Step 5: Align with your Anthropic rotation policy. Anthropic already requires expiry dates unconditionally. If you have a rotation schedule for Anthropic keys, extend it to OpenAI keys and set the org maximum to match that schedule.

Both providers now expect key rotation to be part of your operational baseline, not a periodic cleanup task. Operators who treat key management as infrastructure — automated issuance, scheduled rotation, monitored expiry — will have nothing to change. Operators who have relied on indefinitely valid keys as a convenience will need to build or adopt that automation before the first new key expires.

See the production best practices guide for the current enforcement details and the key management dashboard. TheRouter's docs cover how to configure provider credentials in a routing gateway for teams managing multiple upstream provider keys.