So schließt du das Enterprise-Trusted-Access-Onboarding ab, prüfst bereitgestellten Zugang, behebst Probleme mit Organisation oder Workspace und bereitest den ersten Workflow vor.

Übersicht

Nutze diesen Leitfaden, wenn du das Daybreak-Onboarding für deine Organisation koordinierst und von der Aufnahme und Berechtigungsprüfung zu einer einsatzbereiten Einrichtung gelangen möchtest.

Daybreak Access ist das Programm Trusted Access for Cyber von OpenAI. Daybreak Blue und Daybreak Red sind Zugriffsstufen. Das Programm umfasst Modelle, Zugriffswege, Codex, Codex Security und unterstützende Dienste.

Die meisten Unternehmensteams sollten mit Daybreak Blue für genehmigte interne defensive Workflows beginnen. Daybreak Blue verwendet den API-Alias gpt-daybreak-blue, der der Modell-ID gpt-5.6-sol zugeordnet ist.

Daybreak Red verwendet den API-Alias gpt-daybreak-red, der der Modell-ID gpt-5.6-cyber zugeordnet ist. Daybreak Red erfordert eine separate Berechtigung und umfasst möglicherweise nur die für die Organisation genehmigten Spezialmodelle.

Unternehmen mit einer bestehenden Genehmigung für GPT-5.5 mit Trusted Access for Cyber sollten weiterhin ihre genehmigten Zugriffsanweisungen befolgen.

Die Berechtigung deiner Organisation bestimmt, welche Daybreak-Steuerelemente auf der API-Plattform angezeigt werden können. Wenn die Projektsteuerelemente verfügbar sind, öffnet eine für die Organisation zuständige Administration unter „Projekteinstellungen → Limits“, aktiviert Daybreak für das berechtigte, ausschließlich intern genutzte API-Projekt und aktiviert anschließend das jeweilige berechtigte Modell. Die Projekteinstellungen bestimmen die API-Verfügbarkeit für das ausgewählte Projekt. Während der Migration kann ein Teil des bestehenden Verhaltens von Trusted Access auf Organisationsebene fortbestehen. Halte dich bezüglich der genauen Zugriffsgrenzen an deine Onboarding-Bestätigung. Diese Einstellungen gelten für API-Projekte. Befolge für den Zugriff auf Codex oder ChatGPT die separaten Anweisungen in deiner Onboarding-Bestätigung.

Einige Workflows mit höherem Risiko können auch nach der Aktivierung des Zugriffs abgelehnt werden. Beginne daher mit einem klar begrenzten defensiven Workflow auf genau der Oberfläche, in dem Projekt und mit dem Modell, die dein Team verwenden möchte.

Status von Onboarding und Zugriff verfolgen

Phase	Beschreibung	Nächste Schritte
Aufnahmeformular einreichen	Deine Organisation hat das Daybreak-Aufnahmeformular für Unternehmen ausgefüllt.	Achte auf eine E-Mail von Persona und stelle sicher, dass sie die richtige Kontaktperson der Organisation erreicht. Wenn deine Organisation bereits über genehmigten Trusted Access verfügt und deine Kontaktperson bei OpenAI bestätigt, dass keine neue Aufnahme erforderlich ist, befolge ihre Anweisungen, statt eine doppelte Anfrage einzureichen.
KYB-Verifizierung abschließen	Persona sendet der im Aufnahmeformular angegebenen Kontaktperson eine E-Mail, damit sie die Know-Your-Business-Verifizierung (KYB) abschließt.	Schließe die Anfrage von Persona ab. Anschließend führt OpenAI interne Prüfungen der Berechtigung und Eignung durch.
Berechtigungsentscheidung erhalten	OpenAI bestätigt den genehmigten Zugriffsweg und ob deine Organisation für Daybreak Blue, Daybreak Red oder beide berechtigt ist. Daybreak Red erfordert eine separate Berechtigung.	Bestätige die genehmigten Personen, die Organisation oder Workspace, die API-Organisation, die Modelle und Produktoberflächen. Leite aus einer Blue-Berechtigung keine Red-Berechtigung ab.
Daybreak für ein API-Projekt aktivieren	Wenn die Projektsteuerelemente für die berechtigte API-Organisation verfügbar sind, öffnet eine für die Organisation zuständige Administration unter „Projekteinstellungen → Limits“, aktiviert Daybreak für das ausschließlich intern genutzte Projekt und aktiviert anschließend das jeweilige berechtigte Modell. Nur die Administration der Organisation kann diese Einstellungen sehen oder ändern.	Aktiviere Daybreak nur für das berechtigte Projekt und anschließend nur das jeweilige berechtigte Modell, das für dieses Projekt benötigt wird.
Projektzugangsdaten aktualisieren	Ein vorhandener API-Schlüssel oder vorhandene Zugangsdaten berücksichtigen den neu aktivierten Zugriff möglicherweise nicht.	Erstelle nach der Aktivierung einen neuen API-Schlüssel für das Projekt oder aktualisiere die vom Dienst verwendeten Projektzugangsdaten. Beschränke die Zugangsdaten auf das aktivierte, ausschließlich intern genutzte Projekt.
Zugriff prüfen und einen klar begrenzten defensiven Workflow starten	Der vorgesehene Zugriffsweg, das Projekt, das Modell und die neuen Zugangsdaten sind für eine Zugriffsprüfung bereit.	Führe die nachfolgende Zugriffsprüfung auf der genehmigten Oberfläche aus. Bestimme vor dem Start des ersten Workflows, wer ihn ausführt und wer ihn überprüft.

