OpenAI API Key Governance: Issuance Before Rotation

On September 15, 2026, OpenAI added organization and project controls that can allow only service-account keys, allow only user-owned project keys, or disable new key creation. Five days earlier it added expiration dates and enforceable maximum lifetimes for new project keys. The API changelog is unusually explicit about the boundary: organization restrictions override project settings, and the creation rules do not alter existing keys.

That boundary is the useful part. It tells an engineering leader exactly where provider policy ends and the team's operating control begins.

Treat issuance as the first privileged action

Most key programmes start with rotation. That is late. The first privileged action is minting the credential.

Before a key exists, require one small request record:

The gate should reject requests without an accountable owner, a single workload, and an expiry. It should also reject a production credential requested for a person's laptop. Production workloads get non-human identities; interactive exploration gets user-owned project keys in a non-production project.

OpenAI now lets an administrator encode part of that split directly. The production guide says administrators can restrict new creation to service-account keys, user-owned project keys, or neither, at both organization and project scope. A stricter organization rule cannot be loosened by a project.

That makes a simple baseline possible:

organization:
  key_creation: service_accounts_only
  maximum_lifetime_days: 90

projects:
  development:
    key_creation: user_project_keys_only
    maximum_lifetime_days: 30
  staging:
    key_creation: service_accounts_only
    maximum_lifetime_days: 30
  production:
    key_creation: service_accounts_only
    maximum_lifetime_days: 60

This is a policy sketch, not an OpenAI configuration format. The important move is making the decision explicit before anyone opens the dashboard.

Creation policy is not credential inventory

The September controls apply only to new keys. Existing credentials are unaffected. That means enabling the restriction can leave the oldest and least understood credentials running indefinitely.

Inventory them before declaring the control finished. For every existing key, record the visible identifier or fingerprint, owner, workload, project, creation time, last observed use, intended expiry, secret-store location, and revocation state. Never copy the plaintext secret into the inventory.

Then classify each key:

• Retain: owner, workload, scope and use are all known.
• Rotate: it is legitimate but violates the new lifetime or storage policy.
• Revoke: no owner, no current workload, or no observed need remains.
• Investigate: evidence is incomplete or contradictory.

The investigate state matters. An unowned key is not safe because traffic still uses it, and it is not safe to revoke merely because the owner is missing. Trace the workload first. Unknown is a separate operational state, not a softer word for delete.

OpenAI's guide also notes that key-level usage tracking is available, with older keys potentially shown as Untracked until tracking is enabled. Usage telemetry helps find consumers, but absence of a dashboard event is not proof that no rarely run job still depends on the key.

Rotation is a migration with readback

Safe rotation is not “create new, delete old.” It is a two-credential migration with an observation step.

1. Create the replacement under the current policy.
2. Store it as a new secret version without overwriting the old value.
3. Move one canary instance or low-risk job to the new version.
4. Execute a representative request and retain its application receipt.
5. Confirm provider usage and application telemetry identify the new credential.
6. Roll the new version across the workload.
7. Observe one full business cycle, including scheduled jobs.
8. Revoke the old credential.
9. Prove the old version now fails and the workload still succeeds.

The OpenAI production guide recommends creating a replacement before expiry, updating applications, verifying the replacement works, and only then revoking the old key. The sequence above turns that recommendation into evidence an operator can review.

The rotation record needs more than “completed”:

{
  "rotation_id": "rot_2026_09_24_support_prod",
  "workload": "support-agent-prod",
  "old_key_fingerprint": "key_7f2c",
  "new_key_fingerprint": "key_b914",
  "canary_receipt": "req_01J...",
  "new_key_observed_at": "2026-09-24T16:20:00Z",
  "old_key_revoked_at": "2026-09-24T17:05:00Z",
  "post_revoke_probe": "passed",
  "operator": "platform-oncall"
}

Those values are illustrative. In production, bind the record to real provider and application receipts.

Four failure modes the dashboard cannot prevent

A valid key with the wrong authority

Authentication answers whether OpenAI recognizes the credential. It does not prove the calling workload should use the selected model, tool, data store, region or budget. Keep model access, tool permissions, network egress and spend limits in the project and workload policy around the key.

A service-account key shared by several workloads

A non-human identity is not automatically least privilege. If three agents share one key, cost and incident attribution collapse into the same principal. Give each production workload its own identity and project when its owner, budget or blast radius differs.

An expiring key with no rotation owner

Expiry converts a permanent exposure into a scheduled outage unless somebody owns the replacement. Every expiry should create work before the deadline, not at it. Alert on the next rotation date, the accountable owner, and the unresolved consumers.

A revoked key with no negative test

Revocation is incomplete until the old credential is rejected. A stale container, queue worker or disaster-recovery environment may still hold it. Probe the retired version after revocation, watch for authentication failures, and keep the recovery path ready until the observation window closes.

The minimum release gate

A team does not need a large secrets platform to make this safer. It needs five enforceable checks:

1. Creation is restricted. Human keys are limited to development; production accepts workload identities only.
2. Every new key expires. Maximum lifetime is enforced at organization or project scope.
3. Every key has an owner and one workload. Shared credentials fail the gate.
4. Every rotation has canary and readback evidence. Acceptance is observed, not inferred from a successful secret write.
5. Every revocation has a negative probe. The old key is proven dead after the new path remains live.

Run four representative tests before adopting the control:

OpenAI's settings now provide a stronger issuance boundary. The operational win comes from joining that boundary to inventory, workload ownership, observed rotation and verified revocation. That is the point where API keys stop being strings in environment variables and become a controlled production release.