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.

Überblick

Nutze diesen Leitfaden, wenn du das Daybreak-Onboarding für deine Organisation koordinierst und vom Intake über die Bereitstellung bis zu einer einsatzbereiten Einrichtung kommen musst.

Daybreak ist das Programm von OpenAI für Cybersicherheitsarbeit, einschließlich Modellen, Zugangswegen, Codex, Codex Security und unterstützenden Services.

Die meisten Enterprise-Teams nutzen GPT-5.5 mit Trusted Access for Cyber für genehmigte interne defensive Workflows. Für diesen Zugangsweg stellt OpenAI die Organisation oder den Workspace bereit, die bzw. der im Intake-Prozess identifiziert wurde, nachdem die Persona-KYB-Verifizierung und die internen Eignungsprüfungen abgeschlossen sind. Der Zugang kann je nach genehmigter Einrichtung für eine Codex- oder ChatGPT-Organisation, eine API-Organisation oder beides gelten.

Einige Workflows mit höherem Risiko können auch nach der Bereitstellung abgelehnt werden. Beginne daher mit einem klar begrenzten defensiven Workflow genau auf der Oberfläche, die dein Team nutzen will.

Onboarding- und Bereitstellungsstatus verfolgen

Phase	Beschreibung	Nächster Schritt
Intake-Formular einreichen	Deine Organisation hat das Enterprise-Trusted-Access-Intake-Formular ausgefüllt	Achte auf eine E-Mail von Persona und schließe die KYB-Verifizierung ab. Stelle sicher, dass die Persona-E-Mail die richtige Kontaktperson in der Organisation erreicht.
KYB-E-Mail von Persona erhalten und abschließen	Nachdem das Intake-Formular eingereicht wurde, sendet Persona der im Formular angegebenen Kontaktperson eine E-Mail, um die Know-Your-Business-Verifizierung (KYB) abzuschließen.	Schließe die Persona-KYB-Anfrage ab. Nach Abschluss der KYB-Verifizierung führt OpenAI interne Eignungsprüfungen durch und stellt den Zugang erst bereit, wenn diese Prüfungen bestanden sind.
Benachrichtigung über die Bereitstellung erhalten	OpenAI hat den Zugang auf die im Intake-Formular angeforderte Organisation oder den angeforderten Workspace angewendet.	Prüfe, ob der Zugang auf der angeforderten Oberfläche korrekt bereitgestellt ist. Beachte, dass der Zugang derzeit nicht in einem für Kunden sichtbaren Workspace-Dashboard angezeigt wird.
Zugang prüfen und einen begrenzten defensiven Workflow starten	Die bereitgestellte Organisation oder der Workspace ist bestätigt und die vorgesehene Zugangsprüfung ist erfolgreich	Wähle als ersten Workflow einen begrenzten defensiven Workflow aus, benenne die ausführende und die prüfende Person und nutze das Codex-Security-Plugin oder eine genehmigte Responses-API-Organisation.

Bereitgestellten Zugangsweg verstehen

Die Bestätigung von OpenAI sollte angeben, welcher Zugangsweg bereitgestellt wurde, wer ihn nutzen kann und welche Organisation oder welcher Workspace zuerst genutzt werden soll.

Für praktische Repository-Workflows beginnst du mit Codex oder dem Codex-Security-Plugin. Nutze Codex CLI oder die Codex GitHub Action für genehmigte Automatisierung. Wenn der Zugang für eine API-Organisation bereitgestellt ist, beschränke Anfragen und Anmeldedaten auf diese Organisation.

Bereitgestellter Zugangsweg	Wer ihn nutzen kann	Wo der Zugang gilt	Erste Oberfläche zur Zugangsprüfung
Zugang über Codex	Mitglieder der benannten internen Codex- oder ChatGPT-Organisation oder des entsprechenden Workspace	Die bereitgestellte Organisation oder der bereitgestellte Workspace. Der Zugang gilt für diesen Weg organisationsweit	Für Sicherheitsarbeit an statischen Assets beginnst du mit dem Codex-Security-Plugin.
Zugang über API-Organisation	Nutzende oder Dienste, die bei der benannten internen API-Organisation authentifiziert sind	Die bereitgestellte API-Organisation	Die Responses API oder ein anderer genehmigter Codex-API-Workflow.

Für GPT-5.5 mit Trusted Access for Cyber wird Workspace-Zugang für die benannte Codex- oder ChatGPT-Organisation bereitgestellt, API-Zugang für die benannte API-Organisation. Wenn deine Bestätigung einen anderen benutzerspezifischen oder modellspezifischen Weg nennt, befolge genau diese Anweisungen, statt organisationsweiten Zugang anzunehmen. Wenn der bereitgestellte Zugangsweg unklar ist, bitte deinen OpenAI-Kontakt vor dem Testen um Bestätigung.

Bereitgestellten Zugang prüfen

Nachdem OpenAI die Bereitstellung bestätigt hat, führe diesen Prompt auf der genau bestätigten Oberfläche aus. Das kann in Codex erfolgen, während du bei der ausschließlich internen Organisation oder dem Workspace angemeldet bist, oder über die Responses API mit Anmeldedaten aus der bestätigten API-Organisation.

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 begrenzte Ergebnis liefert, bestätige zuerst die angemeldete Identität sowie die Organisation oder den Workspace. Das Ergebnis kann auf eine unvollständige Bereitstellung, eine Routing-Abweichung oder eine Richtliniengrenze hinweisen. Wenn die Bereitstellung abgeschlossen ist und das Problem weiterhin besteht, folge Trusted Access for Cyber: Häufige Probleme und Fehlerbehebung für Diagnoseschritte und die Angaben, die du beim Kontakt mit dem Support mitschicken solltest. Zum Öffnen einer Support-Anfrage siehe: Wie kontaktiere ich den Support? Eine Ablehnung kann so 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.

