Как да завършите корпоративното въвеждане за Trusted Access, да валидирате предоставения достъп, да коригирате проблеми с организацията или работното пространство и да се подготвите за първия работен процес.

Общ преглед

Използвайте това ръководство, ако координирате въвеждането в Daybreak за организацията си и трябва да преминете от събирането на информация и проверката за допустимост към готова за използване конфигурация.

Daybreak Access е програмата на OpenAI „Доверен достъп за киберсигурност“. Daybreak Blue и Daybreak Red са нива на достъп. Програмата включва модели, начини за достъп, Codex, Codex Security и помощни услуги.

Повечето корпоративни екипи трябва да започнат с Daybreak Blue за одобрени вътрешни защитни работни процеси. Daybreak Blue използва API псевдонима gpt-daybreak-blue-latest, който съответства на идентификатора на модел gpt-5.6-sol.

Daybreak Red използва API псевдонима gpt-daybreak-red-latest, който съответства на идентификатора на модел gpt-5.6-cyber. Daybreak Red изисква отделно одобрение за допустимост и може да включва само специализираните модели, одобрени за организацията.

Клиентите, които вече са одобрени за GPT-5.5 с „Доверен достъп за киберсигурност“, трябва да продължат да следват одобрените си инструкции за достъп.

Допустимостта на организацията ви определя кои контроли на Daybreak могат да се показват в API платформата. За API достъп до Daybreak Blue администратор на организацията отваря Настройки на проекта за съответния проект, намира Daybreak Blue и го включва. Достъпът е отделен за всеки проект: включването или изключването на Daybreak Blue за един проект не засяга останалите проекти. Само администраторите на организацията могат да виждат или променят превключвателя. За Daybreak Red, предишната версия на „Доверен достъп“ или друг одобрен начин за достъп следвайте потвърждението за въвеждане относно точните инструкции за контролите на проекта и границите на достъпа. Тези настройки се отнасят за API проекти. За достъп до Codex или ChatGPT следвайте отделните инструкции в потвърждението за въвеждане.

Някои работни процеси с по-висок риск може да бъдат отказани дори след активиране на достъпа, затова започнете с ограничен защитен работен процес точно в средата, проекта и модела, които екипът ви планира да използва.

Проследявайте състоянието на въвеждането и достъпа

Етап	Описание	Какво следва
Подайте формуляра за първоначални данни	Организацията ви е попълнила корпоративния формуляр за първоначални данни за Daybreak.	Очаквайте имейл от Persona и се уверете, че достига до правилното лице за контакт в организацията. Ако организацията ви вече има одобрен „Доверен достъп“ и лицето ви за контакт в OpenAI каже, че не е необходимо ново подаване на данни, следвайте указанията му, вместо да подавате дублираща заявка.
Завършете проверката KYB	Persona изпраща имейл до посоченото във формуляра лице за контакт, за да бъде извършена проверка „Опознайте бизнеса си“ (KYB).	Изпълнете заявката от Persona. След това OpenAI извършва вътрешни проверки за допустимост и пригодност.
Получете решение за допустимост	OpenAI потвърждава одобрения начин за достъп и дали организацията ви отговаря на условията за Daybreak Blue, Daybreak Red или и двете. Daybreak Red изисква отделно одобрение.	Потвърдете одобрените потребители, организацията или работното пространство, API организацията, моделите и продуктовите интерфейси. Не приемайте, че допустимостта за Red следва от допустимостта за Blue.
Активирайте Daybreak за API проект	Когато контролите за проекта са налични за допустимата API организация, администратор на организацията отваря „Настройки на проекта“ → „Ограничения“, активира Daybreak за проекта само за вътрешно ползване и след това активира конкретния допустим модел. Само администраторите на организацията могат да виждат или променят тези настройки.	Активирайте Daybreak само за допустимия проект, а след това активирайте само конкретния допустим модел, необходим за него.
Обновете идентификационните данни за проекта	Съществуващ API ключ или други идентификационни данни може да не отразяват новоактивирания достъп.	След активирането създайте нов API ключ за проекта или обновете идентификационните данни за проекта, използвани от услугата. Ограничете обхвата на идентификационните данни до активирания проект само за вътрешно ползване.
Проверете достъпа и започнете ограничен защитен работен процес	Предвиденият начин за достъп, проектът, моделът и новите идентификационни данни са готови за проверка на достъпа.	Изпълнете проверката за доказване на достъп по-долу през одобрения интерфейс. Преди да започнете първия работен процес, определете кой ще го изпълнява и кой ще го преглежда.

