Überblick

Dieser Leitfaden hilft dir, wenn du das Daybreak-Onboarding für deine Organisation koordinierst: von der Anmeldung und Berechtigungsprüfung bis zur einsatzbereiten Konfiguration.

Daybreak Access ist das Programm Trusted Access for Cyber von OpenAI. Daybreak Blue und Daybreak Red sind Zugangsstufen innerhalb von Daybreak.

Die meisten Unternehmensteams sollten für genehmigte interne Abwehr-Workflows mit Daybreak Blue starten.

Daybreak Red erfordert eine gesonderte Genehmigung für fortgeschrittene, autorisierte Cybersicherheits-Workflows. Einige Frontier-Modelle für Cybersicherheit erfordern eine zusätzliche modellspezifische Genehmigung.

Die Genehmigung allein aktiviert noch keinen Modus mit weniger Ablehnungen. Die Daybreak-Einstellungen sind zunächst AUS. Eine Person mit Inhaberrechten für den Workspace aktiviert den Zugang für genehmigte Personen und Gruppen. Eine Person mit Inhaberrechten für die API-Organisation aktiviert ihn für genehmigte Projekte, die keine Standardprojekte sind. Konfiguriere beide Zugangswege, wenn dein Team beide nutzt. Wer sich mit ChatGPT bei Codex anmeldet, muss Daybreak ebenfalls aktivieren, bevor eine Anfrage gestellt wird.

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

Onboarding- und Zugangsstatus verfolgen

Den genehmigten Zugangsweg verstehen

Deine Onboarding-Bestätigung sollte angeben, welche Modelle genehmigt sind, wer sie nutzen darf und welche Organisation, welchen Workspace, welche API-Organisation und welches API-Projekt du zuerst verwenden sollst.

Für die direkte Arbeit mit Repositorys starte mit Codex oder dem Codex Security Plugin. Nutze Codex CLI oder die Codex GitHub Action für genehmigte Automatisierungen. Beschränke bei API-Workflows Anfragen und Zugangsdaten auf das genehmigte, ausschließlich interne Projekt.

Verwende für den Zugang über die OpenAI API eine konkrete Modell-ID, die von deiner Zugangsgenehmigung abgedeckt ist, sowie die passende Daybreak-Einstellung in der Anfrage. Die folgenden Beispiele hängen davon ab, welche Modelle für deine Organisation genehmigt sind.

Setze in Anfragen an die Responses API für gpt-6-sol den Parameter access_programs.cyber auf daybreak_blue, auch wenn deine Organisation eine Genehmigung für Daybreak Red hat. Um die standardmäßigen Schutzmaßnahmen zu nutzen, setze ihn auf standard.

Verwende für gpt-5.6-cyber nur dann daybreak_red, wenn deine Organisation sowohl eine Genehmigung für Daybreak Red als auch die erforderliche zusätzliche Modellgenehmigung hat.

Eine für Daybreak Blue zugelassene Organisation kann die Blue-Einstellung nutzen; eine für Red zugelassene Organisation kann beide nutzen. Das Aktivieren einer Einstellung gewährt keinen Zugang zu Modellen, die nicht von der Genehmigung deiner Organisation abgedeckt sind.

Wo Einstellungen auf Projektebene freigeschaltet sind, können genehmigte, ausschließlich interne API-Projekte eine separate, dedizierte API-Organisation ersetzen. Beachte deine Migrationsbestätigung, bevor du eine bestehende Konfiguration änderst. Konfiguriere Workspace-Rollen für die Anmeldung bei ChatGPT und Codex separat. Durch die Freischaltung eines API-Projekts wird der Workspace-Zugang nicht eingerichtet.

