Як пройти корпоративне підключення до Trusted Access, перевірити наданий доступ, виправити проблеми з організацією чи робочим простором і підготуватися до першого робочого процесу.

Огляд

Скористайтеся цим посібником, якщо ви координуєте підключення Daybreak у своїй організації та маєте пройти шлях від подання заявки й перевірки відповідності вимогам до готового до роботи середовища.

Daybreak Access — це програма OpenAI «Довірений доступ для кібербезпеки». Daybreak Blue і Daybreak Red — це рівні доступу. Програма охоплює моделі, способи доступу, Codex, Codex Security і допоміжні сервіси.

Більшості корпоративних команд варто почати з Daybreak Blue для схвалених внутрішніх захисних процесів. Daybreak Blue використовує псевдонім API gpt-daybreak-blue, зіставлений з ідентифікатором моделі gpt-5.6-sol.

Daybreak Red використовує псевдонім API gpt-daybreak-red, зіставлений з ідентифікатором моделі gpt-5.6-cyber. Для Daybreak Red потрібна окрема відповідність вимогам; доступ може охоплювати лише спеціалізовані моделі, схвалені для організації.

Клієнтам, які вже мають схвалення на GPT-5.5 із програмою «Довірений доступ для кібербезпеки», слід і надалі дотримуватися затверджених інструкцій щодо доступу.

Відповідність вашої організації вимогам визначає, які елементи керування Daybreak можуть відображатися на Платформі API. Коли елементи керування проєктом доступні, адміністратор організації відкриває «Параметри проєкту → Ліміти», вмикає Daybreak для відповідного внутрішнього проєкту API, а потім — конкретну доступну модель. Параметри проєкту визначають доступність API для вибраного проєкту. Під час міграції деякі чинні правила програми «Довірений доступ» на рівні організації можуть і надалі діяти. Точні межі доступу наведено в підтвердженні підключення. Ці параметри стосуються проєктів API. Для доступу до Codex або ChatGPT виконайте окремі інструкції з підтвердження підключення.

Після ввімкнення доступу деякі процеси з підвищеним ризиком усе одно можуть бути відхилені, тому починайте з обмеженого захисного процесу саме в тому інтерфейсі, проєкті й моделі, які планує використовувати команда.

Відстеження стану підключення та доступу

Етап	Опис	Подальші дії
Надішліть вступну форму	Ваша організація заповнила корпоративну вступну форму Daybreak.	Очікуйте листа від Persona й переконайтеся, що його отримала належна контактна особа організації. Якщо ваша організація вже має схвалений Довірений доступ, а представник OpenAI повідомив, що нову вступну форму подавати не потрібно, дотримуйтеся його інструкцій і не створюйте повторний запит.
Пройдіть перевірку KYB	Persona надсилає лист контактній особі, зазначеній у вступній формі, щоб вона пройшла перевірку бізнесу Know Your Business (KYB).	Виконайте запит Persona. Після цього OpenAI проводить внутрішні перевірки відповідності вимогам і придатності.
Отримайте рішення щодо відповідності вимогам	OpenAI підтверджує схвалений спосіб доступу й повідомляє, чи відповідає ваша організація вимогам Daybreak Blue, Daybreak Red або обох рівнів. Для Daybreak Red потрібна окрема відповідність вимогам.	Підтвердьте схвалених користувачів, організацію або робочий простір, організацію API, моделі та інтерфейси продуктів. Не вважайте, що відповідність вимогам Blue автоматично надає відповідність вимогам Red.
Увімкніть Daybreak для проєкту API	Коли елементи керування проєктом стають доступними відповідній організації API, адміністратор організації відкриває «Параметри проєкту → Ліміти», вмикає Daybreak для внутрішнього проєкту, а потім — конкретну доступну модель. Лише адміністратори організації можуть переглядати або змінювати ці параметри.	Увімкніть Daybreak лише для відповідного проєкту, а потім — лише конкретну доступну модель, потрібну цьому проєкту.
Оновіть облікові дані проєкту	Наявний ключ API або інші облікові дані можуть не враховувати щойно ввімкнений доступ.	Після ввімкнення створіть новий ключ API для проєкту або оновіть облікові дані проєкту, які використовує сервіс. Обмежте дію облікових даних увімкненим внутрішнім проєктом.
Перевірте доступ і запустіть обмежений захисний процес	Потрібний спосіб доступу, проєкт, модель і нові облікові дані готові до перевірки доступу.	Виконайте наведену нижче перевірку доступу в схваленому інтерфейсі. Перед запуском першого процесу призначте його виконавця та рецензента.

