Огляд
Скористайтеся цим посібником, якщо ви координуєте онбординг 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 або конфігурації моделі. | Доведіть, що доступ активний саме на цьому інтерфейсі, до першого процесу. |
| Готово до запуску | Шлях доступу підтверджено, виправлення налаштування завершено, і ваша команда має видимі докази в UI або API. | Виберіть один обмежений перший захисний процес, визначте виконавця й рецензента процесу та використовуйте плагін Codex Security або Responses API через схвалений робочий простір для наявного тестового стенда. |
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.Якщо доступ не надано, модель може відмовитися реалізувати експлойт і перенаправити до захисних матеріалів, наприклад:
Я не можу створити або упакувати PoC експлойта для RCE до автентифікації, але можу створити захисний засіб перевірки й задокументувати вплив, виявлення та усунення.4. Ескалуйте проблеми з налаштуванням
Якщо виникнуть проблеми з налаштуванням, перед зміною робочих просторів або API-організацій, повторним підключенням репозиторіїв чи переналаштуванням доступу надішліть своєму представнику OpenAI стислий пакет підтримки. Додайте тип проблеми, використаний інтерфейс, робочий простір або API-організацію, email користувача, що ввійшов, або власника облікових даних API, назву репозиторію чи артефакту, ID сканування або ID запуску тестового стенда, якщо застосовно, назву моделі, мітку часу, ID запиту за наявності та точну помилку, відмову або відсутній стан UI.
| Тип проблеми | Що зафіксувати | Де це взяти |
|---|---|---|
| Доступ до робочого простору | Назва або ID робочого простору, email постраждалих учасників команди, очікувана роль і помилка доступу або відсутній стан UI. | Перемикач робочого простору, меню облікового запису, подання учасника або адміністратора, а також сторінка чи модальне вікно, де з’являється помилка доступу. |
| Невідповідність робочого простору/API-організації | Поточне налаштування, заплановане налаштування лише для внутрішнього використання, чи мають бути ввімкнені Codex Security, автоматизація Codex CLI або обидва варіанти, і чи потрібні відкат або видалення. | Дані онбордингу, перемикач робочого простору, налаштування організації Platform, підтвердження команди облікового запису та пакет виправлення. |
| Початковий статус сканування | Назва репозиторію, час початку сканування, поточний статус сканування та чи репозиторій усе ще перебуває в початковому заповненні. | Сторінка сканування Codex Security, список сканувань, історія сканувань репозиторію або банер стану. |
| Доступ до API | API-організація, проєкт за наявності, власник облікових даних API, очікуване налаштування, очікуваний доступ до моделі та помилка автентифікації або маршрутизації. | Журнали тестового стенда, журнали завдань CI, журнали API-клієнта, виняток SDK, відповідь із помилкою API, метадані відповіді або заголовки відповіді. |
| Оплата або ліміти | Нова або наявна організація, комерційний власник, власник оплати, бюджетні ліміти та яке питання щодо консолідації або контролю витрат залишається. | Підтвердження команди облікового запису, сторінка оплати або лімітів Platform, записи відділу закупівель або комерційного власника. |
| Невідповідність доступу до моделі | Використаний робочий простір або API-організація, доступ до моделі, очікуваний з онбордингу, і те, що фактично бачить ваша внутрішня команда. | Модель сеансу Codex або позначка доступу, якщо видима, поле моделі в API-запиті, відповідь із помилкою API, відповідь перевірки доступу або текст відмови, журнали тестового стенда чи знімок екрана відсутньої опції або помилки доступу. |
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 на сторонніх клієнтів, зовнішніх користувачів або процеси подальших продуктів.