September API key controls: rotate access without surprising your workers

Documentation snapshot: October 14, 2026. This guide discusses the dated release described below; check the linked official documentation for current API behavior and account availability before implementation.

A key that works forever is convenient right up until nobody remembers what still uses it. September 2026 brought useful OpenAI API controls: project-key expiration on September 10 and key-creation governance on September 15. The release record and production guidance were checked October 14. Here is how I would turn the settings into an operational improvement.

Inventory references, not secret values

List services, owners, environments, credential references, and rotation paths. Do not copy key contents into a spreadsheet. Distinguish developer experiments from unattended production workers. If nobody owns a credential, resolve that before setting a short expiry and hoping alerts catch the fallout.

Creation restrictions can allow service-account keys, user-owned project keys, or no new keys. Organization restrictions take precedence over project settings. Crucially, these creation rules do not revoke existing keys. Treat them as one control in the process, not as proof that old access disappeared.

Test rotation in a disposable environment

Use an authorized test project and the normal secret-management path. Create a replacement with the intended permissions and lifetime, update the service's secret reference, and exercise a harmless request. Confirm the worker actually loaded the new reference rather than continuing with a cached old value. Keep credentials out of logs and command tracing.

Then revoke or retire the previous credential according to your policy and repeat the check. Test an expired or rejected credential too: the application should report an authentication problem clearly, avoid infinite retries, and notify the responsible operator. A retry storm cannot repair expired authorization.

Choose expiry from the recovery process

Shorter lifetimes reduce the period in which a forgotten credential remains useful, but they also require reliable renewal. Pick a period your automation and staffing can support. Alert before expiration with enough time to act, and include the owner and secret reference rather than the secret itself.

For production, stage the policy in one service, observe a full renewal cycle, and then broaden it. Document what happens if renewal fails during a weekend or an incident. Have a reviewed recovery route that does not involve pasting a personal key into a shared terminal.

These controls are useful because they make access lifecycle more explicit. They do not replace least privilege, spending limits, application authorization, or incident response. My acceptance test is practical: the intended worker can continue, the retired key cannot, and the next operator can understand the evidence without ever seeing the credential.