Ознайомлення зі схваленим способом доступу

У підтвердженні підключення мають бути зазначені схвалені моделі, хто може ними користуватися, а також які організацію, робочий простір, організацію API та проєкт API слід використовувати спочатку.

Для практичної роботи з репозиторіями почніть із Codex або плагіна Codex Security. Для схваленої автоматизації використовуйте Codex CLI або Codex GitHub Action. У процесах API обмежуйте запити й облікові дані схваленим внутрішнім проєктом.

Схвалений спосіб доступу	Хто може користуватися	Де використовувати	Рекомендований перший інтерфейс
Доступ через Codex	Схвалені учасники зазначеної внутрішньої організації чи робочого простору Codex або ChatGPT	Організація або робочий простір, зазначені в підтвердженні підключення	Для перевірки безпеки статичних ресурсів почніть із плагіна Codex Security.
Доступ через проєкт API	Адміністратори організації вмикають Daybreak для відповідного проєкту, а потім — конкретну доступну модель. Користувачі або сервіси, автентифіковані за допомогою нових облікових даних цього проєкту, можуть використовувати ввімкнену для нього модель.	Увімкнений внутрішній проєкт у відповідній організації API	Responses API або інший схвалений процес Codex API.

Використовуйте ці точні зіставлення API:

Рівень доступу Daybreak	Псевдонім API	Ідентифікатор моделі	Відповідність вимогам
Daybreak Blue	`gpt-daybreak-blue`	`gpt-5.6-sol`	Потрібна відповідність вимогам Daybreak Blue.
Daybreak Red	`gpt-daybreak-red`	`gpt-5.6-cyber`	Потрібна окрема відповідність вимогам Daybreak Red.

Коли елементи керування проєктом доступні, адміністратор організації відкриває «Параметри проєкту → Ліміти», вмикає Daybreak для відповідного проєкту, а потім — конкретну доступну модель. Лише адміністратори організації можуть переглядати або змінювати ці параметри.

Параметри проєкту визначають доступність API для вибраного проєкту. Під час міграції деякі чинні правила програми «Довірений доступ» на рівні організації можуть і надалі діяти. Точні межі доступу наведено в підтвердженні підключення. Якщо елементи керування відсутні або для схваленого налаштування все ще потрібна окрема організація 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 для відповідного проєкту в розділі «Параметри проєкту → Ліміти», а потім — конкретну доступну модель.
Для доступу через API: запит використовує новий ключ API або оновлені облікові дані з увімкненого проєкту.
Точне зіставлення API: gpt-daybreak-blue або gpt-5.6-sol для Blue та gpt-daybreak-red або gpt-5.6-cyber для окремо схваленого доступу Red.

Відмова або неочікуваний результат можуть свідчити про невідповідність вимогам чи помилку налаштування, застарілі облікові дані, неправильне зіставлення моделі або обмеження політики. Саме по собі це не підтверджує відсутність доступу.

Діагностичні дії та перелік відомостей для звернення до служби підтримки наведено в статті «Довірений доступ для кібербезпеки: поширені проблеми та їх усунення». Щоб створити запит до служби підтримки, перегляньте статтю «Як зв’язатися зі службою підтримки?». Відмова може мати такий вигляд:

Я не можу створити або упакувати PoC експлойта для 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