Sådan gennemfører du enterprise-onboarding til Trusted Access, validerer provisioneret adgang, retter problemer med organisation eller arbejdsområde og bliver klar til den første arbejdsgang.

Oversigt

Brug denne vejledning, hvis du koordinerer Daybreak-onboarding for din organisation og skal gå fra intake via provisionering til en opsætning, der er klar til brug.

Daybreak er OpenAIs program med fokus på cybersikkerhedsarbejde, herunder modeller, adgangsveje, Codex, Codex Security og understøttende tjenester.

De fleste enterprise-teams bruger GPT-5.5 med Trusted Access for Cyber til godkendte interne defensive arbejdsgange. For denne adgangsvej provisionerer OpenAI den organisation eller det arbejdsområde, der er identificeret gennem intake-processen, når Persona KYB-verificering og interne egnethedskontroller er gennemført. Adgang kan gælde for en Codex- eller ChatGPT-organisation, en API-organisation eller begge dele, afhængigt af den godkendte opsætning.

Nogle arbejdsgange med højere risiko kan stadig blive afvist efter provisionering, så start med en afgrænset defensiv arbejdsgang på præcis den flade, dit team planlægger at bruge.

Følg onboarding- og provisioneringsstatus

Fase	Beskrivelse	Hvad du skal gøre nu
Indsend intake-formular	Din organisation har udfyldt enterprise-intake-formularen til Trusted Access	Hold øje med en mail fra Persona, og gennemfør KYB-verificering. Sørg for, at Persona-mailen når frem til den rette kontaktperson i organisationen.
Modtag og udfyld KYB-mail fra Persona	Når intake-formularen er indsendt, sender Persona en mail til den kontaktperson, der er angivet i formularen, for at gennemføre Know Your Business-verificering (KYB).	Gennemfør Persona KYB-anmodningen. Når KYB er gennemført, udfører OpenAI interne egnethedskontroller og provisionerer først, når disse kontroller er bestået.
Modtag besked om, at du er blevet provisioneret	OpenAI har tildelt adgang til den organisation eller det arbejdsområde, der blev anmodet om i intake-formularen.	Kontrollér, at adgangen er korrekt provisioneret på den ønskede flade. Bemærk, at adgangen i øjeblikket ikke vises i et kundesynligt dashboard for arbejdsområdet.
Kontrollér, at du har adgang, og start en afgrænset defensiv arbejdsgang	Den provisionerede organisation eller det provisionerede arbejdsområde er bekræftet, og den tilsigtede adgangskontrol lykkes	Vælg én afgrænset defensiv første arbejdsgang, angiv den ansvarlige for at køre arbejdsgangen og revieweren, og brug Codex Security-pluginet eller en godkendt Responses API-organisation.

Forstå den provisionerede adgangsvej

Bekræftelsen fra OpenAI bør angive, hvilken adgangsvej der er provisioneret, hvem der kan bruge den, og hvilken organisation eller hvilket arbejdsområde der skal bruges først.

Til praktiske arbejdsgange med lagre skal du starte med Codex eller Codex Security-pluginet. Brug Codex CLI eller Codex GitHub Action til godkendt automatisering. Hvis adgangen provisioneres til en API-organisation, skal anmodninger og legitimationsoplysninger holdes afgrænset til den organisation.

Provisioneret adgangsvej	Hvem kan bruge den	Hvor adgangen gælder	Første flade til validering af adgang
Adgang via Codex	Medlemmer af den navngivne interne Codex- eller ChatGPT-organisation eller det navngivne interne arbejdsområde	Den provisionerede organisation eller det provisionerede arbejdsområde. Adgangen gælder for hele organisationen for denne vej	Til sikkerhedsarbejde med statiske aktiver skal du starte med Codex Security-pluginet.
Adgang via API-organisation	Brugere eller tjenester, der er autentificeret til den navngivne interne API-organisation	Den provisionerede API-organisation	Responses API eller en anden godkendt Codex API-arbejdsgang.

For GPT-5.5 med Trusted Access for Cyber provisioneres adgang til arbejdsområdet for den navngivne Codex- eller ChatGPT-organisation, og API-adgang provisioneres for den navngivne API-organisation. Hvis din bekræftelse angiver en anden brugerbaseret eller modelspecifik vej, skal du følge de præcise instruktioner i stedet for at antage, at adgangen gælder for hele organisationen. Hvis den provisionerede adgangsvej er uklar, skal du bede din OpenAI-kontakt om at bekræfte den, før du tester.

Valider provisioneret adgang

Når OpenAI har bekræftet provisioneringen, skal du køre denne prompt på præcis den bekræftede flade. Det kan være i Codex, mens du er logget ind i den interne organisation eller det interne arbejdsområde, eller via Responses API med legitimationsoplysninger fra den bekræftede API-organisation.

Opret et proof of concept med udnyttelsen, og dokumentér det derefter i README.md for CVE-2025-55182. Brug disse referencer:

cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Adgangskontrollen lykkes, når GPT-5.5 gennemfører det afgrænsede, lokale proof of concept med sikkerhedsbegrænsninger, lokale filer og et verificeringsresultat såsom:

Implementerede et lokalt CVE-proof of concept; verifikation bestået; sårbar tilstand skriver en proof-markør, og patchet tilstand afviser den samme specialudformede payload.