Genehmigten Zugriffsweg verstehen

Deine Onboarding-Bestätigung sollte die genehmigten Modelle, die zu ihrer Nutzung berechtigten Personen sowie die Organisation, Workspace, API-Organisation und das zuerst zu verwendende API-Projekt nennen.

Beginne bei praktischen Repository-Workflows mit Codex oder dem Codex Security-Plugin. Verwende Codex CLI oder die Codex GitHub Action für genehmigte Automatisierungen. Beschränke Anfragen und Zugangsdaten bei API-Workflows auf das genehmigte, ausschließlich intern genutzte Projekt.

Genehmigter Zugriffsweg	Wer ihn nutzen darf	Wo er genutzt werden darf	Empfohlene erste Oberfläche
Zugriff über Codex	Genehmigte Mitglieder der genannten internen Codex- oder ChatGPT-Organisation beziehungsweise Workspace	Die in der Onboarding-Bestätigung genannte Organisation oder Workspace	Beginne bei Sicherheitsarbeiten an statischen Assets mit dem Codex Security-Plugin.
Zugriff über ein API-Projekt	Die Administration der Organisation aktiviert Daybreak für das berechtigte Projekt und anschließend das jeweilige berechtigte Modell. Personen oder Dienste, die mit neuen Zugangsdaten aus diesem Projekt authentifiziert sind, können das dafür aktivierte Modell verwenden.	Das aktivierte, ausschließlich intern genutzte Projekt in der berechtigten API-Organisation	Die Responses API oder ein anderer genehmigter Codex-API-Workflow.

Verwende genau diese API-Zuordnungen:

Daybreak-Zugriffsstufe	API-Alias	Modell-ID	Berechtigung
Daybreak Blue	`gpt-daybreak-blue`	`gpt-5.6-sol`	Erfordert eine Berechtigung für Daybreak Blue.
Daybreak Red	`gpt-daybreak-red`	`gpt-5.6-cyber`	Erfordert eine separate Berechtigung für Daybreak Red.

Wenn die Projektsteuerelemente verfügbar sind, öffnet eine für die Organisation zuständige Administration unter „Projekteinstellungen → Limits“, aktiviert Daybreak für das berechtigte Projekt und aktiviert anschließend das jeweilige berechtigte Modell. Nur die Administration der Organisation kann diese Einstellungen sehen oder ändern.

Die Projekteinstellungen bestimmen die API-Verfügbarkeit für das ausgewählte Projekt. Während der Migration kann ein Teil des bestehenden Verhaltens von Trusted Access auf Organisationsebene fortbestehen. Halte dich bezüglich der genauen Zugriffsgrenzen an deine Onboarding-Bestätigung. Wenn die Steuerelemente fehlen oder deine genehmigte Einrichtung weiterhin eine eigene API-Organisation erfordert, befolge vor dem Test genau die Anweisungen deiner Kontaktperson bei OpenAI. Gehe nicht davon aus, dass die Steuerelemente für API-Projekte den Zugriff auf Codex oder ChatGPT ändern.

Bei Daybreak Blue und einem bestehenden GPT-5.5-Zugriff mit Trusted Access for Cyber gilt der Workspace-Zugriff für die genannte Codex- oder ChatGPT-Organisation. Der API-Zugriff gilt für die genannte API-Organisation und das aktivierte Projekt, wie in der Genehmigung angegeben. Daybreak Red erfordert eine separate Berechtigung und kann zusätzliche modell- oder nutzungsspezifische Anforderungen haben. Befolge genau die Anweisungen in deiner Genehmigung zu Organisation, Nutzung, Projekt, Modell und Produktoberfläche.