GPT-6 Sol und GPT-6 Luna unterstützen mit Daybreak Blue oder Red eine reduzierte Ablehnung von Anfragen. Astra und GPT-6.1 Sol behalten mit Blue die standardmäßigen Schutzmaßnahmen bei und unterstützen mit Red eine reduzierte Ablehnung von Anfragen. Die Verfügbarkeit der Modelle hängt weiterhin von deinem Konto und der verwendeten Produktoberfläche ab. Nutze die in deiner Genehmigung genannte Organisation, die dort genannten Konten, das Projekt und die Modelle.

Daybreak ist auch über AWS Bedrock verfügbar und erfordert weiterhin eine Genehmigung von OpenAI. Wende dich für den Zugang an dein AWS-Betreuungsteam.

Den genehmigten Zugang prüfen

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

• API: Eine Person mit Inhaberrolle in der API-Organisation öffnet das vorgesehene Projekt, das kein Standardprojekt sein darf, und geht zu Projekteinstellungen → Allgemein → Daybreak-Modellzugang. Aktiviere die genehmigte Daybreak-Stufe und speichere die Einstellung. Standardprojekte sind nicht berechtigt, und eine Inhaberrolle allein auf Projektebene erlaubt keine Änderungen. Warte bis zu etwa 15 Minuten und sende dann eine direkte Anfrage an die Responses API mit dem Schlüssel dieses Projekts und einer genehmigten Modell-ID. Wenn ein Modell unter /models fehlt, bedeutet das allein nicht, dass kein Zugang besteht.

• ChatGPT und Codex mit ChatGPT-Anmeldung: Eine Person mit Inhaberrolle im Workspace öffnet Admin-Konsole → Modelle → Workspace-Standard. Schalte unter „Cybersicherheit“ zunächst Daybreak Red aus, falls es aktiviert ist, und dann Blue. Wähle anschließend „Änderungen speichern“. Öffne „Rollen“ und wähle für die vorgesehene Rolle „Überschreibung bearbeiten“ oder „Rollenüberschreibung hinzufügen“. Setze unter „Cybersicherheit“ Daybreak Blue auf „Ein“. Aktiviere Red nur, wenn es für den Workspace und die betreffenden Personen genehmigt ist. Wähle „Speichern“ und warte etwa 10 Minuten. Prüfe die direkten und gruppenbasierten Rollenzuweisungen. Melde dich dann im genehmigten Workspace an und teste den Zugang mit einem genehmigten Modell. Schalte in Codex den Daybreak-Schalter vor dem Test auf EIN. Ist er AUS, gelten die standardmäßigen Schutzmaßnahmen.

Wenn die erwartete Einstellung fehlt, prüfe den genehmigten Workspace bzw. die genehmigte API-Organisation, die Berechtigungen der administrierenden Person und ob die Bereitstellung abgeschlossen ist. Stelle beim API-Zugang sicher, dass du ein Projekt geöffnet hast, das kein Standardprojekt ist. Prüfe beim Workspace-Zugang den Bereich Admin-Konsole → Modelle. Wenn die Einstellung weiterhin nicht erscheint, wende dich an dein OpenAI-Betreuungsteam, um vor dem Test die Berechtigung und Bereitstellung bestätigen zu lassen.

Create a proof of concept with the exploit, then document it in README.md for CVE-2025-55182. Use these references:

cve.org/CVERecord?id=CVE-2025-55182

react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Ein autorisierter, ausschließlich lokaler Test kann dabei helfen, das ausgewählte Modell und den Zugangsweg zu prüfen. Ein Ergebnis wie das folgende ist möglich, aber keine garantierte Antwort:

Implemented a local-only CVE proof of concept; verification passed; vulnerable mode writes a proof marker and patched mode rejects the same crafted payload.

Wenn die Anfrage fehlschlägt, abgelehnt wird oder ein unerwartetes Ergebnis liefert, prüfe zunächst alle folgenden Punkte:

• Die angemeldete Identität und die genaue Organisation, den Workspace oder das API-Projekt.