Разберете одобрения начин за достъп

В потвърждението за въвеждане трябва да са посочени одобрените модели, кой може да ги използва и кои организация, работно пространство, API организация и API проект да използвате първо.

За практически работни процеси с хранилища започнете с Codex или плъгина Codex Security. Използвайте Codex CLI или Codex GitHub Action за одобрена автоматизация. За API работни процеси ограничете заявките и идентификационните данни до одобрения проект само за вътрешна употреба.

Ако одобреният ви достъп използва удостоверяване с API ключ в Codex CLI за Daybreak Blue, изпълнете codex -m gpt-daybreak-blue-latest.

Одобрен начин за достъп	Кой може да го използва	Къде да се използва	Препоръчителна начална среда
Достъп чрез Codex	Одобрени членове на посочената вътрешна организация или работно пространство в Codex или ChatGPT	Организацията или работното пространство, посочени в потвърждението за въвеждане	За работа по сигурността на статични ресурси започнете с плъгина Codex Security.
Достъп чрез API проект	За Daybreak Blue администратор на организацията включва Daybreak Blue за съответния проект. Потребители или услуги, удостоверени с нови идентификационни данни от този проект, могат да използват одобрения модел. За друг начин за достъп следвайте потвърждението за въвеждане.	Активираният проект само за вътрешна употреба в допустимата API организация	Responses API или друг одобрен API работен процес на Codex.

Използвайте точно следните API съответствия:

Ниво на достъп до Daybreak	API псевдоним	Идентификатор на модела	Допустимост
Daybreak Blue	`gpt-daybreak-blue-latest`	`gpt-5.6-sol`	Изисква допустимост за Daybreak Blue.
Daybreak Red	`gpt-daybreak-red-latest`	`gpt-5.6-cyber`	Изисква отделна допустимост за Daybreak Red.

За API достъп до Daybreak Blue администратор на организацията отваря Настройки на проекта за съответния проект, намира Daybreak Blue и го включва. Достъпът е отделен за всеки проект: включването или изключването на Daybreak Blue за един проект не засяга останалите проекти. Само администраторите на организацията могат да виждат или променят превключвателя.

За Daybreak Blue настройката се отнася само за избрания проект. За Daybreak Red, предишната версия на „Доверен достъп“ или друг одобрен начин за достъп следвайте потвърждението за въвеждане относно точната граница на достъпа. Ако контролите не са налични или одобрената ви конфигурация все още изисква специална API организация, преди тестване следвайте точно инструкциите от лицето си за контакт в OpenAI. Не приемайте, че контролите на API проекта променят достъпа до Codex или ChatGPT.

За Daybreak Blue и съществуващия GPT-5.5 с „Доверен достъп за киберсигурност“ достъпът до работното пространство се отнася за посочената организация в Codex или ChatGPT, а API достъпът — за посочената API организация и активирания проект, както е определено в одобрението. Daybreak Red изисква отделна допустимост и може да има допълнителни изисквания за конкретния модел или потребител. Следвайте точните инструкции в одобрението относно организацията, потребителя, проекта, модела и продуктовата среда.

Проверете одобрения достъп

Проверете достъпа точно през одобрения интерфейс:

API: Администратор на организацията трябва първо да отвори „Настройки на проекта“ → „Ограничения“, да активира Daybreak за допустимия проект само за вътрешно ползване и след това да активира конкретния допустим модел. След активирането създайте нов API ключ за този проект или обновете идентификационните данни за проекта, използвани от услугата ви. Изпълнете подканата по-долу чрез одобрения API работен процес, като използвате съответния API псевдоним или идентификатор на модел.
Codex или ChatGPT: Влезте точно в посочената в потвърждението ви вътрешна организация или работно пространство и следвайте указанията в него за модела и потребителите.

Ако контролите за API проекта не се виждат, не приемайте, че достъпът е активиран. Преди тестване потвърдете с лицето си за контакт в OpenAI допустимостта на организацията и текущата наличност на контролите.

Създайте доказателствена концепция с експлойта, след което я документирайте в README.md за CVE-2025-55182. Използвайте тези референции:

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

Проверката на достъпа е успешна, когато GPT-5.5 завърши ограничената локална доказателствена концепция с ограничения за безопасност, локални файлове и резултат от проверка, например:

Имплементирана е локална доказателствена концепция за CVE; проверката премина успешно; уязвимият режим записва маркер за доказателство, а коригираният режим отхвърля същия специално създаден payload.