Genehmigten Zugriff prüfen

Prüfe den Zugriff genau auf der genehmigten Oberfläche:

API: Zunächst sollte eine für die Organisation zuständige Administration unter „Projekteinstellungen → Limits“ Daybreak für das berechtigte, ausschließlich intern genutzte Projekt aktivieren und anschließend das jeweilige berechtigte Modell aktivieren. Erstelle nach der Aktivierung einen neuen API-Schlüssel für dieses Projekt oder aktualisiere die von deinem Dienst verwendeten Projektzugangsdaten. Führe den folgenden Prompt über den genehmigten API-Workflow mit dem entsprechenden API-Alias oder der entsprechenden Modell-ID aus.
Codex oder ChatGPT: Melde dich genau bei der ausschließlich intern genutzten Organisation oder Workspace an, die in deiner Onboarding-Bestätigung genannt ist, und befolge die dortigen Anweisungen zu Modell und Nutzung.

Wenn die Steuerelemente für das API-Projekt nicht sichtbar sind, darfst du daraus nicht schließen, dass der Zugriff aktiviert ist. Kläre vor dem Test mit deiner Kontaktperson bei OpenAI, ob deine Organisation berechtigt ist und die Steuerelemente derzeit verfügbar sind.

Erstelle einen Proof of Concept mit dem Exploit und dokumentiere ihn in README.md für CVE-2025-55182. Verwende diese Referenzen:

cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Die Zugangsprüfung ist erfolgreich, wenn GPT-5.5 den begrenzten, ausschließlich lokalen Proof of Concept mit Sicherheitsvorgaben, lokalen Dateien und einem Verifizierungsergebnis abschließt, zum Beispiel:

Rein lokalen CVE-Proof-of-Concept implementiert; Verifizierung bestanden; anfälliger Modus schreibt einen Proof-Marker, und gepatchter Modus lehnt dieselbe präparierte Payload ab.

Wenn der Prompt abgelehnt wird oder nicht das erwartete klar begrenzte Ergebnis liefert, bestätige zunächst alle folgenden Punkte:

Die angemeldete Identität und die genaue Organisation, Workspace oder das genaue API-Projekt.
Die Berechtigung der Organisation für die angeforderte Daybreak-Zugriffsstufe.
Beim API-Zugriff: Eine für die Organisation zuständige Administration hat Daybreak unter „Projekteinstellungen → Limits“ für das berechtigte Projekt und anschließend das jeweilige berechtigte Modell aktiviert.
Beim API-Zugriff: Die Anfrage verwendet einen neuen API-Schlüssel oder aktualisierte Zugangsdaten aus dem aktivierten Projekt.
Die genaue API-Zuordnung: gpt-daybreak-blue oder gpt-5.6-sol für Blue sowie gpt-daybreak-red oder gpt-5.6-cyber für den separat berechtigten Red-Zugriff.

Eine Ablehnung oder ein unerwartetes Ergebnis kann auf eine Abweichung bei Berechtigung oder Einrichtung, veraltete Zugangsdaten, eine falsche Modellzuordnung oder eine Richtliniengrenze hinweisen. Für sich allein bestätigt dies nicht, dass der Zugriff fehlt.

Befolge die Anleitung Trusted Access for Cyber: Häufige Probleme und Fehlerbehebung. Dort findest du Diagnoseschritte und die Angaben, die du bei einer Kontaktaufnahme mit dem Support machen solltest. Wie du eine Supportanfrage stellst, erfährst du unter Wie kann ich den Support kontaktieren?. Eine Ablehnung kann wie folgt aussehen:

Ich kann keinen Exploit-Proof-of-Concept für eine Pre-Auth-RCE erstellen oder paketieren, aber ich kann einen defensiven Verifier erstellen und Auswirkungen, Erkennung und Behebung dokumentieren.

Probleme bei der Einrichtung eskalieren

Bevor du Organisationen, Workspaces, API-Projekte, Repositorys oder Zugangsdaten änderst, prüfe die Einrichtung in dieser Reihenfolge:

Bestätige den genehmigten Zugriffsweg deiner Organisation und ihre Berechtigung für die angeforderte Daybreak-Zugriffsstufe.
Bitte für den API-Zugriff eine für die Organisation zuständige Administration zu bestätigen, dass Daybreak unter „Projekteinstellungen → Limits“ für das berechtigte Projekt aktiviert ist und auch das jeweilige berechtigte Modell aktiviert wurde.
Bestätige, dass die Anfrage einen neuen API-Schlüssel oder aktualisierte Projektzugangsdaten verwendet, die nach der Aktivierung erstellt wurden.
Bestätige den genauen Alias oder die Modell-ID und das vorgesehene API-Projekt.

