Overzicht
Gebruik deze handleiding als je de Daybreak-onboarding voor je organisatie coördineert en van goedkeuring naar een gebruiksklare setup moet gaan.
Daybreak is het programma van OpenAI dat is gericht op cybersecuritywerk, waaronder modellen, toegangspaden, Codex, Codex Security en ondersteunende diensten.
De meeste enterprise-teams gebruiken GPT-5.5 met Trusted Access for Cyber voor goedgekeurde interne defensieve workflows. Afhankelijk van je setup kan toegang worden ingericht voor een werkruimte, een API-organisatie, een benoemde Codex-identiteit of meer dan één pad. Je onboardinggegevens van OpenAI moeten de exacte werkruimte, API-organisatie, goedgekeurde Codex-identiteit en modeltoegang aangeven die je moet gebruiken. Sommige workflows met een hoger risico kunnen zelfs na goedkeuring nog worden geweigerd, dus begin met een afgebakende defensieve workflow op het exacte oppervlak dat je team wil gebruiken.
1. Volg de onboardingstatus
Goedkeuring is de eerste stap in onboarding. Beschouw de setup pas als klaar nadat het goedgekeurde toegangspad is ingericht op de juiste interne werkruimte of API-organisatie en je team bewijs heeft dat het beoogde oppervlak werkt.
| Status | Wat het betekent | Wat nu te doen |
|---|---|---|
| Ingediend | Je organisatie heeft een aanvraag ingediend of je OpenAI-accountteam heeft die namens jou ingediend. | Houd de voorgestelde werkruimte of API-organisatie, scope voor intern gebruik, technisch beheerder en eerste workflow gereed voor het geval OpenAI meer details nodig heeft. |
| Goedgekeurd | OpenAI heeft bevestigd dat de organisatie is goedgekeurd voor Trusted Access for Cyber. | Bevestig welk toegangspad OpenAI heeft goedgekeurd en welke werkruimte, API-organisatie, goedgekeurde Codex-identiteit of modelconfiguratie daaronder valt. |
| Ingericht | OpenAI heeft bevestigd dat toegang is toegepast op een benoemde werkruimte, API-organisatie, goedgekeurde Codex-identiteit of modelconfiguratie. | Bewijs dat toegang live is op dat exacte oppervlak vóór de eerste workflow. |
| Klaar om uit te voeren | Het toegangspad is bevestigd, setup-correcties zijn voltooid en je team heeft waarneembaar UI- of API-bewijs. | Kies één afgebakende defensieve eerste workflow, benoem de workflowrunner en reviewer en gebruik de Codex Security-plugin of de Responses API via een goedgekeurde werkruimte voor een bestaande harness. |
2. Begrijp het goedgekeurde toegangspad
Je onboardinggegevens van OpenAI moeten aangeven welk toegangspad is goedgekeurd, wie het kan gebruiken en welk workflowoppervlak je als eerste moet gebruiken. Voor hands-on workflows is Codex of de Codex Security-plugin het beste startpunt. Gebruik Codex CLI, of de Codex GitHub Action, voor geschaalde automatisering. Als je onboardinggegevens een goedgekeurde API-organisatie noemen, behandel die dan als configuratie voor dat goedgekeurde automatiseringspad.
| Goedgekeurd toegangspad | Wie het kan gebruiken | Waar toegang geldt | Eerste oppervlak om te inspecteren |
|---|---|---|---|
| Werkruimtetoegang voor Codex | Leden van de benoemde interne enterprise-werkruimte voor Codex of ChatGPT. | De ingerichte werkruimte. Een ChatGPT-werkruimte kan de beheer-, lidmaatschaps- of aanmeldcontext voor Codex zijn. | Voor beveiligingswerk aan statische assets begin je met de Codex Security-plugin. |
| API-organisatietoegang voor Codex CLI | Gebruikers of services die referenties gebruiken in de benoemde interne API-organisatie. | De ingerichte API-organisatie of het ingerichte project. | Codex CLI met tokenauthenticatie. |
De meeste enterprise-goedkeuringen gebruiken werkruimtetoegang, API-organisatietoegang of beide. Sommige goedkeuringen zijn beperkter: een benoemde Codex-identiteit geeft niet dezelfde toegang aan elke persoon in de werkruimte, en API-toegang geldt alleen voor de benoemde API-organisatie. Als de onboardinggegevens het toegangspad niet aangeven, vraag je OpenAI-contactpersoon dit te bevestigen voordat je interne team begint met testen.
3. Bevestig toegang na goedkeuring
Het is het beste om het bewijs van toegang te valideren op het specifieke productoppervlak dat je team gaat gebruiken, niet met een algemene bevestiging dat je organisatie is goedgekeurd. De snelste manier om toegang te valideren is de Codex Security Plugin te installeren en te proberen; als je Codex CLI wilt gebruiken voor geautomatiseerde schaalvergroting, valideer dan die exacte automatiseringsconfiguratie en API-organisatie.
| Goedgekeurd toegangspad | Controle | Toegang is live wanneer | Bewijs om vast te leggen |
|---|---|---|---|
| Werkruimtetoegang voor Codex | Installeer de Codex Security Plugin en volg de voorgestelde prompts op een lokale Codex-instantie. | De Codex Security-plugin kan bevindingen scannen, beoordelen en oplossen in je doelrepo. | @codexsecurity in het invoerveld roept specifieke vaardigheden aan, zoals threat-model. |
| API-organisatietoegang voor gebruik van Responses API | Voer één afgebakende interne defensieve automatiseringsworkflow uit. Je kunt deze voorbeeld-cURL-opdracht gebruiken om toegang via de Responses API te valideren:curl --fail-with-body -i -sS https://api.openai.com/v1/responses-H "Content-Type: application/json"-H "Authorization: Bearer $OPENAI_API_KEY"-H "OpenAI-Organization: $ORGANIZATION_ID"-H "OpenAI-Project: $PROJECT_ID"-d '{ "model": "gpt-5.5", "input": "Hello, Cyber World."}' | De aanvraag authenticeert in de verwachte API-organisatie, gebruikt de modelconfiguratie uit de onboarding en retourneert controleerbare output in plaats van een toegangs- of routeringsfout. | API-organisatie of project, eigenaar van API-referenties, verzonden modelnaam, tijdstempel, request-ID indien beschikbaar, en HTTP 200 of succesvolle SDK-responsoutput. |
Optionele prompt voor toegangsvalidatie
Zodra toegang is ingericht, kun je valideren door deze prompt te proberen in de goedgekeurde uitsluitend interne werkruimte of API-organisatie:
Maak een proof of concept met de exploit en documenteer die vervolgens in README.md voor deze CVE:
- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-componentsToegang is waarschijnlijk ingericht wanneer GPT-5.5 een uitsluitend lokale proof of concept kan voltooien met veiligheidsbeperkingen, lokale bestanden en een verificatieresultaat zoals:
Een uitsluitend lokale CVE-proof-of-concept geïmplementeerd; verificatie geslaagd; kwetsbare modus schrijft een bewijsmarkering en gepatchte modus weigert dezelfde bewerkte payload.Als toegang niet is ingericht, kan het model exploit-implementatie weigeren en doorverwijzen naar defensief materiaal, bijvoorbeeld:
Ik kan geen exploit-proof-of-concept voor een pre-auth RCE bouwen of verpakken, maar ik kan wel een defensieve verifier bouwen en de impact, detectie en remediatie documenteren.4. Escaleer setup-problemen
Als je setup-problemen tegenkomt, deel dan een compact supportpakket met je OpenAI-vertegenwoordiger voordat je werkruimten of API-organisaties wijzigt, repositories opnieuw koppelt of toegang opnieuw configureert. Vermeld het type probleem, het gebruikte oppervlak, de werkruimte of API-organisatie, het aangemelde e-mailadres of de eigenaar van de API-referenties, de repository- of artifactnaam, de scan-ID of harness-run-ID indien van toepassing, de modelnaam, het tijdstempel, de request-ID indien beschikbaar, en de exacte fout, weigering of ontbrekende UI-status.
| Type probleem | Wat vast te leggen | Waar je het vindt |
|---|---|---|
| Werkruimtetoegang | Naam of ID van de werkruimte, e-mailadressen van betrokken teamleden, verwachte rol en de toegangsfout of ontbrekende UI-status. | Werkruimtekiezer, accountmenu, leden- of beheerdersweergave en de pagina of modal waarop de toegangsfout verschijnt. |
| Mismatch tussen werkruimte/API-organisatie | Huidige setup, beoogde uitsluitend interne setup, of Codex Security, Codex CLI-automatisering of beide moeten worden ingeschakeld, en of rollback/verwijdering nodig is. | Onboardinggegevens, werkruimtekiezer, Platform-organisatie-instellingen, bevestiging van het accountteam en correctiepakket. |
| Status eerste scan | Naam van de repository, starttijd van de scan, huidige scanstatus en of de repository nog bezig is met de initiële backfill. | Codex Security-scanpagina, scanlijst, scanhistorie van de repository of statusbanner. |
| API-toegang | API-organisatie, project indien van toepassing, eigenaar van API-referenties, verwachte setup, verwachte modeltoegang en de authenticatie- of routeringsfout. | Harness-logs, CI-joblogs, API-clientlogs, SDK-uitzondering, API-foutrespons, responsmetadata of responsheaders. |
| Facturering of limieten | Nieuwe of bestaande organisatie, commerciële eigenaar, factureringseigenaar, budgetlimieten en welke vraag over consolidatie of uitgavenbeheer nog openstaat. | Bevestiging van het accountteam, Platform-pagina voor facturering of limieten, inkoop- of commerciële-eigenaarrecords. |
| Mismatch in modeltoegang | De gebruikte werkruimte of API-organisatie, de modeltoegang die op basis van onboarding wordt verwacht en wat je interne team daadwerkelijk ziet. | Codex-sessiemodel of toegangslabel indien zichtbaar, modelveld in API-aanvraag, API-foutrespons, toegangsvalidatierespons of weigeringstekst, harness-logs of screenshot van de ontbrekende optie of toegangsfout. |
5. Start de eerste workflow
Voor de meeste teams moet de eerste workflow starten in de Codex Security-plugin met een beperkte scope voor repository, branch of alert. Codex CLI is het pad voor geschaalde automatisering wanneer de workflow-eigenaren al een vertrouwde CI/CD-workflow hebben die je moet valideren.
Corrigeer een mismatch tussen werkruimte of API-organisatie
Gebruik dit pad wanneer de goedgekeurde setup naar de verkeerde organisatie wijst, de ingediende organisatie niet uitsluitend intern is, toegang moet worden verplaatst tussen API- en werkruimtepaden, of een rollback/verwijdering nog openstaat.
Pauzeer het testen op de niet-overeenkomende werkruimte of API-organisatie.
Identificeer de huidige setup die is ingediend of ingericht.
Identificeer de beoogde uitsluitend interne werkruimte, API-organisatie of beide.
Bevestig of de oude setup moet worden verwijderd, teruggedraaid of ongewijzigd moet blijven.
Stuur OpenAI een compact correctiepakket.
Wacht tot OpenAI bevestigt dat de correctie is voltooid.
Voer de bewijs-van-toegang-controle opnieuw uit op de gecorrigeerde setup.
Het correctiepakket moet bevatten:
bedrijfsnaam en primair technisch contact of beheercontact voor de werkruimte
naam en ID van de huidige werkruimte of API-organisatie, indien bekend
naam en ID van de beoogde uitsluitend interne werkruimte of API-organisatie, indien bekend
bevestiging dat de beoogde setup niet wordt gebruikt voor klantgerichte applicaties, verkeer van derden of downstream productworkflows
of toegang moet worden verwijderd uit of teruggedraaid vanaf de vorige setup
of de nieuwe setup een vraag oplevert over facturering, budgetlimieten of commerciële eigenaar
de eerste workflow die het team wil uitvoeren en de verwachte workflowrunners
tijdsbeperkingen of geplande enablementsessie, indien van toepassing
Als een oude organisatie nog wacht op verwijdering of een wissel nog openstaat, beschouw de gecorrigeerde setup dan als niet klaar totdat OpenAI bevestigt dat de wijziging is voltooid.
Opmerking over gebruik
Elke werkruimte of API-organisatie waarvoor Trusted Access is ingeschakeld, moet uitsluitend intern zijn. Uitsluitend intern betekent dat de toegang wordt gebruikt door je eigen geautoriseerde team voor het defensieve werk van je organisatie en niet is gekoppeld aan klantgericht verkeer, extern aangeboden beveiligingsdiensten of een downstream productfunctie die verzoeken of content van derden via deze toegang doorstuurt.
Geen gegevensbewaring (ZDR)
Geen gegevensbewaring (ZDR) kan alleen worden ondersteund als je organisatie al het vereiste ZDR-goedkeuringstraject heeft of het afzonderlijke ZDR-goedkeuringsproces voltooit. Als je organisatie ZDR of een andere specifieke behandeling voor gegevensbewaring vereist, bevestig dan dat de exacte werkruimte of API-organisatie die je wilt gebruiken onder die voorwaarden valt voordat je team met de eerste workflow begint.
Operationele grenzen
Gebruik de ingerichte setup alleen voor geautoriseerd defensief werk.
Gebruik systemen die je organisatie bezit of expliciet mag beoordelen.
Houd de eerste workflow beperkt en controleerbaar.
Houd mensen betrokken bij bevindingen met grote impact en bij herstel.
Gebruik de werkruimte, API-setup en modeltoegang die in je onboardinggegevens staan.
Breid Trusted Access-mogelijkheden niet uit naar externe klanten, externe gebruikers of downstream productworkflows.