Einrichtungsprobleme eskalieren

Bevor du Workspaces, API-Organisationen, Repositorys oder Anmeldedaten änderst, bitte dein OpenAI Account Team zu bestätigen, dass die Bereitstellung abgeschlossen ist und die vorgesehene Organisation, der Workspace und der Zugangsweg korrekt sind.

Bei Problemen mit Verifizierung, Zugang, Modell oder Cybersicherheit folge Trusted Access for Cyber: Häufige Probleme und Fehlerbehebung. Der Artikel enthält Diagnoseschritte und die Informationen, die du beim Kontakt mit dem Support angeben solltest, etwa Organisations-ID, Produktoberfläche, Modell, vollständige Fehlermeldung, Anfrage-ID, Zeitstempel und Zeitzone, ggf. Screenshot sowie eine kurze, bereinigte Beschreibung der Aufgabe.

Zum Öffnen einer Support-Anfrage siehe: Wie kontaktiere ich den Support?

Ersten Workflow starten

Für die meisten Teams sollte der erste Workflow im Codex-Security-Plugin beginnen, mit einem engen Repository-, Branch- oder Alert-Umfang. Codex CLI ist der Weg für skalierte Automatisierung, wenn die Workflow-Verantwortlichen bereits einen vertrauenswürdigen CI/CD-Workflow haben, den du validieren musst.

Abweichung bei Workspace oder API-Organisation korrigieren

Nutze diesen Weg, wenn die genehmigte Einrichtung auf die falsche Organisation verweist, die eingereichte Organisation nicht ausschließlich intern ist, der Zugang zwischen API- und Workspace-Pfaden verschoben werden muss oder ein Rollback bzw. eine Entfernung aussteht.

Pausiere Tests auf dem abweichenden Workspace oder der abweichenden API-Organisation.
Ermittle die aktuelle Einrichtung, die eingereicht oder bereitgestellt wurde.
Ermittle den vorgesehenen ausschließlich internen Workspace, die API-Organisation oder beides.
Bestätige, ob die alte Einrichtung entfernt, zurückgesetzt oder unverändert belassen werden soll.
Sende die folgenden Details als Korrekturanfrage an dein OpenAI Account Team.
Warte, bis OpenAI bestätigt, dass die Korrektur abgeschlossen ist.
Führe die Zugangsprüfung erneut auf der korrigierten Einrichtung aus.

Gib Folgendes an:

Unternehmensname und primärer technischer Kontakt oder Workspace-Admin-Kontakt
Name und ID des aktuellen Workspace oder der aktuellen API-Organisation, falls bekannt
Name und ID des vorgesehenen ausschließlich internen Workspace oder der vorgesehenen API-Organisation, falls bekannt
Bestätigung, dass die vorgesehene Einrichtung nicht für kundenorientierte Anwendungen, Drittanbieter-Traffic oder nachgelagerte Produkt-Workflows genutzt wird
ob der Zugang aus der vorherigen Einrichtung entfernt oder zurückgesetzt werden soll
ob die neue Einrichtung eine Frage zu Abrechnung, Budgetlimit oder kommerziell verantwortlicher Person aufwirft
der erste Workflow, den das Team ausführen will, und die voraussichtlich ausführenden Personen
zeitliche Einschränkungen oder anstehende Enablement-Session, falls vorhanden

Wenn die Entfernung einer alten Organisation oder ein Wechsel noch aussteht, behandle die korrigierte Einrichtung erst dann als bereit, wenn OpenAI den Abschluss der Änderung bestätigt.

Hinweis zur Nutzung

Jeder Workspace und jede API-Organisation, die für Trusted Access aktiviert ist, sollte nur intern sein. „Nur intern“ bedeutet, dass der Zugriff von deinem eigenen autorisierten Team für defensive Arbeit deiner Organisation genutzt wird und nicht mit kundenseitigem Traffic, extern angebotenen Sicherheitsservices oder nachgelagerten Produktfunktionen verknüpft ist, die Anfragen oder Inhalte von Dritten über diesen Zugriff weiterleiten.

Keine Datenaufbewahrung (ZDR)

Die Bereitstellung von Trusted Access aktiviert keine Zero Data Retention (ZDR) automatisch. ZDR muss für die genaue Organisation separat angefordert und bereitgestellt werden. Wenn deine Organisation ZDR oder eine andere bestimmte Regelung zur Datenaufbewahrung benötigt, bestätige vor dem ersten Workflow deines Teams, dass die Organisation, die du nutzen willst, von diesen Bedingungen abgedeckt ist.

Betriebliche Grenzen

Nutze die bereitgestellte Einrichtung nur für autorisierte defensive Arbeit.
Nutze Systeme, die deiner Organisation gehören oder für deren Prüfung sie ausdrücklich autorisiert ist.
Halte den ersten Workflow eng begrenzt und überprüfbar.
Beziehe Menschen bei Erkenntnissen mit hoher Auswirkung und bei der Behebung ein.
Nutze den Workspace, die API-Einrichtung und den Modellzugriff, die in deinen Onboarding-Details aufgeführt sind.
Weite Trusted-Access-Funktionen nicht auf Drittanbieter-Kund:innen, externe Nutzer:innen oder nachgelagerte Produkt-Workflows aus.

Enterprise-Daybreak-Onboarding