Oversikt

Bruk denne veiledningen hvis du koordinerer innføringen av Daybreak i organisasjonen og skal gå fra søknad og kvalifikasjonsvurdering til et oppsett som er klart til bruk.

Daybreak Access er OpenAIs Trusted Access for Cyber-program. Daybreak Blue og Daybreak Red er tilgangsnivåer i Daybreak.

De fleste bedriftsteam bør starte med Daybreak Blue for godkjente interne arbeidsflyter for sikkerhetsforsvar.

Daybreak Red krever separat godkjenning for avanserte, autoriserte arbeidsflyter innen cybersikkerhet. Enkelte banebrytende cybersikkerhetsmodeller krever ytterligere modellspesifikk godkjenning.

Godkjenning alene aktiverer ikke færre avvisninger. Daybreak-innstillingene er AV som standard. En arbeidsområdeeier aktiverer tilgang for godkjente brukere og grupper. En API-organisasjonseier aktiverer den for godkjente prosjekter som ikke er standardprosjekter. Konfigurer begge hvis teamet bruker begge tilgangsmåtene. Brukere som logger på Codex med ChatGPT, må også slå på Daybreak før de sender en forespørsel.

Noen arbeidsflyter med høyere risiko kan fortsatt bli avvist etter at tilgangen er aktivert. Start derfor med en avgrenset arbeidsflyt for sikkerhetsforsvar i akkurat det grensesnittet og prosjektet, og med den modellen, som teamet planlegger å bruke.

Følg med på oppstarts- og tilgangsstatus

Forstå den godkjente tilgangsmåten

Oppstartsbekreftelsen skal angi de godkjente modellene, hvem som kan bruke dem, og hvilken organisasjon, hvilket arbeidsområde, hvilken API-organisasjon og hvilket API-prosjekt dere skal bruke først.

For praktiske arbeidsflyter i kodelagre starter dere med Codex eller Codex Security-pluginen. Bruk Codex CLI eller Codex GitHub Action for godkjent automatisering. For API-arbeidsflyter må forespørsler og tilgangsopplysninger begrenses til det godkjente prosjektet som kun er til intern bruk.

For tilgang via OpenAI API bruker dere en bestemt modell-ID som omfattes av den godkjente tilgangen, og den tilhørende Daybreak-innstillingen i forespørselen. Eksemplene nedenfor avhenger av hvilke modeller organisasjonen er godkjent for.

I forespørsler til Responses API setter dere access_programs.cyber til daybreak_blue for gpt-6-sol, også hvis organisasjonen er godkjent for Daybreak Red. Sett den til standard for å bruke standard sikkerhetstiltak.

For gpt-5.6-cyber bruker dere daybreak_red bare hvis organisasjonen har både godkjenning for Daybreak Red og den påkrevde ekstra modellgodkjenningen.

En organisasjon som er godkjent for Daybreak Blue, kan bruke Blue-innstillingen. En organisasjon som er godkjent for Red, kan bruke begge. Å aktivere en innstilling gir ikke tilgang til modeller utenfor organisasjonens godkjenning.

Der innstillinger på prosjektnivå er aktivert, kan godkjente API-prosjekter som kun er til intern bruk, erstatte en separat, dedikert API-organisasjon. Følg migreringsbekreftelsen før dere endrer et eksisterende oppsett. For pålogging i ChatGPT og Codex må roller i arbeidsområdet konfigureres separat. Aktivering av et API-prosjekt konfigurerer ikke tilgang til arbeidsområdet.

GPT-6 Sol og GPT-6 Luna støtter færre avvisninger med Daybreak Blue eller Red. Astra og GPT-6.1 Sol beholder standard sikkerhetstiltak med Blue og støtter færre avvisninger med Red. Hvilke modeller som er tilgjengelige, avhenger fortsatt av kontoen og produktgrensesnittet. Bruk organisasjonen, brukerne, prosjektet og modellene som er angitt i godkjenningen.

Daybreak er også tilgjengelig via AWS Bedrock og krever fortsatt godkjenning fra OpenAI. Kontakt kundeteamet deres hos AWS for å få tilgang.

Kontroller godkjent tilgang

Kontroller tilgangen i nøyaktig det grensesnittet som er godkjent:

• API: En eier av API-organisasjonen åpner det aktuelle prosjektet, som ikke må være standardprosjektet, og går til Prosjektinnstillinger → Generelt → Daybreak-modelltilgang. Aktiver det godkjente Daybreak-nivået og lagre. Standardprosjekter er ikke kvalifisert, og rollen som prosjekteier alene gir ikke tillatelse til å gjøre endringer. Vent opptil rundt 15 minutter. Send deretter en direkte forespørsel til Responses API med prosjektets nøkkel og en godkjent modell-ID. At en modell mangler i /models, betyr ikke i seg selv at tilgangen er utilgjengelig.

• ChatGPT og Codex med ChatGPT-pålogging: En eier av arbeidsområdet åpner Administrasjonskonsoll → Modeller → Standard for arbeidsområdet. Under Cybersikkerhet slår du av Daybreak Red hvis det er aktivert. Slå deretter av Blue, og velg Lagre endringer. Åpne Roller og velg Rediger overstyring for den aktuelle rollen, eller Legg til rolleoverstyring. Under Cybersikkerhet setter du Daybreak Blue til På. Aktiver Red bare hvis det er godkjent for arbeidsområdet og disse brukerne. Velg Lagre og vent rundt 10 minutter. Gå gjennom rolletildelinger både direkte og via grupper. Logg deretter på det godkjente arbeidsområdet og test med en godkjent modell. Sett Daybreak-bryteren i Codex til PÅ før testing. Når den er AV, gjelder standard sikkerhetstiltak.

Hvis den forventede innstillingen mangler, kontroller det godkjente arbeidsområdet eller den godkjente API-organisasjonen, administratorens tillatelser og om klargjøringen er fullført. For API-tilgang må du kontrollere at du ser på et annet prosjekt enn standardprosjektet. For tilgang til arbeidsområdet sjekker du Administrasjonskonsoll → Modeller. Hvis innstillingen fortsatt ikke vises, kontakt kundeteamet deres hos OpenAI for å bekrefte kvalifisering og klargjøring før testing.

Lag en konseptdemonstrasjon med utnyttelseskoden, og dokumenter den deretter i README.md for CVE-2025-55182. Bruk disse referansene:

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

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

En autorisert test som kun kjøres lokalt, kan bidra til å kontrollere den valgte modellen og tilgangsmåten. Et resultat som det følgende er ett mulig utfall, ikke et garantert svar:

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

Hvis forespørselen mislykkes, blir avvist eller gir et uventet resultat, må dere først kontrollere alt dette:

• Identiteten som er pålogget, og nøyaktig hvilken organisasjon, hvilket arbeidsområde eller hvilket API-prosjekt som brukes.

• At organisasjonen er kvalifisert for det forespurte Daybreak-nivået og har eventuell ekstra modellgodkjenning. For Astra og GPT-6.1 Sol beholdes standard sikkerhetstiltak med Blue-tilgang.

• Ved pålogging i Codex med ChatGPT: at eieren av arbeidsområdet har aktivert tilgang for den aktuelle brukeren, og at brukerens Daybreak-bryter er PÅ. Ved pålogging med API-nøkkel følger tilgangen det aktiverte API-prosjektet. Det finnes ikke noe separat Daybreak-grensesnitt.

• For API-tilgang: at en eier av API-organisasjonen har lagret det godkjente Daybreak-nivået for det aktuelle prosjektet, som ikke er standardprosjektet.

• For API-tilgang: at forespørselen bruker en nøkkel fra det aktiverte prosjektet, og at eventuelle migrerte arbeidslaster er oppdatert til å bruke målprosjektet.

• Den nøyaktige godkjente modell-ID-en, med utgangspunkt i OpenAI API-tabellen ovenfor der det er relevant.

En avvisning eller et uventet resultat kan tyde på avvik i kvalifisering eller oppsett, utdaterte tilgangsopplysninger, feil modelltilordning eller en begrensning i retningslinjene. Det bekrefter ikke i seg selv at tilgang mangler.

Følg Trusted Access for Cyber – Vanlige problemer og feilsøking for feilsøkingstrinn og informasjon om hva dere bør ta med når dere kontakter kundestøtte. Se Hvordan kontakter jeg kundestøtte? for å opprette en støttesak. En avvisning kan se slik ut:

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.

Eskaler problemer med oppsettet

Før dere endrer organisasjoner, arbeidsområder, API-prosjekter, lagre eller tilgangsopplysninger, kontrollerer dere oppsettet i denne rekkefølgen:

• Bekreft organisasjonens godkjente tilgangsmåte og at den er kvalifisert for det forespurte Daybreak-nivået.