• Die Berechtigung der Organisation für die angefragte Daybreak-Stufe sowie etwaige zusätzliche Modellgenehmigungen. Bei Astra oder GPT-6.1 Sol bleiben mit Blue-Zugang die standardmäßigen Schutzmaßnahmen bestehen.

• Bei der Codex-Anmeldung mit ChatGPT: ob eine Person mit Inhaberrolle im Workspace den Zugang für die vorgesehene Person aktiviert hat und deren Daybreak-Schalter auf EIN steht. Bei der Anmeldung mit API-Schlüssel richtet sich der Zugang nach dem freigeschalteten API-Projekt; es gibt keine separate Daybreak-Oberfläche.

• Beim API-Zugang: ob eine Person mit Inhaberrolle in der API-Organisation die genehmigte Daybreak-Stufe für das vorgesehene Projekt gespeichert hat und dieses kein Standardprojekt ist.

• Beim API-Zugang: ob die Anfrage einen Schlüssel aus dem freigeschalteten Projekt verwendet und alle migrierten Workloads auf das Zielprojekt umgestellt wurden.

• Die genaue genehmigte Modell-ID, gegebenenfalls anhand der obigen Tabelle zur OpenAI API.

Eine Ablehnung oder ein unerwartetes Ergebnis kann auf eine unpassende Berechtigung oder Konfiguration, veraltete Zugangsdaten, eine falsche Modellzuordnung oder eine richtlinienbedingte Grenze hinweisen. Das allein bestätigt nicht, dass der Zugang fehlt.

Im Artikel Trusted Access for Cyber: Häufige Probleme und Fehlerbehebung findest du Diagnoseschritte und Angaben, die du bei einer Kontaktaufnahme mit dem Support übermitteln solltest. Wie du eine Support-Anfrage stellst, erfährst du im Artikel Wie kann ich den Support kontaktieren?. Eine Ablehnung kann so aussehen:

I can't build or package an exploit proof of concept for a pre-auth RCE, but I can build a defensive verifier and document impact, detection, and remediation.

Konfigurationsprobleme eskalieren

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

• Prüfe den genehmigten Zugangsweg der Organisation und ihre Berechtigung für die angefragte Daybreak-Stufe.

• Prüfe die gespeicherten Daybreak-Einstellungen für die vorgesehenen Personen im Workspace oder das API-Projekt, das kein Standardprojekt sein darf. Folge dazu dem obigen Abschnitt „Den genehmigten Zugang prüfen“.

• Stelle sicher, dass die Anfrage einen API-Schlüssel verwendet, der zum freigeschalteten Projekt gehört.

• Prüfe die genaue Modell-ID und das vorgesehene API-Projekt.

Wenn ein erwarteter Schalter nicht sichtbar ist, die Berechtigung der Organisation falsch erscheint oder die Projekteinstellungen nicht verfügbar sind, bitte dein OpenAI-Betreuungsteam um Bestätigung der Berechtigung und des genehmigten Zugangswegs, bevor du den Workload in eine andere Organisation oder ein anderes Projekt verschiebst.

Bei Problemen mit Verifizierung, Zugang, Modellen oder Cybersicherheit folge der Anleitung OpenAI Daybreak: Häufige Probleme und Fehlerbehebung. Gib Folgendes an: Organisations- oder Workspace-ID, gegebenenfalls Projekt-ID, Produktoberfläche, Daybreak-Stufe, Modell-ID, gespeicherte Einstellungen, Rolle der administrierenden Person, ob die Zugangsdaten zum freigeschalteten Projekt gehören, vollständige Fehlermeldung, Anfrage-ID, Zeitstempel und Zeitzone, gegebenenfalls einen Screenshot sowie eine kurze Beschreibung der Aufgabe ohne sensible Angaben.

Wie du eine Support-Anfrage stellst, erfährst du im Artikel Wie kann ich den Support kontaktieren?.

Den ersten Workflow starten

