OpenAI lets an administrator decide who may create an API key

OpenAI's API changelog recorded on 15 September 2026 that it [added API key creation governance controls at the organization and project levels] . The control is over who may make a key, not over what a key can do: [an administrator can allow only service-account keys, allow only user-owned project keys, or disable all new API key creation] .

What changed

Three settings, and one rule about how they combine. [A restriction set on the organization takes precedence over a project's settings, and keys that already exist are unaffected] — so turning creation off does not break what is running, and a project cannot loosen what the organization has tightened.

The distinction the three choices rest on is between a key that belongs to a service account— an identity that is not a person — and a key a person owns inside a project. An organization that allows only the first is saying that anything calling the API in production must do so as a service, not as somebody's account; one that allows only the second is saying the opposite for its projects; one that disables creation entirely is freezing the set of keys it already has. [The changelog entry points to OpenAI's production best practices for the details] .

What it was before

Before this, the page's own September entries had already moved on key handling rather than key creation. [Five days earlier, on 10 September 2026, the same page recorded that expiration dates can be set when a project API key is created] , and [that entry also states that an administrator can enforce a maximum key lifetime at the organization or project level in Platform settings, so that a newly created key must expire within the configured limit] . A key could be made to die on a date; now it can be stopped from being made at all.

[The direction is older than this month: on 26 May 2026 the page recorded workload identity federation, which lets a trusted workload exchange an externally issued identity token for a short-lived OpenAI access token without storing a long-lived API key] . Read together, the three entries are one movement — fewer long-lived secrets, and fewer hands able to mint them.

What it means for you

If you are the only person in your account, nothing changes today: you are the administrator and the key holder at once, and the setting you would choose is the one you already have.

If you share an organization with other people, this is a setting to decide rather than discover. Ask which of the three states your organization should be in, and check it before someone finds out the hard way that their key will not be created. A team whose production traffic already runs on service accounts can turn user-owned project keys off and lose nothing. A team where every engineer has a personal key will feel the change as a refusal, so decide first and announce it, rather than switching and waiting for the support message.

Two things are worth checking in the same sitting, because the entries above make them cheap: whether your existing keys have an expiry at all, and whether any of them belongs to a person who has left. Neither is affected by the new control — the setting governs creation, not what is already issued — which is exactly why it is the moment to look.

The source

OpenAI's API changelog, the entry of 15 September 2026, with the entries of 10 September 2026 and 26 May 2026 on the same page.