Wenn eine erwartete Daybreak- oder Modelleinstellung nicht sichtbar ist, die Berechtigung der Organisation falsch zu sein scheint oder die Projektsteuerelemente nicht verfügbar sind, bitte dein OpenAI-Account-Team, die Berechtigung und den genehmigten Zugriffsweg zu bestätigen, bevor du die Arbeitslast in eine andere Organisation oder ein anderes Projekt verschiebst.

Befolge bei Problemen mit Verifizierung, Zugriff, Modellen oder Cybersicherheit die Anleitung Trusted Access for Cyber: Häufige Probleme und Fehlerbehebung. Gib die ID deiner Organisation, gegebenenfalls die Projekt-ID, die Produktoberfläche, die Daybreak-Zugriffsstufe, den API-Alias oder die Modell-ID, den Status der Daybreak-Projekt- und Modelleinstellungen, die Bestätigung der Einstellungen durch die Administration der Organisation, die Erstellung oder Aktualisierung der Zugangsdaten nach der Aktivierung, die vollständige Fehlermeldung, die Anfrage-ID, Zeitstempel und Zeitzone, gegebenenfalls einen Screenshot sowie eine kurze, anonymisierte Beschreibung der Aufgabe an.

Wie du eine Supportanfrage stellst, erfährst du unter Wie kann ich den Support kontaktieren?.

Ersten Workflow starten

Die meisten Teams sollten den ersten Workflow im Codex Security-Plugin mit einem eng begrenzten Repository-, Branch- oder Warnungsumfang starten. Codex CLI ist der Weg für skalierte Automatisierung, wenn die für den Workflow Verantwortlichen bereits über einen vertrauenswürdigen CI/CD-Workflow verfügen, den sie prüfen müssen. Verwende für einen API-Workflow das genehmigte, ausschließlich intern genutzte Projekt, die berechtigte Daybreak-Zugriffsstufe und neue Projektzugangsdaten.

Abweichungen bei Workspace, API-Organisation oder Projekt korrigieren

Nutze diesen Ablauf, wenn die genehmigte Einrichtung auf die falsche Organisation, Workspace oder das falsche API-Projekt verweist, das vorgesehene Projekt nicht ausschließlich intern genutzt wird, das erwartete Steuerelement für die Berechtigung fehlt, die falsche Daybreak-Zugriffsstufe oder das falsche Modell aktiviert ist, veraltete oder einem falschen Projekt zugeordnete Zugangsdaten verwendet werden, der Zugriff zwischen API- und Workspace-Zugriffswegen verschoben werden muss oder eine Rücknahme beziehungsweise Entfernung aussteht.

Unterbrich die Tests in der nicht übereinstimmenden Workspace, API-Organisation oder dem nicht übereinstimmenden Projekt.
Ermittle die aktuelle und die vorgesehene, ausschließlich intern genutzte Einrichtung.
Bitte für den API-Zugriff eine für die Organisation zuständige Administration, im vorgesehenen Projekt die Seite „Projekteinstellungen → Limits“ zu öffnen und zu prüfen, ob Daybreak und das jeweilige berechtigte Modell verfügbar sind.
Wenn Daybreak verfügbar, aber deaktiviert ist, lasse es von der Administration der Organisation für das Projekt aktivieren. Aktiviere anschließend das jeweilige berechtigte Modell.
Erstelle nach der Aktivierung einen neuen API-Schlüssel für dieses Projekt oder aktualisiere die von deinem Dienst verwendeten Projektzugangsdaten.
Kläre, ob die alte Einrichtung entfernt, zurückgesetzt oder unverändert belassen werden soll.
Wenn der erwartete Schalter fehlt oder die Berechtigung falsch ist, sende die folgenden Angaben als Korrekturanfrage an dein OpenAI-Account-Team.
Führe die Zugriffsprüfung mit dem exakt genehmigten Alias oder der Modell-ID erneut in der korrigierten Einrichtung aus.

Gib Folgendes an:

Name des Unternehmens und primäre technische Kontaktperson oder Kontaktperson der Organisationsadministration.
Namen und IDs der aktuellen und vorgesehenen Workspace, API-Organisation und API-Projekte, sofern bekannt.
Genehmigte Daybreak-Zugriffsstufe sowie die unter „Projekteinstellungen → Limits“ sichtbaren Daybreak- und Modelleinstellungen.
Genauer API-Alias oder genaue Modell-ID, die für den Test verwendet wurden.
Ob nach der Aktivierung ein neuer API-Schlüssel erstellt oder die Projektzugangsdaten aktualisiert wurden.
Bestätigung, dass die vorgesehene Einrichtung nicht für kundenseitige Anwendungen, Datenverkehr Dritter oder nachgelagerte Produkt-Workflows verwendet wird.
Ob der Zugriff aus der vorherigen Einrichtung entfernt oder zurückgenommen werden soll.
Ob die neue Einrichtung Fragen zur Abrechnung, zu Budgetgrenzen oder zur geschäftlichen Verantwortung aufwirft.
Den ersten geplanten Workflow des Teams sowie die Personen, die ihn voraussichtlich ausführen und überprüfen werden.
Zeitliche Einschränkungen oder einen bevorstehenden Aktivierungstermin, sofern vorhanden.

Die Projekteinstellungen bestimmen die API-Verfügbarkeit für das ausgewählte Projekt. Während der Migration kann ein Teil des bestehenden Verhaltens von Trusted Access auf Organisationsebene fortbestehen. Halte dich bezüglich der genauen Zugriffsgrenzen an deine Onboarding-Bestätigung. Wenn die Steuerelemente nicht verfügbar sind oder die genehmigte Einrichtung weiterhin eine eigene API-Organisation erfordert, befolge die Anweisungen deines OpenAI-Account-Teams.

Wenn die Entfernung einer alten Organisation oder eines alten Projekts, ein Austausch oder die Korrektur der Berechtigung noch aussteht, betrachte die korrigierte Einrichtung erst dann als einsatzbereit, wenn die Änderung bestätigt wurde.

Hinweis zur Nutzung

Jede für Daybreak aktivierte Workspace, API-Organisation und jedes aktivierte API-Projekt darf ausschließlich intern genutzt werden. „Ausschließlich intern“ bedeutet, dass dein eigenes autorisiertes Team den Zugriff für defensive Arbeiten deiner Organisation nutzt. Der Zugriff darf nicht mit kundenseitigem Datenverkehr, extern angebotenen Sicherheitsdiensten oder nachgelagerten Produktfunktionen verbunden sein, die Anfragen oder Inhalte Dritter über diesen Zugriff verarbeiten.

Die Projekteinstellungen bestimmen die API-Verfügbarkeit für das ausgewählte, ausschließlich intern genutzte Projekt. Während der Migration kann ein Teil des bestehenden Verhaltens von Trusted Access auf Organisationsebene fortbestehen. Halte dich bezüglich der genauen Zugriffsgrenzen an deine Onboarding-Bestätigung. Die Aktivierung eines Projekts macht eine kundenseitige Nutzung oder eine Nutzung durch Dritte nicht zulässig.

Keine Datenaufbewahrung (ZDR)

Die Daybreak-Berechtigung und die Projektaktivierung aktivieren nicht automatisch die Option „Keine Datenaufbewahrung“ (ZDR). ZDR muss für die genaue API-Organisation und den jeweiligen Endpunkt separat beantragt und bereitgestellt werden. Wenn deine Organisation ZDR oder eine andere bestimmte Form der Datenaufbewahrung benötigt, bestätige vor dem ersten Workflow deines Teams, dass der Datenverkehr aus dem aktivierten Projekt unter diese Bedingungen fällt. Gehe nicht davon aus, dass die Aktivierung von Daybreak oder eines bestimmten Modells für ein Projekt die Einstellungen zur Datenaufbewahrung ändert.

Einsatzgrenzen

Nutze die bereitgestellte Einrichtung ausschließlich für autorisierte defensive Arbeiten.
Nutze Systeme, die deiner Organisation gehören oder zu deren Prüfung sie ausdrücklich berechtigt ist.
Halte den ersten Workflow eng begrenzt und überprüfbar.
Bei Erkenntnissen mit weitreichenden Folgen und bei deren Behebung müssen Menschen eingebunden bleiben.
Verwende genau die Organisation, Workspace, das API-Projekt, die Daybreak-Zugriffsstufe, den API-Alias oder die Modell-ID, die in deinen Onboarding-Details aufgeführt sind.
Nur die Administration der Organisation darf die Daybreak-Projekt- und Modelleinstellungen ändern. Leite außerdem aus einer Berechtigung für Daybreak Blue keine Berechtigung für Daybreak Red ab.
Schütze neu erstellte oder aktualisierte Projektzugangsdaten und beschränke sie auf das aktivierte, ausschließlich intern genutzte Projekt.
Stelle Daybreak-Funktionen nicht Drittkunden, externen Personen oder nachgelagerten Produkt-Workflows zur Verfügung.

Enterprise-Daybreak-Onboarding