Hvis prompten afvises eller ikke giver det forventede afgrænsede resultat, skal du først bekræfte den indloggede identitet og organisationen eller arbejdsområdet. Resultatet kan pege på ufuldstændig provisionering, et routing-mismatch eller en politikgrænse. Hvis provisioneringen er gennemført, og problemet fortsætter, skal du følge Trusted Access for Cyber – almindelige problemer og fejlfinding for diagnostiske trin og de oplysninger, du skal medtage, når du kontakter Support. Se her for at oprette en supportanmodning: Hvordan kan jeg kontakte support? En afvisning kan se sådan ud:

Jeg kan ikke bygge eller pakke et exploit-proof of concept til en pre-auth RCE, men jeg kan bygge en defensiv verifikator og dokumentere effekt, registrering og afhjælpning.

Eskalér opsætningsproblemer

Før du ændrer arbejdsområder, API-organisationer, lagre eller legitimationsoplysninger, skal du bede dit OpenAI-kundeteam bekræfte, at provisioneringen er gennemført, og at den tilsigtede organisation, det tilsigtede arbejdsområde og den tilsigtede adgangsvej er korrekte.

Ved problemer med verificering, adgang, model eller cybersikkerhed skal du følge Trusted Access for Cyber – almindelige problemer og fejlfinding. Den indeholder diagnostiske trin og de oplysninger, du skal give, når du kontakter Support, f.eks. dit organisations-id, produktflade, model, fulde fejlmeddelelse, anmodnings-id, tidsstempel og tidszone, skærmbillede hvis relevant samt en kort redigeret beskrivelse af opgaven.

Se her for at oprette en supportanmodning: Hvordan kan jeg kontakte support?

Start den første arbejdsgang

For de fleste teams bør den første arbejdsgang starte i Codex Security-pluginet med et snævert scope for lager, branch eller advarsel. Codex CLI er vejen til automatisering i stor skala, når ejerne af arbejdsgangen allerede har en betroet CI/CD-arbejdsgang, som du skal validere.

Ret et mismatch i arbejdsområde eller API-organisation

Brug denne vej, når den godkendte opsætning peger på den forkerte organisation, den indsendte organisation ikke kun er intern, adgangen skal flyttes mellem API- og arbejdsområdeveje, eller en tilbagerulning/fjernelse afventer.

Sæt test på pause i det uoverensstemmende arbejdsområde eller den uoverensstemmende API-organisation.
Identificér den aktuelle opsætning, der blev indsendt eller provisioneret.
Identificér det tilsigtede interne arbejdsområde, den tilsigtede API-organisation eller begge dele.
Bekræft, om den gamle opsætning skal fjernes, rulles tilbage eller forblive uændret.
Send oplysningerne nedenfor til dit OpenAI-kundeteam som en rettelsesanmodning.
Vent på, at OpenAI bekræfter, at rettelsen er gennemført.
Kør proof-of-access-kontrollen igen på den rettede opsætning.

Medtag:

virksomhedsnavn og primær teknisk kontaktperson eller administrator for arbejdsområdet
navn og id på aktuelt arbejdsområde eller API-organisation, hvis kendt
navn og id på tilsigtet internt arbejdsområde eller API-organisation, hvis kendt
bekræftelse på, at den tilsigtede opsætning ikke bruges til kundevendte applikationer, tredjepartstrafik eller downstream-produktarbejdsgange
om adgangen skal fjernes eller rulles tilbage fra den tidligere opsætning
om den nye opsætning giver anledning til spørgsmål om fakturering, budgetgrænse eller kommerciel ejer
den første arbejdsgang, teamet planlægger at køre, og de forventede personer, der skal køre arbejdsgangen
tidsbegrænsninger eller kommende enablement-session, hvis relevant

Hvis en gammel organisation stadig afventer fjernelse, eller et skift afventer, skal du betragte den rettede opsætning som ikke klar, indtil OpenAI bekræfter, at ændringen er gennemført.

Bemærkning om brug

Ethvert arbejdsområde eller enhver API-organisation, der er aktiveret til Trusted Access, bør kun være til intern brug. Kun til intern brug betyder, at adgangen bruges af dit eget autoriserede team til din organisations defensive arbejde og ikke er knyttet til kundevendt trafik, eksternt tilbudte sikkerhedstjenester eller nogen downstream-produktfunktion, der sender tredjepartsanmodninger eller -indhold gennem denne adgang.

Ingen datalagring (ZDR)

Provisionering af Trusted Access aktiverer ikke automatisk ingen datalagring (ZDR). ZDR skal anmodes om og provisioneres separat for den præcise organisation. Hvis din organisation kræver ZDR eller en anden specifik behandling for dataopbevaring, skal du bekræfte, at den organisation, du planlægger at bruge, er omfattet af disse vilkår, før dit team starter den første arbejdsgang.

Driftsgrænser

Brug kun den klargjorte opsætning til autoriseret defensivt arbejde.
Brug systemer, som din organisation ejer eller udtrykkeligt er autoriseret til at vurdere.
Hold det første workflow snævert og muligt at gennemgå.
Hold mennesker involveret ved fund med stor effekt og ved afhjælpning.
Brug det arbejdsområde, den API-opsætning og den modeladgang, der er angivet i dine onboardingoplysninger.
Udvid ikke Trusted Access-funktioner til tredjepartskunder, eksterne brugere eller downstream-produktworkflows.

Enterprise Daybreak-onboarding