Ü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.

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

Verwende für den Zugang über die OpenAI API einen genehmigten Daybreak-Alias oder eine genehmigte Modell-ID. Aliasse können im Laufe der Zeit auf neuere berechtigte Modelle verweisen. Die folgenden Beispiele sind keine festen Alias-Ziele. Diese Aliasse der OpenAI API sind auf Amazon Bedrock nicht verfügbar.

Eine für Daybreak Blue zugelassene Organisation kann die Blue-Einstellung nutzen. Eine für Red zugelassene Organisation kann beide Einstellungen nutzen. Das Aktivieren einer Einstellung gewährt keinen Zugang zu Modellen, die nicht für deine Organisation genehmigt sind.

Wenn Einstellungen auf Projektebene aktiviert sind, können genehmigte, ausschließlich interne API-Projekte eine separate, dedizierte API-Organisation ersetzen. Befolge die Hinweise in deiner Migrationsbestätigung, bevor du eine bestehende Konfiguration änderst. Konfiguriere die Workspace-Rollen für die Anmeldung bei ChatGPT und Codex separat. Das Aktivieren eines API-Projekts konfiguriert nicht den Workspace-Zugang.

GPT-6 Sol und GPT-6 Luna unterstützen mit Daybreak Blue oder Red einen Modus mit weniger Ablehnungen. Astra und GPT-6.1 Sol behalten mit Blue die standardmäßigen Schutzmaßnahmen bei und unterstützen mit Red einen Modus mit weniger Ablehnungen. Die Modellverfügbarkeit hängt weiterhin von deinem Konto und der Produktoberfläche ab. Nutze die in deiner Genehmigung angegebene Organisation, das Projekt und die Modelle mit den dort aufgeführten Personen.

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

Genehmigten Zugang prüfen

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

• API: Eine Person mit Inhaberrechten für die API-Organisation öffnet das vorgesehene Projekt, das kein Standardprojekt ist, und geht zu Projekteinstellungen → Allgemein → Daybreak-Modellzugang. Aktiviere die genehmigte Daybreak-Stufe und speichere die Einstellung. Standardprojekte sind nicht berechtigt. Inhaberrechte für das Projekt allein berechtigen nicht zu Änderungen. Warte bis zu etwa 15 Minuten. Sende dann eine direkte Anfrage an die Responses API mit dem Schlüssel dieses Projekts und einem genehmigten Alias oder einer genehmigten Modell-ID. Dass ein Modell unter /models fehlt, bedeutet allein noch nicht, dass kein Zugang verfügbar ist.

• ChatGPT und Codex mit ChatGPT-Anmeldung: Eine Person mit Inhaberrechten für den Workspace öffnet Admin-Konsole → Modelle → Workspace-Standard. Schalte unter „Cybersicherheit“ Daybreak Red aus, falls es aktiviert ist. Schalte dann Blue aus und wähle „Ä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 diese Personen genehmigt ist. Wähle „Speichern“ und warte etwa 10 Minuten. Prüfe direkte und gruppenbasierte Rollenzuweisungen. Melde dich dann im genehmigten Workspace an und teste mit einem genehmigten Modell. Stelle den Daybreak-Schalter in Codex vor dem Test auf EIN. Steht er auf AUS, gelten die standardmäßigen Schutzmaßnahmen.

Wenn die erwartete Einstellung fehlt, prüfe den genehmigten Workspace oder die API-Organisation, die Admin-Berechtigungen und ob die Bereitstellung abgeschlossen ist. Prüfe beim API-Zugang, ob du ein Projekt geöffnet hast, das kein Standardprojekt ist. Prüfe beim Workspace-Zugang die Admin-Konsole → Modelle. Wenn die Einstellung weiterhin nicht erscheint, lass dir vor dem Test die Berechtigung und Bereitstellung von deinem OpenAI-Account-Team bestätigen.

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 helfen, das ausgewählte Modell und den Zugangsweg zu prüfen. Ein Ergebnis wie das folgende ist möglich, aber nicht garantiert:

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 zuerst alle folgenden Punkte:

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

• Die Berechtigung der Organisation für die angeforderte Daybreak-Stufe und 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 Inhaberrechten für den 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 aktivierten API-Projekt. Es gibt keine separate Daybreak-Oberfläche.

• Beim API-Zugang: ob eine Person mit Inhaberrechten für die 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 des aktivierten Projekts verwendet und ob alle migrierten Workloads auf das Zielprojekt umgestellt wurden.

• Den genauen genehmigten API-Alias oder die 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 Hinweise dazu, welche Angaben du bei einer Support-Anfrage machen 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

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

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

• Prüfe die gespeicherten Daybreak-Einstellungen für die vorgesehenen Personen im Workspace oder das API-Projekt, das kein Standardprojekt ist. Befolge dazu den obigen Abschnitt „Genehmigten Zugang prüfen“.

• Prüfe, ob die Anfrage einen API-Schlüssel des aktivierten Projekts verwendet.