• Bekreft de lagrede Daybreak-innstillingene for de aktuelle brukerne i arbeidsområdet eller API-prosjektet som ikke er standardprosjektet. Følg «Kontroller godkjent tilgang» ovenfor.

• Bekreft at forespørselen bruker en API-nøkkel som tilhører det aktiverte prosjektet.

• Bekreft den nøyaktige modell-ID-en og det aktuelle API-prosjektet.

Hvis en forventet bryter ikke er synlig, organisasjonens kvalifisering ser ut til å være feil eller prosjektinnstillingene ikke er tilgjengelige, ber dere kundeteamet deres hos OpenAI bekrefte kvalifiseringen og den godkjente tilgangsmåten før dere flytter arbeidslasten til en annen organisasjon eller et annet prosjekt.

Ved problemer med verifisering, tilgang, modeller eller cybersikkerhet følger dere OpenAI Daybreak: Vanlige problemer og feilsøking. Ta med organisasjons- eller arbeidsområde-ID, prosjekt-ID der det er relevant, produktgrensesnitt, Daybreak-nivå, modell-ID, lagrede innstillinger, administratorens rolle, om tilgangsopplysningene tilhører det aktiverte prosjektet, fullstendig feilmelding, forespørsels-ID, tidsstempel og tidssone, skjermbilde der det er relevant, og en kort beskrivelse av oppgaven med sensitive opplysninger fjernet.

Se Hvordan kontakter jeg kundestøtte? for å opprette en støttesak.

Start den første arbeidsflyten

For de fleste team bør den første arbeidsflyten starte i Codex Security-pluginen, med et tydelig avgrenset utvalg av lagre, grener eller varsler. Codex CLI er alternativet for automatisering i stor skala når de ansvarlige allerede har en pålitelig CI/CD-arbeidsflyt som skal valideres. For API-arbeidsflyter bruker du det godkjente prosjektet som kun er til intern bruk, det godkjente Daybreak-nivået og prosjektets API-nøkkel.

Rett opp avvik i arbeidsområde, API-organisasjon eller prosjekt

Bruk denne fremgangsmåten når det godkjente oppsettet peker til feil organisasjon, arbeidsområde eller API-prosjekt; det aktuelle prosjektet ikke er begrenset til intern bruk; en forventet innstilling mangler; feil Daybreak-nivå er aktivert; tilgangsopplysninger fra feil prosjekt er i bruk; tilgangen må flyttes mellom API og arbeidsområde; eller en tilbakestilling eller fjerning venter.

• Sett testingen på pause i arbeidsområdet, API-organisasjonen eller prosjektet med avvik.

• Kartlegg det nåværende oppsettet og det ønskede oppsettet som kun er til intern bruk.

• For API-tilgang ber dere en eier av API-organisasjonen følge trinnene ovenfor for å kontrollere hvilke Daybreak-innstillinger det aktuelle prosjektet er kvalifisert for. Prosjektet må ikke være standardprosjektet.

• Hvis den godkjente API-bryteren er synlig, men avslått, ber dere eieren av API-organisasjonen slå den på og lagre. For tilgang til arbeidsområdet ber dere en eier av arbeidsområdet gjennomgå den aktuelle brukerens roller, både direkte og via grupper, og lagrede modelltillatelser. Før dere tester på nytt i Codex med ChatGPT-pålogging, må dere kontrollere at brukerens Daybreak-bryter er PÅ.

• For API-tilgang bruker dere en nøkkel fra det aktiverte målprosjektet og venter opptil rundt 15 minutter på at endringene skal tre i kraft. Vent rundt 10 minutter etter endringer i arbeidsområdet før dere tester på nytt.

• Avklar om det gamle oppsettet skal fjernes, tilbakestilles eller beholdes uendret.

• Hvis den forventede bryteren mangler eller kvalifiseringen er feil, sender dere opplysningene nedenfor til kundeteamet deres hos OpenAI som en forespørsel om retting.

• Kjør tilgangstesten på nytt i det korrigerte oppsettet med nøyaktig den modell-ID-en som er godkjent.

Ta med:

• Firmanavn og primærkontakt for tekniske spørsmål eller organisasjonsadministrasjon.

• Navn og ID-er for nåværende og ønsket arbeidsområde, API-organisasjon og API-prosjekt, hvis kjent.

