Oversikt
Bruk denne veiledningen hvis du koordinerer Daybreak-onboarding for organisasjonen din og må gå fra godkjenning til et oppsett som er klart til bruk.
Daybreak er OpenAI's program med fokus på cybersikkerhetsarbeid, inkludert modeller, tilgangsveier, Codex, Codex Security og støttetjenester.
De fleste enterprise-team bruker GPT-5.5 med Trusted Access for Cyber for godkjente interne defensive arbeidsflyter. Avhengig av oppsettet ditt kan tilgang tildeles et arbeidsområde, en API-organisasjon, en navngitt Codex-identitet eller mer enn én vei. Onboarding-detaljene dine fra OpenAI bør angi nøyaktig hvilket arbeidsområde, hvilken API-organisasjon, godkjent Codex-identitet og modelltilgang som skal brukes. Enkelte arbeidsflyter med høyere risiko kan fortsatt bli avvist selv etter godkjenning, så start med en avgrenset defensiv arbeidsflyt på nøyaktig den flaten teamet planlegger å bruke.
1. Spor onboarding-statusen
Godkjenning er første trinn i onboarding. Behandle oppsettet som klart først etter at den godkjente tilgangsveien er tildelt på riktig internt arbeidsområde eller API-organisasjon, og teamet har bevis på at den tiltenkte flaten fungerer.
| Status | Hva det betyr | Hva du gjør videre |
|---|---|---|
| Sendt inn | Organisasjonen din sendte inn en forespørsel, eller OpenAI-kontoteamet sendte den inn på dine vegne. | Hold det foreslåtte arbeidsområdet eller API-organisasjonen, omfang for intern bruk, teknisk administrator og første arbeidsflyt klare i tilfelle OpenAI trenger flere detaljer. |
| Godkjent | OpenAI bekreftet at organisasjonen er godkjent for Trusted Access for Cyber. | Bekreft hvilken tilgangsvei OpenAI godkjente, og hvilket arbeidsområde, hvilken API-organisasjon, godkjent Codex-identitet eller modellkonfigurasjon som omfattes. |
| Tildelt | OpenAI bekreftet at tilgang ble brukt på et navngitt arbeidsområde, en API-organisasjon, en godkjent Codex-identitet eller en modellkonfigurasjon. | Bevis at tilgangen er aktiv på nøyaktig den flaten før den første arbeidsflyten. |
| Klar til å kjøre | Tilgangsveien er bekreftet, oppsettrettelser er fullført, og teamet har observerbare UI- eller API-bevis. | Velg én avgrenset defensiv første arbeidsflyt, navngi kjøreren og gjennomgåreren for arbeidsflyten, og bruk Codex Security-pluginen eller Responses API via et godkjent arbeidsområde for en eksisterende harness. |
2. Forstå den godkjente tilgangsveien
Onboarding-detaljene dine fra OpenAI bør angi hvilken tilgangsvei som ble godkjent, hvem som kan bruke den, og hvilken arbeidsflytflate som skal brukes først. For praktiske arbeidsflyter er det beste startpunktet Codex eller Codex Security-pluginen. Bruk Codex CLI eller Codex GitHub Action for automatisering i stor skala. Hvis onboarding-detaljene dine navngir en godkjent API-organisasjon, behandler du den som konfigurasjon for den godkjente automatiseringsveien.
| Godkjent tilgangsvei | Hvem kan bruke den | Hvor tilgangen gjelder | Første flate å inspisere |
|---|---|---|---|
| Arbeidsområdetilgang for Codex | Medlemmer av det navngitte interne Codex- eller ChatGPT-enterprise-arbeidsområdet. | Det tildelte arbeidsområdet. Et ChatGPT-arbeidsområde kan være kontekst for administrasjon, medlemskap eller innlogging for Codex. | For sikkerhetsarbeid med statiske ressurser, start med Codex Security-pluginen. |
| API-organisasjonstilgang for Codex CLI | Brukere eller tjenester som bruker legitimasjon i den navngitte interne API-organisasjonen. | Den tildelte API-organisasjonen eller det tildelte prosjektet. | Codex CLI med tokenautentisering. |
De fleste enterprise-godkjenninger bruker arbeidsområdetilgang, API-organisasjonstilgang eller begge. Noen godkjenninger er smalere: En navngitt Codex-identitet gir ikke samme tilgang til alle i arbeidsområdet, og API-tilgang gjelder bare for den navngitte API-organisasjonen. Hvis onboarding-detaljene ikke identifiserer tilgangsveien, ber du OpenAI-kontakten din om å bekrefte den før det interne teamet starter testing.
3. Bekreft tilgang når den er godkjent
Det er best å validere bevis på tilgang på den spesifikke produktflaten teamet skal bruke, ikke en generell bekreftelse på at organisasjonen er godkjent. Den raskeste måten å validere tilgang på er å installere og prøve Codex Security Plugin. Hvis du planlegger å bruke Codex CLI til automatisering i stor skala, må du validere nøyaktig den automatiseringskonfigurasjonen og API-organisasjonen.
| Godkjent tilgangsvei | Kontroll | Tilgangen er aktiv når | Bevis som skal fanges opp |
|---|---|---|---|
| Arbeidsområdetilgang for Codex | Installer Codex Security Plugin og følg de foreslåtte promptene på en lokal Codex-instans. | Codex Security-pluginen kan skanne, gjennomgå og rette funn i mållageret ditt. | @codexsecurity i inndatafeltet aktiverer bestemte ferdigheter, for eksempel threat-model. |
| API-organisasjonstilgang for bruk av Responses API | Kjør én avgrenset intern defensiv automatiseringsarbeidsflyt. Du kan bruke denne eksempelkommandoen for cURL til å validere tilgang via Responses API: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."}' | Forespørselen autentiseres i den forventede API-organisasjonen, bruker modellkonfigurasjonen fra onboarding og returnerer gjennomgåbare utdata i stedet for en tilgangs- eller rutingsfeil. | API-organisasjon eller prosjekt, eier av API-legitimasjon, sendt modellnavn, tidsstempel, forespørsels-ID hvis tilgjengelig, og HTTP 200 eller vellykket SDK-svarutdata. |
Valgfri prompt for tilgangsvalidering
Når tilgang er tildelt, kan du validere ved å prøve denne prompten i det godkjente interne arbeidsområdet eller API-organisasjonen:
Opprett et proof of concept med exploiten, og dokumenter deretter i README.md for denne CVE-en:
- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-componentsTilgangen er sannsynligvis tildelt når GPT-5.5 kan fullføre et lokalt proof of concept med sikkerhetsbegrensninger, lokale filer og et verifiseringsresultat som:
Implementerte et lokalt CVE proof of concept; verifisering bestått; sårbar modus skriver en bevismarkør, og patchet modus avviser den samme spesiallagde nyttelasten.Hvis tilgang ikke er tildelt, kan modellen avvise exploit-implementering og omdirigere til defensivt materiale, for eksempel:
Jeg kan ikke bygge eller pakke et exploit proof of concept for en pre-auth RCE, men jeg kan bygge en defensiv verifikator og dokumentere påvirkning, deteksjon og utbedring.4. Eskaler oppsettproblemer
Hvis du støter på oppsettproblemer, del en kompakt støttepakke med OpenAI-representanten din før du endrer arbeidsområder eller API-organisasjoner, kobler til lagre på nytt eller rekonfigurerer tilgang. Inkluder problemtypen, flaten som brukes, arbeidsområde eller API-organisasjon, innlogget e-post eller eier av API-legitimasjon, lager- eller artefaktnavn, skanne-ID eller harness-kjørings-ID hvis aktuelt, modellnavn, tidsstempel, forespørsels-ID hvis tilgjengelig, og den nøyaktige feilen, avvisningen eller manglende UI-tilstanden.
| Problemtype | Hva som skal fanges opp | Hvor du finner det |
|---|---|---|
| Arbeidsområdetilgang | Navn eller ID for arbeidsområde, e-postadressene til berørte teammedlemmer, forventet rolle og tilgangsfeilen eller manglende UI-tilstand. | Arbeidsområdevelger, kontomeny, medlems- eller administratorvisning og siden eller modalen der tilgangsfeilen vises. |
| Uoverensstemmelse mellom arbeidsområde/API-organisasjon | Nåværende oppsett, tiltenkt oppsett kun for intern bruk, om Codex Security, Codex CLI-automatisering eller begge skal aktiveres, og om tilbakestilling/fjerning er nødvendig. | Onboarding-detaljer, arbeidsområdevelger, organisasjonsinnstillinger i Platform, bekreftelse fra kontoteam og rettelsespakke. |
| Status for innledende skanning | Lagernavn, starttid for skanning, gjeldende skannestatus og om lageret fortsatt er i innledende etterfylling. | Codex Security-skanneside, skanneliste, lagerets skannehistorikk eller statusbanner. |
| API-tilgang | API-organisasjon, prosjekt hvis aktuelt, eier av API-legitimasjon, forventet oppsett, forventet modelltilgang og autentiserings- eller rutingsfeilen. | Harness-logger, CI-jobblogger, API-klientlogger, SDK-unntak, API-feilsvar, svarmetadata eller svarhoder. |
| Fakturering eller grenser | Ny eller eksisterende organisasjon, kommersiell eier, faktureringseier, budsjettgrenser og hvilket spørsmål om konsolidering eller utgiftskontroll som gjenstår. | Bekreftelse fra kontoteam, Platform-side for fakturering eller grenser, innkjøps- eller kommersielle eierregistre. |
| Uoverensstemmelse i modelltilgang | Arbeidsområdet eller API-organisasjonen som brukes, modelltilgangen som forventes fra onboarding, og hva det interne teamet faktisk ser. | Codex-øktmodell eller tilgangsetikett hvis synlig, modellfelt i API-forespørsel, API-feilsvar, svar på tilgangsvalidering eller avvisningstekst, harness-logger eller skjermbilde av det manglende alternativet eller tilgangsfeilen. |
5. Start den første arbeidsflyten
For de fleste team bør den første arbeidsflyten starte i Codex Security-pluginen med et smalt omfang for lager, gren eller varsel. Codex CLI er veien for automatisering i stor skala når eierne av arbeidsflyten allerede har en betrodd CI/CD-arbeidsflyt du må validere.
Korriger en uoverensstemmelse mellom arbeidsområde og API-organisasjon
Bruk denne veien når det godkjente oppsettet peker til feil organisasjon, den innsendte organisasjonen ikke er kun intern, tilgang må flyttes mellom API- og arbeidsområdeveier, eller en tilbakestilling/fjerning venter.
Sett testing på pause på det feiltilpassede arbeidsområdet eller API-organisasjonen.
Identifiser det nåværende oppsettet som ble sendt inn eller tildelt.
Identifiser det tiltenkte arbeidsområdet, API-organisasjonen eller begge som kun skal brukes internt.
Bekreft om det gamle oppsettet skal fjernes, rulles tilbake eller stå uendret.
Send OpenAI en kompakt rettelsespakke.
Vent til OpenAI bekrefter at rettelsen er fullført.
Kjør tilgangsbeviskontrollen på nytt på det korrigerte oppsettet.
Rettelsespakken bør inkludere:
firmanavn og primær teknisk kontakt eller administrator for arbeidsområdet
nåværende navn og ID for arbeidsområde eller API-organisasjon, hvis kjent
tiltenkt navn og ID for arbeidsområde eller API-organisasjon kun for intern bruk, hvis kjent
bekreftelse på at det tiltenkte oppsettet ikke brukes til kundevendte applikasjoner, tredjepartstrafikk eller nedstrøms produktarbeidsflyter
om tilgang skal fjernes eller rulles tilbake fra det forrige oppsettet
om det nye oppsettet skaper et spørsmål om fakturering, budsjettgrense eller kommersiell eier
den første arbeidsflyten teamet planlegger å kjøre, og de forventede arbeidsflytkjørerne
tidsbegrensninger eller kommende aktiveringsøkt, hvis aktuelt
Hvis en gammel organisasjon fortsatt venter på fjerning eller et bytte venter, behandler du det korrigerte oppsettet som ikke klart før OpenAI bekrefter at endringen er fullført.
Merknad om bruk
Alle arbeidsområder eller API-organisasjoner som er aktivert for Trusted Access, bør være kun interne. Kun internt betyr at tilgangen brukes av ditt eget autoriserte team til organisasjonens defensive arbeid og ikke er knyttet til kundevendt trafikk, eksternt tilbudte sikkerhetstjenester eller noen nedstrøms produktfunksjon som sender tredjepartsforespørsler eller -innhold gjennom denne tilgangen.
Ingen oppbevaring av data (ZDR)
Ingen oppbevaring av data (ZDR) kan bare støttes hvis organisasjonen din allerede har den nødvendige godkjenningsveien for ZDR eller fullfører den separate ZDR-godkjenningsprosessen. Hvis organisasjonen din krever ZDR eller en annen spesifikk behandling for dataoppbevaring, må du bekrefte at nøyaktig det arbeidsområdet eller den API-organisasjonen du planlegger å bruke, er dekket av disse vilkårene før teamet starter den første arbeidsflyten.
Driftsgrenser
Bruk det tildelte oppsettet bare til autorisert defensivt arbeid.
Bruk systemer organisasjonen eier eller eksplisitt er autorisert til å vurdere.
Hold den første arbeidsflyten smal og mulig å gjennomgå.
Hold mennesker involvert for funn og utbedringer med høy påvirkning.
Bruk arbeidsområdet, API-oppsettet og modelltilgangen som er oppført i onboarding-detaljene dine.
Ikke utvid Trusted Access-funksjoner til tredjepartskunder, eksterne brukere eller nedstrøms produktarbeidsflyter.