OpenAI Enforces API Key Expiration at the Org Level: What Every Gateway Operator Must Audit Now

Two things changed in AI key management this quarter, and they interact in a way that routing teams need to plan for explicitly.

On September 10, OpenAI added org-level API key expiration enforcement. Administrators can now set a maximum key lifetime in Platform settings — at the organization or project level — and any newly created key must expire within that limit. On the surface, this is a straightforward credential hygiene feature. In practice, it changes the key rotation calculus for any team that operates more than one major provider.

What changed and what it enforces

OpenAI now supports two distinct controls:

• Per-key expiration at creation: When creating a project API key, you can optionally set an expiration date. This existed before September 10.
• Org-level lifetime enforcement (new): Administrators can configure a maximum key lifetime at the organization or project level. Once set, all newly created keys must expire within that limit. Keys that would otherwise be created without expiration are now blocked.

The critical word is "newly created." Existing long-lived keys are not immediately expired. But any key rotation — manual or automated — must now produce a compliant key. If your provisioning scripts create keys without expiration dates and an org admin has enabled enforcement, the creation call fails.

How this differs from Anthropic's model

In July, Anthropic made key expiration mandatory at creation for all API keys — you cannot create an Anthropic API key without specifying an expiration. There is no bypass; the API call simply rejects keyless creation.

OpenAI's model is opt-in at the org level and enforced top-down from the administrator. A project that hasn't been placed under enforcement can still create unlimited-lifetime keys. This matters for multi-project orgs: enforcement granularity means some projects may be governed and others not.

The practical difference for routing operators:

For teams routing to both providers, the failure modes are structurally the same — your key provisioning tool must now pass an expiration — but the governance surface is different. Anthropic's rule is universal; OpenAI's depends on whether your org admin has enabled it.

The routing operator consequence

Most gateway operators manage provider API keys outside application code: stored in secrets managers, rotated by CI jobs, referenced by environment variables at runtime. The September 10 change breaks any key-provisioning flow that:

1. Creates OpenAI keys without an expiration date and is operating inside an org with max-lifetime enforcement enabled.
2. Assumes a key provisioned today will be valid indefinitely.

The second point is the subtler risk. Even if enforcement is not yet enabled in your org, the feature is now available to administrators. Key rotation tooling that doesn't support expiration dates is now one admin config change away from breaking.

Concretely: if your gateway reads a provider key from a secret at startup and that key has expired, the request fails at the first outbound call, not at startup. Depending on your health-check configuration, this can be a silent failure that degrades only under traffic.

What to audit now

Four checks cover the exposure for most routing teams:

1. Inventory long-lived OpenAI keys. In Platform settings → API keys, sort by creation date. Any key created before expiration enforcement was available that has no expiration is your current risk surface if your org enables enforcement.

2. Check whether your org has enabled enforcement. Organization admins: Platform settings → Organization → API key settings. If a max lifetime is set, all key rotation tooling must be updated before the next rotation cycle.

3. Update provisioning tooling. Any script, Terraform resource, or CI job that calls the OpenAI keys API to create project keys must now optionally (or mandatorily, under enforcement) pass an expires_at parameter. The Python SDK's project_api_keys.create() accepts expires_at as an ISO-8601 timestamp.

4. Align with your Anthropic rotation policy. If you've already updated provisioning tooling for Anthropic's mandatory expiration, the same pattern applies to OpenAI. The target state for a two-provider shop: all keys have explicit expiration dates and are rotated on a schedule short enough that no key is within 24 hours of expiration when your system is under load.

What TheRouter users should watch

If you route through TheRouter to both Anthropic and OpenAI, the key management surface is provider-side — TheRouter uses your configured provider credentials and does not manage provider API keys directly. The operational implication is that key rotation on either provider needs to propagate to your TheRouter provider configuration. Short-lived keys that expire before rotation is complete will produce authentication errors on all requests routed to that provider until the credential is updated.

The practical recommendation: set key expiration windows generously relative to your rotation cadence. A key that expires every 30 days and is rotated on day 25 leaves a 5-day buffer; a key that expires every 7 days on a weekly rotation schedule leaves no buffer. Use TheRouter's provider configuration docs to confirm how provider credentials are loaded — hot-reload behavior varies by deployment mode.