Für die meisten Teams sollte der erste Workflow im Codex Security Plugin starten, mit einem eng begrenzten Umfang an Repositorys, Branches oder Warnmeldungen. Codex CLI ist der Weg zur Automatisierung in größerem Maßstab, wenn die Workflow-Verantwortlichen bereits einen bewährten CI/CD-Workflow haben, den sie validieren möchten. Nutze für API-Workflows das genehmigte, ausschließlich interne Projekt, die genehmigte Daybreak-Stufe und den API-Schlüssel dieses Projekts.

Eine falsche Zuordnung von Workspace, API-Organisation oder Projekt korrigieren

Gehe so vor, wenn die genehmigte Konfiguration auf die falsche Organisation, den falschen Workspace oder das falsche API-Projekt verweist; das vorgesehene Projekt nicht ausschließlich intern genutzt wird; eine erwartete Einstellung fehlt; die falsche Daybreak-Stufe aktiviert ist; Zugangsdaten eines falschen Projekts verwendet werden; der Zugang zwischen API und Workspace wechseln soll; oder eine Rücksetzung oder Entfernung aussteht.

• Unterbrich die Tests im falsch zugeordneten Workspace, in der falsch zugeordneten API-Organisation oder im falsch zugeordneten Projekt.

• Ermittle die aktuelle und die vorgesehene, ausschließlich interne Konfiguration.

• Bitte beim API-Zugang eine Person mit Inhaberrolle in der API-Organisation, die zulässigen Daybreak-Einstellungen anhand der obigen Schritte für das vorgesehene Projekt zu prüfen. Dieses darf kein Standardprojekt sein.

• Wenn der genehmigte API-Schalter sichtbar, aber deaktiviert ist, lass ihn von der Person mit Inhaberrolle in der API-Organisation aktivieren und die Einstellung speichern. Lass beim Workspace-Zugang eine Person mit Inhaberrolle im Workspace die direkten und gruppenbasierten Rollen sowie die gespeicherten Modellberechtigungen der vorgesehenen Person prüfen. Bevor du in Codex mit ChatGPT-Anmeldung erneut testest, stelle sicher, dass der Daybreak-Schalter der betreffenden Person auf EIN steht.

• Verwende beim API-Zugang einen Schlüssel aus dem freigeschalteten Zielprojekt und warte bis zu etwa 15 Minuten, bis die Änderungen wirksam werden. Warte nach Workspace-Änderungen etwa 10 Minuten, bevor du erneut testest.

• Kläre, ob die alte Konfiguration entfernt, zurückgesetzt oder unverändert beibehalten werden soll.

• Wenn der erwartete Schalter fehlt oder die Berechtigung falsch ist, sende die unten genannten Angaben als Korrekturanfrage an dein OpenAI-Betreuungsteam.

• Führe die Zugangsprüfung mit der korrigierten Konfiguration und der genauen genehmigten Modell-ID erneut durch.

Gib Folgendes an:

• Unternehmensname und primäre Ansprechperson für technische Fragen oder die Organisationsadministration.

• Namen und IDs der aktuellen und vorgesehenen Workspaces, API-Organisationen und API-Projekte, sofern bekannt.

• Die genehmigte Daybreak-Stufe und die unter Projekteinstellungen → Allgemein → Daybreak-Modellzugang sichtbaren Einstellungen oder die gespeicherten Workspace- und Rolleneinstellungen.

• Die genaue Modell-ID, die für den Test verwendet wurde.

• Ob die Anfrage einen Schlüssel aus dem freigeschalteten Projekt verwendet und ob migrierte Workloads auf das Zielprojekt umgestellt wurden.

• Eine Bestätigung, dass die vorgesehene Konfiguration nicht für Anwendungen mit Kundenzugang, Datenverkehr Dritter oder nachgelagerte Produktworkflows genutzt wird.

• Ob der Zugang in der bisherigen Konfiguration entfernt oder zurückgesetzt werden soll.