Ако подканата бъде отказана или не даде очаквания ограничен резултат, първо потвърдете всичко изброено по-долу:

Самоличността на влезлия потребител и точната организация, работно пространство или API проект.
Допустимостта на организацията за заявеното ниво на достъп до Daybreak.
За API достъп до Daybreak Blue — че администратор на организацията е включил Daybreak Blue в Настройки на проекта за съответния проект. За друг одобрен начин за достъп следвайте потвърждението за въвеждане.
За API достъп — че заявката използва нов API ключ или обновени идентификационни данни от активирания проект.
Точното API съответствие: gpt-daybreak-blue-latest или gpt-5.6-sol за Blue и gpt-daybreak-red-latest или gpt-5.6-cyber за отделно одобрен достъп до Red.

Отказ или неочакван резултат може да е признак за несъответствие в допустимостта или конфигурацията, остарели идентификационни данни, неправилно съответствие на модела или ограничение на правилата. Само по себе си това не потвърждава, че липсва достъп.

Следвайте „Доверен достъп за киберсигурност“ — често срещани проблеми и отстраняването им за диагностичните стъпки и данните, които да включите, когато се свързвате с екипа за поддръжка. За да изпратите заявка до екипа за поддръжка, вижте Как мога да се свържа с екипа за поддръжка? Отказът може да изглежда така:

Не мога да изградя или пакетирам доказателствена концепция за експлойт за RCE преди удостоверяване, но мога да изградя защитен проверител и да документирам въздействието, откриването и отстраняването.

Ескалирайте проблемите с конфигурацията

Преди да променяте организации, работни пространства, API проекти, хранилища или идентификационни данни, проверете конфигурацията в следния ред:

Потвърдете одобрения начин за достъп на организацията и допустимостта ѝ за заявеното ниво на достъп до Daybreak.
За API достъп помолете администратор на организацията да потвърди, че Daybreak е активиран за допустимия проект в „Настройки на проекта“ → „Ограничения“ и че конкретният допустим модел също е активиран.
Потвърдете, че заявката използва нов API ключ или обновени идентификационни данни за проекта, създадени след активирането.
Потвърдете точния псевдоним или идентификатор на модел и предвидения API проект.

Ако очаквана настройка за Daybreak или модела не се вижда, допустимостта на организацията изглежда неправилна или контролите за проекта не са налични, помолете екипа на OpenAI за профила ви да потвърди допустимостта и одобрения начин за достъп, преди да преместите натоварването към друга организация или проект.

При проблеми с проверката, достъпа, модела или киберсигурността следвайте „Доверен достъп за киберсигурност — често срещани проблеми и отстраняването им“. Включете идентификатора на организацията, идентификатора на проекта, когато е приложимо, продуктовия интерфейс, нивото на достъп до Daybreak, API псевдонима или идентификатора на модел, състоянието на настройките за проекта и модела на Daybreak, дали администратор на организацията е проверил настройката, дали идентификационните данни са създадени или обновени след активирането, пълното съобщение за грешка, идентификатора на заявката, датата и часа с часовата зона, екранна снимка, когато е приложимо, и кратко редактирано описание на задачата без чувствителни данни.

За да подадете заявка до поддръжката, вижте „Как мога да се свържа с поддръжката?“.

Започнете първия работен процес

За повечето екипи първият работен процес трябва да започне в приставката Codex Security с тесен обхват на хранилището, клона или предупрежденията. Codex CLI е пътят към мащабирана автоматизация, когато отговорниците за процеса вече разполагат с надежден CI/CD работен процес, който трябва да проверят. За API работен процес използвайте одобрения проект само за вътрешно ползване, допустимото ниво на достъп до Daybreak и нови идентификационни данни за проекта.

Коригирайте несъответствие в работното пространство, API организацията или проекта

Използвайте тази процедура, когато одобрената конфигурация сочи към грешна организация, работно пространство или API проект; предвиденият проект не е само за вътрешно ползване; липсва очакваната контрола за допустимост; активирани са неправилно ниво на достъп до Daybreak или модел; използват се остарели или предназначени за друг проект идентификационни данни; достъпът трябва да се премести между API и работно пространство; или предстои връщане към предишно състояние или премахване.

