What OpenAI Changed
OpenAI's September 15, 2026 API changelog introduced API-key creation governance at organization and project levels. Administrators can restrict new creation to service-account keys, restrict it to user-owned project keys, or disable all new API-key creation. The corresponding production best-practices guide places the controls in the API Key Governance section of Platform settings.
The precedence rule matters more than the saved value on a project. Organization restrictions always win. A project may become more restrictive, but it cannot relax its organization's policy. That means a project page that appears to permit a user-owned key is not evidence that creation will succeed when the organization permits service-account keys only.
Both official sources say existing API keys are unaffected. Enabling “service-account keys only” does not convert, expire, rotate, revoke, or disable a user-owned key that already exists. Treat the policy rollout and the existing-key migration as two linked workstreams with separate evidence.
Inventory the Keys You Already Have
Start from both sides of the connection. In the OpenAI Platform, list the keys and service accounts visible to the administrators responsible for each project. In your systems, search secret-manager entries, deployment configuration, CI variables, local runbooks, and agent tool configuration for key references. Record references and fingerprints where your tooling exposes them; never copy secret values into the inventory.
The Usage page can add evidence, but it cannot replace the inventory. OpenAI says tracking is not enabled by default for keys generated before December 20, 2023. Later keys have tracking enabled, while historical use that was not tracked appears as Untracked. A blank per-key result therefore means “no tracked evidence found,” not “safe to revoke.”
| Project | Key owner/type | Consumer and location | Evidence | Decision |
|---|---|---|---|---|
prod-api | User-owned, release engineer | OPENAI_API_KEY in deployment secret store | Deployment revision and recent tracked use | Replace with service-account key; verify; revoke old |
eval-lab | Service account | Nightly evaluation runner | Secret version and last successful run | Keep; add expiry and rotation owner |
prototype | User-owned, former team member | No consumer located | No tracking; repository search negative | Quarantine, observe, then revoke with rollback owner |
These rows illustrate the evidence shape, not actual OpenAI defaults. Add a row even when you cannot identify the consumer. Unknown ownership is a migration state that needs an owner and a deadline, not a reason to silently keep a credential forever.
Write the Organization and Project Policy
Document intent before changing settings. At organization level, state which credential owner types may be created and who can approve exceptions. At project level, state whether the project matches the organization or adds a narrower rule. Include the effective outcome you expect after precedence, not just screenshots of two independently saved controls.
organization: example-org
organization_policy: service-account keys only
project: prod-api
project_policy: no additional restriction
expected_effective_policy: service-account keys only
existing_key_plan: inventory complete; 3 rotate, 1 keep, 1 revoke
test_owner: platform-admin@example.invalid
rollback_owner: security-oncall@example.invalidDo not choose service-account-only merely because it sounds stricter. Use it where a workload owns the credential and the team can operate that identity through deployment, rotation, and incident response. If a person legitimately owns an interactive development key, record that decision and constrain it at the appropriate project. For a broader identity migration method, use the AI authentication migration plan. The Anthropic personal-to-service-account key guide covers that provider's distinct key model; it is useful as an inventory pattern, not as evidence for OpenAI behavior.
Run a Four-Case Creation Test
Use a disposable project when your environment permits one, name every attempted key so it is easy to remove, and delete successful test credentials after collecting sanitized evidence. The fixture below is proposed; it was not run for this article. Keep the administrator, project, and test procedure fixed so policy is the only intended difference.
| Case | Organization policy | Project policy | Attempt | Expected result |
|---|---|---|---|---|
| 1: service positive | No added type restriction | Service-account keys only | Create service-account key | Allowed |
| 2: user negative | No added type restriction | Service-account keys only | Create user-owned project key | Blocked |
| 3: user positive | User-owned project keys only | No additional restriction | Create user-owned project key | Allowed |
| 4: precedence negative | Disable all new key creation | Attempt to allow user-owned keys | Create user-owned project key | Blocked by organization restriction |
For every case, record the policy values, acting role, key type, timestamp, sanitized result, and whether any credential was actually issued. A denied creation is not enough by itself: the two positive controls prove that the actor and procedure can create each key type when policy permits it. If a positive case fails for permissions, account availability, or an unrelated error, mark the fixture inconclusive rather than calling governance successful.
After case 4, restore the intended organization and project policy and repeat one expected positive and one expected negative. This catches a common rollout error: proving the temporary test configuration but never verifying the final state.
Test Existing Keys Separately
Select one existing user-owned test key before enabling a restrictive creation policy. Run a harmless, pre-approved authentication check and save only the status and request identifier, not prompts or secret material. Apply the new creation policy, prove that the matching new-key attempt is blocked, and repeat the same existing-key check. The documented expectation is that the existing key remains unaffected.
That result is not a recommendation to keep the key. It proves only that creation governance did not remove it. Decide each inventory row explicitly: keep with an owner and review date, rotate within the same identity type, replace with a service-account or user-owned key that matches the policy, or revoke because the consumer is retired.
For rotation or replacement, follow the order in OpenAI's production guide: create the replacement, update the application, verify the new credential works, and then revoke the old one. OpenAI also recommends setting expiration dates on project keys and maintaining regular rotation. A maximum lifetime can be enforced at organization or project level, with the organization limit constraining the project, but choose the duration from your operating and recovery requirements rather than inventing a universal number.
Close the Rollout with Evidence
The final record should contain the organization rule, every project override, the four creation results, the post-restore positive and negative checks, and one decision per existing credential. Link each replacement to the deployment that adopted it and each revocation to the verification that preceded it. Keep the person who approved policy separate from the workload identity that receives the production key where your operating model allows it.
Re-run the inventory after migration. Repository and configuration searches should no longer find retired references, successful applications should identify the intended replacement, and unresolved rows should have a named owner and deadline. The useful outcome is not a green toggle in Platform settings. It is a reproducible proof of what can be created now, plus an accountable disposition for every key the new toggle deliberately leaves untouched.