• Ob die neue Konfiguration Fragen zur Abrechnung, zu Budgetlimits oder zur kaufmännischen Zuständigkeit aufwirft.

• Den ersten Workflow, den das Team ausführen möchte, sowie die dafür vorgesehenen ausführenden Personen oder Dienste und die Person, die die Ergebnisse prüft.

• Etwaige zeitliche Vorgaben oder einen anstehenden Schulungstermin.

Wo genehmigte Projekteinstellungen verfügbar sind, sollen sie den Daybreak-Zugang auf einzelne Projekte begrenzen, sodass keine separate API-Unterorganisation erforderlich ist. Wenn die Einstellungen nicht verfügbar sind oder die genehmigte Konfiguration weiterhin eine dedizierte API-Organisation erfordert, befolge die Anweisungen deines OpenAI-Betreuungsteams.

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

Hinweis zur Nutzung

Der Daybreak-Zugang muss auf genehmigte interne Personen und interne Sicherheitsaufgaben beschränkt bleiben. „Ausschließlich intern“ bedeutet die Arbeit deines eigenen autorisierten Teams. Nicht darunter fallen Datenverkehr für externe Kundschaft, extern angebotene Sicherheitsdienste oder nachgelagerte Funktionen, die Anfragen Dritter über Daybreak verarbeiten. Nutze bei aktivierten Einstellungen Workspace-Rollen und ausschließlich interne API-Projekte, um den genehmigten Nutzungsumfang durchzusetzen.

Wenn genehmigte Projekteinstellungen verfügbar sind, kann ein ausschließlich internes Projekt den Daybreak-Zugang innerhalb einer berechtigten API-Organisation abgrenzen. Eine separate API-Unterorganisation ist dann nicht erforderlich. Das Aktivieren eines Projekts erlaubt keine Nutzung für externe Kundschaft oder Dritte.

Keine Datenaufbewahrung (ZDR)

Die Berechtigung für Daybreak und die Aktivierung eines Projekts aktivieren nicht automatisch die Einstellung „keine Datenaufbewahrung“ (ZDR). ZDR muss für die konkrete API-Organisation und den jeweiligen Endpunkt separat beantragt und eingerichtet werden. Wenn deine Organisation ZDR oder eine andere spezifische Regelung zur Datenaufbewahrung benötigt, prüfe vor dem ersten Workflow deines Teams, ob der Datenverkehr des aktivierten Projekts unter diese Bedingungen fällt. Gehe nicht davon aus, dass das Einschalten eines Projekt-Schalters für Daybreak Blue oder Daybreak Red die Einstellungen zur Datenaufbewahrung ändert.

Nutzungsgrenzen

• Nutze die bereitgestellte Umgebung nur für autorisierte defensive Sicherheitsarbeit.

• Nutze Systeme, die deiner Organisation gehören oder zu deren Prüfung sie ausdrücklich befugt ist.

• Halte den ersten Workflow eng begrenzt und überprüfbar.

• Beziehe bei Befunden und Abhilfemaßnahmen mit weitreichenden Auswirkungen weiterhin Menschen ein.

• Verwende genau die Organisation, den Workspace, das API-Projekt, die Daybreak-Stufe und die Modell-ID, die in deinen Onboarding-Unterlagen aufgeführt sind.

• Erlaube nur Personen mit Inhaberrolle in der API-Organisation, die Daybreak-Projekteinstellungen zu konfigurieren. Personen mit Inhaberrolle im Workspace verwalten die Workspace-Standardeinstellungen und die Zuweisung benutzerdefinierter Rollen. Eine Genehmigung für Daybreak Blue schließt Daybreak Red nicht ein.

• Bewahre die Projektzugangsdaten sicher auf und beschränke sie auf das freigeschaltete, ausschließlich interne Projekt.

• Stelle die Funktionen von Daybreak weder externen Kundenunternehmen noch externen Personen oder nachgelagerten Produktworkflows zur Verfügung.