Общ преглед
Използвайте това ръководство, ако координирате въвеждането в Daybreak за вашата организация и трябва да преминете от одобрение към готова за работа настройка.
Daybreak е програмата на OpenAI, насочена към работа в областта на киберсигурността, включително модели, пътища за достъп, Codex, Codex Security и поддържащи услуги.
Повечето корпоративни екипи използват GPT-5.5 с Trusted Access for Cyber за одобрени вътрешни защитни работни процеси. В зависимост от вашата настройка достъпът може да бъде предоставен към работно пространство, API организация, именувана самоличност в Codex или повече от един път. Данните за въвеждането от OpenAI трябва да посочват точното работно пространство, API организацията, одобрената самоличност в Codex и достъпа до модел, които да използвате. Някои по-високорискови работни процеси може все пак да бъдат отказани дори след одобрение, затова започнете с ограничен защитен работен процес върху точната повърхност, която екипът ви планира да използва.
1. Проследете състоянието на въвеждането
Одобрението е първата стъпка във въвеждането. Считайте настройката за готова само след като одобреният път за достъп е предоставен в правилното вътрешно работно пространство или API организация и екипът ви има доказателство, че предвидената повърхност работи.
| Състояние | Какво означава | Какво да направите след това |
|---|---|---|
| Изпратено | Вашата организация е изпратила заявка или вашият екип по акаунта в OpenAI я е изпратил от ваше име. | Поддържайте предложеното работно пространство или API организация, обхвата за вътрешна употреба, техническия администратор и първия работен процес готови, в случай че OpenAI се нуждае от повече подробности. |
| Одобрено | OpenAI потвърди, че организацията е одобрена за Trusted Access for Cyber. | Потвърдете кой път за достъп е одобрен от OpenAI и кое работно пространство, API организация, одобрена самоличност в Codex или конфигурация на модел е обхваната. |
| Предоставено | OpenAI потвърди, че достъпът е приложен към именувано работно пространство, API организация, одобрена самоличност в Codex или конфигурация на модел. | Докажете, че достъпът е активен на точно тази повърхност преди първия работен процес. |
| Готово за изпълнение | Пътят за достъп е потвърден, корекциите на настройката са завършени и екипът ви има наблюдаеми доказателства от потребителския интерфейс или API. | Изберете един ограничен защитен първи работен процес, посочете изпълнителя и проверяващия на работния процес и използвайте плъгина Codex Security или Responses API чрез одобрено работно пространство за съществуващ harness. |
2. Разберете одобрения път за достъп
Данните за въвеждането от OpenAI трябва да посочват кой път за достъп е одобрен, кой може да го използва и коя повърхност за работен процес да използвате първо. За практически работни процеси най-добрата начална точка е Codex или плъгинът Codex Security. Използвайте Codex CLI или Codex GitHub Action за мащабирана автоматизация. Ако данните за въвеждането посочват одобрена API организация, третирайте я като конфигурация за този одобрен път за автоматизация.
| Одобрен път за достъп | Кой може да го използва | Къде се прилага достъпът | Първа повърхност за проверка |
|---|---|---|---|
| Достъп до работно пространство за Codex | Членове на именуваното вътрешно корпоративно работно пространство на Codex или ChatGPT. | Предоставеното работно пространство. Работно пространство на ChatGPT може да бъде контекстът за администриране, членство или вход за Codex. | За работа по сигурността на статични активи започнете с плъгина Codex Security. |
| Достъп на API организация за Codex CLI | Потребители или услуги, използващи идентификационни данни в именуваната вътрешна API организация. | Предоставената API организация или проект. | Codex CLI с удостоверяване чрез токен. |
Повечето корпоративни одобрения използват достъп до работно пространство, достъп до API организация или и двете. Някои одобрения са по-тесни: именувана самоличност в Codex не предоставя същия достъп на всеки човек в работното пространство, а API достъпът се прилага само за именуваната API организация. Ако данните за въвеждането не посочват пътя за достъп, помолете вашия контакт в OpenAI да го потвърди, преди вътрешният ви екип да започне тестване.
3. Потвърдете достъпа след одобрение
Най-добре е да валидирате доказателството за достъп върху конкретната продуктова повърхност, която екипът ви ще използва, а не чрез общо потвърждение, че организацията ви е одобрена. Най-бързият начин да валидирате достъпа е да инсталирате и изпробвате Codex Security Plugin; ако планирате да използвате Codex CLI за мащабирана автоматизация, валидирайте точно тази конфигурация за автоматизация и API организация.
| Одобрен път за достъп | Проверка | Достъпът е активен, когато | Доказателства за събиране |
|---|---|---|---|
| Достъп до работно пространство за Codex | Инсталирайте Codex Security Plugin и следвайте предложените подкани в локална инстанция на Codex. | Плъгинът Codex Security може да сканира, преглежда и коригира констатации в целевото ви хранилище. | @codexsecurity в полето за въвеждане извиква конкретни умения, като например threat-model. |
| Достъп на API организация за използване на Responses API | Изпълнете един ограничен вътрешен защитен работен процес за автоматизация. Можете да използвате тази примерна команда cURL, за да валидирате достъпа чрез 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."}' | Заявката се удостоверява в очакваната API организация, използва конфигурацията на модел от въвеждането и връща резултат, който може да се прегледа, вместо грешка за достъп или маршрутизиране. | API организация или проект, собственик на API идентификационни данни, изпратено име на модел, времеви печат, ID на заявка, ако е наличен, и HTTP 200 или успешен изход от SDK отговор. |
Незадължителна подкана за валидиране на достъпа
След като достъпът бъде предоставен, можете да валидирате, като опитате тази подкана в одобреното работно пространство или API организация само за вътрешна употреба:
Създайте доказателствена концепция с експлойта, след което документирайте в README.md за този CVE:
- 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.Ако достъпът не е предоставен, моделът може да откаже имплементация на експлойт и да пренасочи към защитни материали, например:
Не мога да изградя или пакетирам доказателствена концепция за експлойт за RCE преди удостоверяване, но мога да изградя защитен проверител и да документирам въздействието, откриването и отстраняването.4. Ескалирайте проблеми с настройката
Ако срещнете проблеми с настройката, споделете компактен пакет за поддръжка с вашия представител на OpenAI, преди да променяте работни пространства или API организации, да свързвате отново хранилища или да преконфигурирате достъпа. Включете типа проблем, използваната повърхност, работното пространство или API организацията, имейла за вход или собственика на API идентификационните данни, името на хранилището или артефакта, ID на сканиране или ID на изпълнение на harness, ако е приложимо, името на модел, времевия печат, ID на заявка, ако е наличен, и точната грешка, отказ или липсващо състояние на потребителския интерфейс.
| Тип проблем | Какво да се събере | Откъде да се вземе |
|---|---|---|
| Достъп до работно пространство | Име или ID на работното пространство, имейли на засегнатите членове на екипа, очаквана роля и грешката за достъп или липсващото състояние на потребителския интерфейс. | Селектор на работно пространство, меню на акаунта, изглед за членове или администратор и страницата или модалният прозорец, където се появява грешката за достъп. |
| Несъответствие между работно пространство/API организация | Текуща настройка, предвидена настройка само за вътрешна употреба, дали Codex Security, автоматизация с Codex CLI или и двете трябва да бъдат активирани, и дали е нужно връщане назад/премахване. | Данни за въвеждането, селектор на работно пространство, настройки на Platform организацията, потвърждение от екипа по акаунта и пакет за корекция. |
| Състояние на първоначално сканиране | Име на хранилище, начален час на сканирането, текущо състояние на сканирането и дали хранилището все още е в първоначално обратно попълване. | Страница за сканиране на Codex Security, списък със сканирания, история на сканиранията на хранилището или банер за състояние. |
| API достъп | API организация, проект, ако е приложимо, собственик на API идентификационни данни, очаквана настройка, очакван достъп до модел и грешката при удостоверяване или маршрутизиране. | Регистри на harness, регистри на CI задача, регистри на API клиент, SDK изключение, API отговор за грешка, метаданни на отговора или заглавки на отговора. |
| Таксуване или лимити | Нова или съществуваща организация, търговски собственик, собственик на таксуването, бюджетни лимити и какъв въпрос относно консолидация или контрол на разходите остава. | Потвърждение от екипа по акаунта, страница за таксуване или лимити в Platform, записи на снабдяването или търговския собственик. |
| Несъответствие в достъпа до модел | Използваното работно пространство или API организация, достъпът до модел, очакван от въвеждането, и какво действително вижда вътрешният ви екип. | Модел на сесия в Codex или етикет за достъп, ако е видим, поле за модел в API заявка, API отговор за грешка, отговор за валидиране на достъпа или текст на отказ, регистри на harness или екранна снимка на липсващата опция или грешката за достъп. |
5. Стартирайте първия работен процес
За повечето екипи първият работен процес трябва да започне в плъгина Codex Security с тесен обхват на хранилище, клон или предупреждение. Codex CLI е пътят за мащабирана автоматизация, когато собствениците на работния процес вече имат доверен CI/CD работен процес, който трябва да валидирате.
Коригирайте несъответствие между работно пространство или API организация
Използвайте този път, когато одобрената настройка сочи към грешна организация, изпратената организация не е само за вътрешна употреба, достъпът трябва да се премести между API и работно пространство или предстои връщане назад/премахване.
Поставете на пауза тестването в несъответстващото работно пространство или API организация.
Идентифицирайте текущата настройка, която е изпратена или предоставена.
Идентифицирайте предвиденото работно пространство, API организация или и двете, само за вътрешна употреба.
Потвърдете дали старата настройка трябва да бъде премахната, върната назад или оставена без промяна.
Изпратете на OpenAI компактен пакет за корекция.
Изчакайте OpenAI да потвърди, че корекцията е завършена.
Изпълнете отново проверката за доказателство за достъп върху коригираната настройка.
Пакетът за корекция трябва да включва:
име на компанията и основен технически контакт или контакт на администратор на работно пространство
текущо име и ID на работно пространство или API организация, ако са известни
предвидено име и ID на работно пространство или API организация само за вътрешна употреба, ако са известни
потвърждение, че предвидената настройка не се използва за приложения, насочени към клиенти, трафик от трети страни или работни процеси на продукти надолу по веригата
дали достъпът трябва да бъде премахнат или върнат назад от предишната настройка
дали новата настройка създава въпрос, свързан с таксуване, бюджетен лимит или търговски собственик
първия работен процес, който екипът планира да изпълни, и очакваните изпълнители на работния процес
времеви ограничения или предстояща сесия за активиране, ако има такива
Ако стара организация все още чака премахване или предстои размяна, считайте коригираната настройка за неготова, докато OpenAI не потвърди, че промяната е завършена.
Бележка за използването
Всяко работно пространство или API организация с активиран Trusted Access трябва да бъде само за вътрешна употреба. „Само за вътрешна употреба“ означава, че достъпът се използва от вашия собствен упълномощен екип за защитната работа на организацията ви и не е свързан с трафик към клиенти, външно предлагани услуги за сигурност или функция на продукт надолу по веригата, която пропуска заявки или съдържание на трети страни през този достъп.
Нулево задържане на данни (ZDR)
Нулево задържане на данни (ZDR) може да се поддържа само ако вашата организация вече има необходимия път за одобрение на ZDR или завърши отделния процес за одобрение на ZDR. Ако вашата организация изисква ZDR или друго конкретно третиране на задържането на данни, потвърдете, че точното работно пространство или API организация, които планирате да използвате, са обхванати от тези условия, преди екипът ви да започне първия работен процес.
Оперативни граници
Използвайте предоставената настройка само за упълномощена защитна работа.
Използвайте системи, които вашата организация притежава или за които има изрично разрешение да оценява.
Поддържайте първия работен процес тесен и удобен за преглед.
Дръжте хората в процеса при констатации с голямо въздействие и при отстраняване на проблеми.
Използвайте работното пространство, API настройката и достъпа до модел, посочени в данните за въвеждането ви.
Не разширявайте възможностите на Trusted Access към клиенти трети страни, външни потребители или работни процеси на продукти надолу по веригата.