OpenAI hat am 15. September 2026 neue Governance-Kontrollen für die Erstellung von API-Schlüsseln auf Organisations- und Projektebene angekündigt. Administratoren können neue Schlüssel auf Service Accounts beschränken, nur nutzereigene Projektschlüssel erlauben oder die Neuerstellung vollständig deaktivieren. Organisationsregeln haben Vorrang vor Projekteinstellungen. Für Unternehmen ist das ein wichtiger Schritt zu zentraler Kontrolle – allerdings nur für neue Schlüssel. Bereits vorhandene API-Keys bleiben laut OpenAI unverändert und müssen separat inventarisiert, bewertet und gegebenenfalls ersetzt werden.
Was die drei neuen Richtungsentscheidungen bedeuten
Die Kontrollen beantworten zunächst eine Identitätsfrage: Unter wessen Verantwortung darf ein neuer Schlüssel entstehen? Die passende Option hängt vom Betriebsmodell ab. Sie sollte nicht pauschal für alle Projekte gewählt werden, ohne Automationen, Entwicklungsprozesse und Notfallzugänge zu prüfen.
- Nur Service-Account-Schlüssel: passend für produktive Anwendungen, CI/CD und dauerhaft betriebene Automationen, bei denen die Identität nicht an eine einzelne Person gebunden sein soll.
- Nur nutzereigene Projektschlüssel: sinnvoll für klar abgegrenzte Entwicklungs- und Analysearbeiten, wenn persönliche Verantwortlichkeit, Projektzuordnung und Offboarding sauber gesteuert werden.
- Neue Schlüssel vollständig sperren: geeignet für stabile oder besonders sensible Bereiche, in denen Keys nur über einen kontrollierten Ausnahmeprozess, bestehende Identitäten oder alternative Authentifizierungswege bereitgestellt werden sollen.
- Projektregel unter Organisationsvorgabe: Teams können nur innerhalb des zentral erlaubten Rahmens entscheiden, weil die Einschränkung der Organisation laut OpenAI Vorrang hat.
Diese Zuordnung ist eine betriebliche Ableitung, keine von OpenAI veröffentlichte Eignungsgarantie. Ein Service Account ist nicht automatisch sicherer, wenn sein Schlüssel in Quellcode, Images oder ungeschützten Variablen landet. Ein nutzereigener Schlüssel ist nicht automatisch ungeeignet, wenn Lebenszyklus, Rechte und Ausscheiden des Mitarbeiters zuverlässig gesteuert werden.
Entscheidungsrahmen nach Umgebung und Verantwortung
Für produktive Systeme sollte die Identität möglichst dem Workload und nicht einer Person folgen. Das erleichtert Ownership, Rotation und Offboarding. In Entwicklungsumgebungen kann ein nutzereigener Projektschlüssel sinnvoll sein, sofern er auf das richtige Projekt begrenzt ist und keine produktiven Abhängigkeiten trägt. Für besonders regulierte Projekte kann eine vollständige Sperre neuer Keys angemessen sein, bis ein genehmigter Bereitstellungsprozess existiert.
Die Organisationsebene sollte dabei die nicht verhandelbaren Grenzen festlegen. Projekte können innerhalb dieser Leitplanken restriktiver werden, aber eine zentrale Vorgabe nicht aushebeln. Vor der Aktivierung muss das Plattformteam deshalb klären, welche Teams tatsächlich neue Schlüssel erstellen, welche Deployments davon abhängen und welche Ausnahmefälle legitim sind.
Rolloutplan: neue Regeln setzen und Altbestand bereinigen
Ein sicherer Rollout trennt Zukunftskontrolle und Bestandsbereinigung. Die neue Policy verhindert unerwünschte Neuerstellung; ein eigener Migrationsstrang behandelt vorhandene Keys. Beide Arbeiten sollten gemeinsam geplant, aber getrennt nachgewiesen werden.
- Schlüsselbestand erfassen: vorhandene API-Keys, Projekte, Owner, Einsatzorte, letzte bekannte Nutzung und abhängige Systeme dokumentieren. Unklare Einträge als Risiko markieren.
- Zielmodell definieren: pro Umgebungsart festlegen, ob Service Accounts, nutzereigene Projektschlüssel oder keine neuen Schlüssel zulässig sind; zentrale Mindestregel beschließen.
- Abhängigkeiten testen: CI/CD, Serveranwendungen, lokale Entwicklung, Analysejobs, Notfallprozesse und Secret-Stores auf den geplanten Erstellungsweg prüfen.
- Organisation zuerst konfigurieren: die übergreifende Grenze setzen und danach Projekte nur innerhalb dieses Rahmens differenzieren.
- Bestehende Keys migrieren: verwaiste oder personengebundene Produktionsschlüssel ersetzen, abhängige Systeme kontrolliert umstellen und alte Keys erst nach erfolgreichem Funktionstest entziehen.
- Ausnahmen begrenzen: Zweck, Owner, Ablaufdatum und Freigabe jeder Abweichung dokumentieren; dauerhafte Ausnahmen vermeiden.
- Nachkontrolle einplanen: neue Schlüsselereignisse, Nutzung, Kosten, Fehler und nicht zuordenbare Identitäten regelmäßig prüfen.
Welche Risiken trotz neuer Policy bleiben
Die Richtlinie steuert die Erstellung, nicht automatisch den gesamten Lebenszyklus. Verteilung, Speicherung, Berechtigungen, Rotation, Ablauf, Sperrung und Monitoring bleiben eigene Aufgaben. Besonders kritisch sind Keys in Quellcode, Tickets, Chatverläufen, lokalen Konfigurationsdateien oder gemeinsam genutzten Secret-Sammlungen. Die neue Kontrolle ersetzt deshalb weder Secret Scanning noch einen zentralen Vault und kein belastbares Offboarding.
Auch die Wahl „nur Service Accounts“ kann Schattenidentitäten erzeugen, wenn Teams für jeden Test einen neuen Account anlegen oder Ownership unklar bleibt. Umgekehrt kann die vollständige Sperre neue Umgehungswege fördern, wenn Entwickler keinen funktionsfähigen Bereitstellungsprozess erhalten. Governance wirkt nur, wenn der erlaubte Weg schneller und verständlicher ist als der inoffizielle.
Betrieb, Kosten und Nachweise
Für den laufenden Betrieb braucht jeder Schlüssel oder Service Account mindestens einen fachlichen Owner, einen technischen Zweck, ein Projekt, eine Umgebung und einen überprüfbaren Lebenszyklus. Kostenberichte sollten nach Projekt und Identität auswertbar sein, damit ungewöhnliche Nutzung nicht in einer Gesamtsumme verschwindet. Bei Störungen muss klar sein, wer rotieren darf und welche Systeme anschließend getestet werden müssen.
Der Rollout gilt erst als abgeschlossen, wenn drei Nachweise vorliegen: Die neue Organisationsregel ist aktiv, Projektregeln widersprechen ihr nicht und der Altbestand wurde bewertet. Eine reine Screenshot-Dokumentation der Policy genügt nicht, solange bestehende Keys außerhalb des Zielmodells weiterlaufen. Sinnvolle Kennzahlen sind Anteil eindeutig zugeordneter Keys, Zahl personengebundener Produktionsschlüssel, Alter offener Ausnahmen und Zeit bis zur Sperrung nach einem Sicherheitsereignis.
Fazit: Zukunftskontrolle und Altbestand gemeinsam lösen
Die neuen OpenAI-Kontrollen geben Administratoren ein klares Instrument für die Erstellung künftiger API-Schlüssel. Organisationen können Service-Account- oder nutzereigene Projektschlüssel erzwingen oder neue Keys komplett sperren; zentrale Vorgaben haben Vorrang. Der entscheidende Punkt liegt außerhalb dieser Policy: Bestehende Schlüssel bleiben unberührt. Unternehmen sollten deshalb die Regelaktivierung mit Inventur, Migration, Rotation und Monitoring verbinden. Erst dann wird aus einer Konfiguration ein belastbares Zugriffsmodell.