• Prüfe den genauen Alias oder die 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, lass dir die Berechtigung und den genehmigten Zugangsweg von deinem OpenAI-Account-Team bestätigen, bevor du den Workload in eine andere Organisation oder ein anderes Projekt verschiebst.

Befolge bei Problemen mit der Verifizierung, dem Zugang, dem Modell oder der Cybersicherheit die Hinweise im Artikel OpenAI Daybreak: Häufige Probleme und Fehlerbehebung. Gib Folgendes an: Organisations- oder Workspace-ID, gegebenenfalls Projekt-ID, Produktoberfläche, Daybreak-Stufe, API-Alias oder Modell-ID, gespeicherte Einstellungen, Rolle der administrierenden Person, ob die Zugangsdaten zum aktivierten Projekt gehören, vollständige Fehlermeldung, Anfrage-ID, Zeitstempel und Zeitzone, gegebenenfalls einen Screenshot sowie eine kurze Aufgabenbeschreibung ohne vertrauliche 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

Nutze dieses Vorgehen, wenn die genehmigte Konfiguration auf die falsche Organisation, den falschen Workspace oder das falsche API-Projekt verweist; das vorgesehene Projekt nicht ausschließlich intern ist; eine erwartete Einstellung fehlt; die falsche Daybreak-Stufe aktiviert ist; Zugangsdaten des falschen Projekts verwendet werden; der Zugang zwischen API- und Workspace-Zugangsweg wechseln muss; oder eine Rücksetzung oder Entfernung aussteht.

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

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

• Bitte beim API-Zugang eine Person mit Inhaberrechten für die API-Organisation, die freigegebenen Daybreak-Einstellungen für das vorgesehene Projekt anhand der obigen Schritte zu prüfen. Das Projekt darf kein Standardprojekt sein.

• Wenn der genehmigte API-Schalter sichtbar, aber ausgeschaltet ist, lass ihn von der Person mit Inhaberrechten für die API-Organisation einschalten und die Änderung speichern. Lass beim Workspace-Zugang eine Person mit Inhaberrechten für den Workspace die direkten und gruppenbasierten Rollen sowie die gespeicherten Modellberechtigungen der vorgesehenen Person prüfen. Prüfe vor einem erneuten Test in Codex mit ChatGPT-Anmeldung, ob der Daybreak-Schalter der betreffenden Person auf EIN steht.

• Verwende beim API-Zugang einen Schlüssel des aktivierten Zielprojekts 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 folgenden Angaben als Korrekturanfrage an dein OpenAI-Account-Team.

• Wiederhole den Zugangstest mit der korrigierten Konfiguration und genau dem genehmigten Alias oder der genehmigten Modell-ID.

Gib Folgendes an:

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

• Namen und IDs des aktuellen und des vorgesehenen Workspace, der API-Organisation und des API-Projekts, soweit bekannt.

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

• Genauer API-Alias oder genaue Modell-ID, die beim Test verwendet wurden.

• Ob die Anfrage einen Schlüssel des aktivierten Projekts verwendet und ob migrierte Workloads auf das Zielprojekt umgestellt wurden.

• Bestätigung, dass die vorgesehene Konfiguration nicht für Anwendungen für externe Kundschaft, Datenverkehr Dritter oder nachgelagerte Produkt-Workflows 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 geplanten Workflow des Teams sowie die Personen, die ihn voraussichtlich ausführen und überprüfen werden.

• Etwaige zeitliche Einschränkungen oder anstehende Einführungstermine.

Wenn genehmigte Projekteinstellungen verfügbar sind, sollen sie den Daybreak-Zugang nach Projekten trennen, 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-Account-Teams.

Wenn die Entfernung einer alten Organisation oder eines alten Projekts, ein Wechsel oder eine Berechtigungskorrektur noch aussteht, betrachte die korrigierte Konfiguration erst als einsatzbereit, wenn die Änderung bestätigt ist.

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 Konfiguration nur für autorisierte Abwehrmaßnahmen.

• Nutze Systeme, die deiner Organisation gehören oder die sie ausdrücklich prüfen darf.

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

• Beziehe bei Befunden mit erheblichen Auswirkungen und deren Behebung Menschen ein.

• Verwende genau die Organisation, den Workspace, das API-Projekt, die Daybreak-Stufe und den API-Alias oder die Modell-ID aus deinen Onboarding-Unterlagen.

• Erlaube nur Personen mit Inhaberrechten für die API-Organisation, die Daybreak-Projekteinstellungen zu konfigurieren. Personen mit Inhaberrechten für den Workspace verwalten dessen Standardeinstellungen und die Zuweisung benutzerdefinierter Rollen. Die Genehmigung für Daybreak Blue schließt Daybreak Red nicht ein.

• Bewahre die Projekt-Zugangsdaten sicher auf und beschränke sie auf das aktivierte, ausschließlich interne Projekt.

• Stelle Daybreak-Funktionen nicht für externe Kundenunternehmen, externe Personen oder nachgelagerte Produkt-Workflows bereit.