Спрете тестването в несъответстващото работно пространство, API организация или проект.
Определете текущата и предвидената конфигурация само за вътрешно ползване.
За API достъп помолете администратор на организацията да отвори страницата „Настройки на проекта“ → „Ограничения“ за предвидения проект и да провери дали Daybreak и конкретният допустим модел са налични.
Ако Daybreak е наличен, но деактивиран, помолете администратора на организацията да го активира за проекта, а след това да активира конкретния допустим модел.
След активирането създайте нов API ключ за този проект или обновете идентификационните данни за проекта, използвани от услугата.
Потвърдете дали старата конфигурация трябва да бъде премахната, върната към предишно състояние или оставена непроменена.
Ако очакваният превключвател липсва или допустимостта е неправилна, изпратете данните по-долу на екипа на OpenAI за профила ви като заявка за корекция.
Изпълнете отново проверката за доказване на достъп в коригираната конфигурация с точния одобрен псевдоним или идентификатор на модел.

Включете:

Името на компанията и основното техническо лице за контакт или администратора на организацията.
Текущите и предвидените имена и идентификатори на работното пространство, API организацията и API проекта, ако са известни.
Одобреното ниво на достъп до Daybreak и видимите настройки за Daybreak и модела в „Настройки на проекта“ → „Ограничения“.
Точния API псевдоним или идентификатор на модел, използван за теста.
Дали след активирането е създаден нов API ключ или са обновени идентификационните данни за проекта.
Потвърждение, че предвидената конфигурация не се използва за клиентски приложения, трафик на трети страни или последващи продуктови работни процеси.
Дали достъпът трябва да бъде премахнат или върнат към предишното състояние в старата конфигурация.
Дали новата конфигурация поражда въпрос относно фактурирането, бюджетния лимит или търговския отговорник.
Първия работен процес, който екипът планира да изпълни, очакваните му изпълнители и проверяващото лице.
Времеви ограничения или предстояща сесия за активиране, ако има такива.

Настройките на проекта определят наличността на API за избрания проект. По време на миграцията е възможно да се запази част от съществуващото поведение на „Доверен достъп“ на ниво организация. Следвайте потвърждението за въвеждане за точната граница на достъпа. Ако контролите не са налични или одобрената конфигурация все още изисква специална API организация, следвайте указанията на екипа на OpenAI за профила ви.

Ако премахването на стара организация или проект, замяната или корекцията на допустимостта още не са приключили, приемайте коригираната конфигурация за неготова, докато промяната не бъде потвърдена.

Бележка относно употребата

Всяко работно пространство, API организация или API проект с активиран Daybreak трябва да е само за вътрешно ползване. „Само за вътрешно ползване“ означава, че достъпът се използва от упълномощения ви собствен екип за защитната работа на организацията и не е свързан с клиентски трафик, предлагани външно услуги за сигурност или последваща продуктова функция, която предава заявки или съдържание на трети страни чрез този достъп.

Настройките на проекта определят наличността на API за избрания проект само за вътрешно ползване. По време на миграцията е възможно да се запази част от съществуващото поведение на „Доверен достъп“ на ниво организация. Следвайте потвърждението за въвеждане за точната граница на достъпа. Активирането на проект не прави допустимо използването от клиенти или трети страни.

Нулево задържане на данни (ZDR)

Допустимостта за Daybreak и активирането на проекта не активират автоматично нулево задържане на данни (ZDR). ZDR трябва да се заяви и предостави отделно за точната API организация и приложимата крайна точка. Ако организацията ви изисква ZDR или друг конкретен режим за задържане на данни, преди екипът ви да започне първия работен процес потвърдете, че трафикът от активирания проект е обхванат от тези условия. Не приемайте, че активирането на Daybreak или на конкретен модел за даден проект променя настройките за задържане на данни.

Работни ограничения

Използвайте предоставената конфигурация само за разрешена защитна работа.
Използвайте системи, които организацията ви притежава или има изрично разрешение да оценява.
Първият работен процес трябва да е тесен по обхват и лесен за преглед.
Осигурете човешки контрол при констатации и корекции със значително въздействие.
Използвайте точно посочените в данните за въвеждане организация, работно пространство, API проект, ниво на достъп до Daybreak, API псевдоним или идентификатор на модел.
Разрешавайте само на администратори на организацията да променят настройките на проекта и модела за Daybreak и не приемайте, че допустимостта за Daybreak Blue означава допустимост за Daybreak Red.
Пазете новосъздадените или обновени идентификационни данни за проекта и ограничете обхвата им до активирания проект само за вътрешно ползване.
Не предоставяйте възможностите на Daybreak на външни клиенти, външни потребители или последващи продуктови работни процеси.

Корпоративно въвеждане в Daybreak