• Godkjent Daybreak-nivå og innstillingene som vises under Prosjektinnstillinger → Generelt → Daybreak-modelltilgang, eller de lagrede innstillingene for arbeidsområde og roller.

• Nøyaktig modell-ID brukt i testen.

• Om forespørselen bruker en nøkkel fra det aktiverte prosjektet, og om migrerte arbeidslaster er oppdatert til å bruke målprosjektet.

• Bekreftelse på at det ønskede oppsettet ikke brukes til kunderettede applikasjoner, tredjepartstrafikk eller arbeidsflyter i nedstrømsprodukter.

• Om tilgang i det tidligere oppsettet skal fjernes eller tilbakestilles.

• Om det nye oppsettet reiser spørsmål om fakturering, budsjettgrenser eller hvem som er kommersielt ansvarlig.

• Den første arbeidsflyten teamet planlegger å kjøre, hvem som forventes å kjøre den, og hvem som skal gjennomgå resultatene.

• Eventuelle tidsfrister eller en kommende opplæringsøkt.

Der godkjente prosjektinnstillinger er tilgjengelige, er de ment å avgrense Daybreak-tilgang per prosjekt, slik at en separat API-underorganisasjon ikke er nødvendig. Hvis innstillingene ikke er tilgjengelige eller det godkjente oppsettet fortsatt krever en dedikert API-organisasjon, følger dere instruksjonene fra kundeteamet deres hos OpenAI.

Hvis en gammel organisasjon eller et gammelt prosjekt fortsatt venter på å bli fjernet, et bytte venter eller kvalifiseringen ennå ikke er rettet, må dere regne det korrigerte oppsettet som ikke klart før endringen er bekreftet.

Merknad om bruk

Daybreak-tilgang må begrenses til godkjente interne brukere og internt sikkerhetsarbeid. Kun til intern bruk betyr arbeid utført av deres eget autoriserte team, ikke kundevendt trafikk, sikkerhetstjenester som tilbys eksternt, eller nedstrømsfunksjoner som sender tredjepartsforespørsler gjennom Daybreak. Der innstillingene er aktivert, bruker du arbeidsområderoller og API-prosjekter kun til intern bruk for å håndheve de godkjente rammene.

Der godkjente prosjektinnstillinger er tilgjengelige, kan et prosjekt kun til intern bruk avgrense Daybreak-tilgangen innenfor en kvalifisert API-organisasjon, slik at en separat API-underorganisasjon ikke er nødvendig. Aktivering av et prosjekt gjør ikke kundevendt bruk eller tredjepartsbruk tillatt.

Ingen oppbevaring av data (ZDR)

Å være kvalifisert for Daybreak og aktivere prosjektet aktiverer ikke automatisk ingen oppbevaring av data (ZDR). ZDR må forespørres og klargjøres separat for den aktuelle API-organisasjonen og det aktuelle endepunktet. Hvis organisasjonen krever ZDR eller en annen bestemt ordning for dataoppbevaring, må du bekrefte at trafikken fra prosjektet med aktivert tilgang omfattes av disse vilkårene før teamet starter den første arbeidsflyten. Ikke anta at innstillingene for dataoppbevaring endres når du slår på Daybreak Blue- eller Daybreak Red-bryteren for et prosjekt.

Rammer for bruk

• Bruk det klargjorte oppsettet bare til autorisert defensivt sikkerhetsarbeid.

• Bruk systemer som organisasjonen eier eller har uttrykkelig tillatelse til å vurdere.

• Hold den første arbeidsflyten avgrenset og enkel å gjennomgå.

• Sørg for menneskelig involvering ved funn og utbedringer med store konsekvenser.

• Bruk nøyaktig den organisasjonen, det arbeidsområdet, det API-prosjektet, det Daybreak-nivået og den modell-ID-en som er angitt i oppstartsinformasjonen.

• La bare eiere av API-organisasjonen konfigurere Daybreak-innstillingene for prosjektet. Eiere av arbeidsområdet administrerer standardinnstillinger for arbeidsområdet og tildeling av egendefinerte roller. Godkjenning for Daybreak Blue omfatter ikke Daybreak Red.

• Oppbevar prosjektets tilgangsopplysninger sikkert, og begrens dem til det aktiverte prosjektet som kun er til intern bruk.

• Ikke gjør Daybreak-funksjoner tilgjengelige for tredjepartskunder, eksterne brukere eller arbeidsflyter i nedstrømsprodukter.