Omówienie
Skorzystaj z tego przewodnika, jeśli koordynujesz wdrożenie Daybreak w swojej organizacji i chcesz przejść od zgłoszenia i oceny uprawnień do konfiguracji gotowej do pracy.
Daybreak Access to program OpenAI Trusted Access for Cyber. Daybreak Blue i Daybreak Red to poziomy dostępu w ramach Daybreak.
Większość zespołów w przedsiębiorstwach powinna zacząć od Daybreak Blue do zatwierdzonych wewnętrznych działań obronnych.
Daybreak Red wymaga osobnej zgody na zaawansowane, autoryzowane działania z zakresu cyberbezpieczeństwa. Niektóre pionierskie modele do cyberbezpieczeństwa wymagają dodatkowej zgody dotyczącej konkretnego modelu.
Samo uzyskanie zgody nie włącza trybu ograniczonych odmów. Ustawienia Daybreak są początkowo WYŁĄCZONE. Właściciel przestrzeni roboczej włącza dostęp dla zatwierdzonych użytkowników i grup; właściciel organizacji API włącza go dla zatwierdzonych projektów innych niż domyślne. Skonfiguruj obie ścieżki dostępu, jeśli Twój zespół korzysta z obu. Użytkownicy logujący się do Codex przez ChatGPT muszą również włączyć Daybreak przed wysłaniem żądania.
Niektóre działania o podwyższonym ryzyku nadal mogą spotkać się z odmową po włączeniu dostępu. Zacznij więc od działań obronnych o ograniczonym zakresie, w dokładnie tym interfejsie, projekcie i modelu, których Twój zespół zamierza używać.
Śledź stan wdrożenia i dostępu
| Etap | Opis | Co zrobić dalej |
|---|---|---|
| Prześlij formularz zgłoszeniowy | Twoja organizacja wypełniła formularz zgłoszeniowy Daybreak dla przedsiębiorstw. | Wypatruj wiadomości e-mail od Persona i upewnij się, że trafi do właściwej osoby kontaktowej w organizacji. Jeśli Twoja organizacja ma już zatwierdzony dostęp do Daybreak, a osoba kontaktowa w OpenAI informuje, że nowe zgłoszenie nie jest wymagane, postępuj zgodnie z jej instrukcjami zamiast składać ponowny wniosek. |
| Ukończ weryfikację KYB | Persona wysyła do osoby wskazanej w formularzu zgłoszeniowym wiadomość e-mail z prośbą o przeprowadzenie weryfikacji firmy (Know Your Business, KYB). | Wykonaj czynności wskazane w prośbie od Persona. Następnie OpenAI przeprowadza wewnętrzną ocenę spełnienia warunków i odpowiedniości udziału w programie. |
| Odbierz decyzję o przyznaniu uprawnień | OpenAI potwierdza zatwierdzoną ścieżkę dostępu oraz to, czy Twoja organizacja ma uprawnienia do Daybreak Blue, Daybreak Red, czy obu poziomów. Daybreak Red wymaga osobnych uprawnień. | Potwierdź zatwierdzonych użytkowników, przestrzeń roboczą lub organizację API, modele i interfejsy produktów. Nie zakładaj, że uprawnienia do Blue oznaczają uprawnienia do Red. Po zakończeniu udostępniania dostępu OpenAI wysyła powitalną wiadomość e-mail do administratora organizacji lub przestrzeni roboczej. |
| Skonfiguruj dostęp przez przestrzeń roboczą lub API | Na potrzeby logowania do ChatGPT i Codex właściciel przestrzeni roboczej konfiguruje role dla zatwierdzonych użytkowników i grup. Na potrzeby dostępu przez API właściciel organizacji API włącza Daybreak w każdym zatwierdzonym projekcie innym niż domyślny. Wykonaj kroki opisane poniżej w sekcji „Zweryfikuj zatwierdzony dostęp”. | Włącz tylko zatwierdzony poziom dostępu dla odpowiednich użytkowników lub projektu, zapisz ustawienia i sprawdź, czy zostały zapisane prawidłowo. W projektach domyślnych nie można włączyć Daybreak. Dostęp przez przestrzeń roboczą i dostęp przez projekt API są niezależne. |
| Użyj danych uwierzytelniających projektu docelowego | Klucz API należy do konkretnej organizacji i projektu. Klucz ze starej organizacji lub projektu nie zapewnia dostępu do środowiska docelowego. | Użyj klucza API z projektu, w którym włączono dostęp. Po migracji do innej organizacji lub projektu utwórz albo wybierz tam klucz i zaktualizuj korzystające z niego aplikacje lub procesy. Ogranicz zakres danych uwierzytelniających do zatwierdzonego użytku wewnętrznego. |
| Zweryfikuj dostęp i rozpocznij działania obronne o ograniczonym zakresie | Docelowa przestrzeń robocza lub projekt, zatwierdzeni użytkownicy, model i dane uwierzytelniające API są gotowe do sprawdzenia dostępu. | Przeprowadź opisany poniżej test potwierdzający dostęp w zatwierdzonym interfejsie. Przed rozpoczęciem pierwszego procesu wyznacz osobę, która go przeprowadzi, oraz osobę odpowiedzialną za weryfikację. |
Poznaj zatwierdzoną ścieżkę dostępu
Potwierdzenie wdrożenia powinno wskazywać zatwierdzone modele, osoby uprawnione do ich używania oraz organizację, przestrzeń roboczą, organizację API i projekt API, od których należy zacząć.
Do bezpośredniej pracy z repozytorium zacznij od Codex lub wtyczki Codex Security. Do zatwierdzonej automatyzacji używaj Codex CLI lub akcji Codex GitHub Action. W procesach korzystających z API ogranicz żądania i dane uwierzytelniające do zatwierdzonego projektu przeznaczonego wyłącznie do użytku wewnętrznego.
| Zatwierdzona ścieżka dostępu | Kto może z niej korzystać | Gdzie z niej korzystać | Zalecany interfejs na początek |
|---|---|---|---|
| Dostęp przez Codex | Uprawnieni członkowie wskazanej wewnętrznej organizacji lub przestrzeni roboczej Codex lub ChatGPT | Organizacja lub przestrzeń robocza wskazana w potwierdzeniu wdrożenia | Prace nad bezpieczeństwem zasobów statycznych zacznij od wtyczki Codex Security. |
| Dostęp przez projekt API | Właściciele organizacji API konfigurują dostępne dla niej ustawienia Daybreak. Uprawnieni użytkownicy lub usługi korzystają z klucza projektu z włączonym dostępem, w ramach zatwierdzonego zakresu tego projektu. | Projekt wyłącznie do użytku wewnętrznego z włączonym dostępem, w uprawnionej organizacji API | Responses API lub inny zatwierdzony proces korzystający z API Codex. |
Aby korzystać z API OpenAI, użyj konkretnego identyfikatora modelu objętego zatwierdzonym dostępem oraz odpowiedniego ustawienia Daybreak w żądaniu. Poniższe przykłady zależą od modeli zatwierdzonych dla Twojej organizacji.
| Poziom Daybreak | Przykładowy identyfikator modelu | Warunki dostępu |
|---|---|---|
| Daybreak Blue | gpt-6-sol | Wymaga uprawnień do Daybreak Blue. |
| Daybreak Red | gpt-5.6-cyber | Wymaga osobnej zgody na dostęp do Daybreak Red. Przykład z gpt-5.6-cyber wymaga też dodatkowej zgody na dostęp do modelu. |
W żądaniach Responses API dla gpt-6-sol ustaw access_programs.cyber na daybreak_blue, również wtedy, gdy Twoja organizacja ma zatwierdzony dostęp do Daybreak Red. Aby korzystać ze standardowych zabezpieczeń, ustaw ten parametr na standard.
W przypadku gpt-5.6-cyber używaj daybreak_red tylko wtedy, gdy Twoja organizacja ma zarówno zatwierdzony dostęp do Daybreak Red, jak i wymaganą dodatkową zgodę na dostęp do modelu.
Organizacja z zatwierdzonym dostępem do Daybreak Blue może korzystać z ustawienia Blue; organizacja z zatwierdzonym dostępem do Red może korzystać z obu ustawień. Włączenie ustawienia nie daje dostępu do modeli spoza zakresu zatwierdzonego dla Twojej organizacji.
Gdy włączone są ustawienia na poziomie projektu, zatwierdzone projekty API wyłącznie do użytku wewnętrznego mogą zastąpić osobną, dedykowaną organizację API. Przed zmianą istniejącej konfiguracji postępuj zgodnie z potwierdzeniem migracji. Na potrzeby logowania do ChatGPT i Codex skonfiguruj role w przestrzeni roboczej osobno; włączenie dostępu w projekcie API nie konfiguruje dostępu do przestrzeni roboczej.
GPT-6 Sol i GPT-6 Luna obsługują tryb z ograniczoną liczbą odmów w Daybreak Blue i Red. Astra i GPT-6.1 Sol zachowują standardowe zabezpieczenia w Blue, a w Red obsługują tryb z ograniczoną liczbą odmów. Dostępność modeli nadal zależy od Twojego konta i interfejsu produktu. Korzystaj z organizacji, kont użytkowników, projektu i modeli wskazanych w przyznanej zgodzie.
Daybreak jest też dostępny przez AWS Bedrock i nadal wymaga zgody OpenAI. Aby uzyskać dostęp, skontaktuj się z zespołem opiekującym się Twoim kontem AWS.
Sprawdź zatwierdzony dostęp
Sprawdź dostęp w konkretnym zatwierdzonym interfejsie:
API: właściciel organizacji API otwiera właściwy projekt inny niż domyślny i przechodzi do Ustawienia projektu → Ogólne → Dostęp do modeli Daybreak. Włącz zatwierdzony poziom Daybreak i zapisz zmiany. Projekty domyślne nie kwalifikują się do dostępu, a sama rola właściciela projektu nie uprawnia do wprowadzania zmian. Odczekaj do około 15 minut, a następnie wyślij bezpośrednie żądanie do Responses API, używając klucza tego projektu i zatwierdzonego identyfikatora modelu. Sam brak modelu w /models nie oznacza, że dostęp jest niedostępny.
ChatGPT i Codex z logowaniem przez ChatGPT: właściciel przestrzeni roboczej otwiera Konsola administratora → Modele → Ustawienia domyślne przestrzeni roboczej. W sekcji Cyberbezpieczeństwo wyłącz Daybreak Red, jeśli jest włączony, następnie wyłącz Blue i wybierz Zapisz zmiany. Otwórz Role i wybierz Edytuj nadpisanie dla właściwej roli lub Dodaj nadpisanie roli. W sekcji Cyberbezpieczeństwo ustaw Daybreak Blue na Włączone; włącz Red tylko wtedy, gdy zatwierdzono go dla tej przestrzeni roboczej i tych użytkowników. Wybierz Zapisz i odczekaj około 10 minut. Sprawdź role przypisane bezpośrednio i przez grupy, a następnie zaloguj się do zatwierdzonej przestrzeni roboczej i przeprowadź test z zatwierdzonym modelem. Przed testem w Codex WŁĄCZ przełącznik Daybreak; gdy jest WYŁĄCZONY, obowiązują standardowe zabezpieczenia.
Jeśli brakuje oczekiwanego ustawienia, sprawdź zatwierdzoną przestrzeń roboczą lub organizację API, uprawnienia administratora oraz to, czy zakończono udostępnianie dostępu. W przypadku dostępu przez API upewnij się, że przeglądasz projekt inny niż domyślny; w przypadku dostępu przez przestrzeń roboczą sprawdź Konsola administratora → Modele. Jeśli ustawienie nadal się nie pojawia, przed testami skontaktuj się z zespołem opiekującym się Twoim kontem OpenAI, aby potwierdzić uprawnienia i udostępnienie dostępu.
Utwórz demonstrację wykorzystania podatności (PoC) z exploitem, a następnie udokumentuj ją w README.md dla CVE-2025-55182. Skorzystaj z tych źródeł:
cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
Autoryzowany test przeprowadzony wyłącznie lokalnie może pomóc sprawdzić wybrany model i ścieżkę dostępu. Poniższy wynik to jeden z możliwych rezultatów, a nie gwarantowana odpowiedź:
Implemented a local-only CVE proof of concept; verification passed; vulnerable mode writes a proof marker and patched mode rejects the same crafted payload.
Jeśli żądanie zakończy się błędem, odmową lub nieoczekiwanym wynikiem, najpierw sprawdź wszystkie poniższe kwestie:
Tożsamość zalogowanego użytkownika oraz dokładną organizację, przestrzeń roboczą lub projekt API.
Uprawnienia organizacji do żądanego poziomu Daybreak i wszelkie dodatkowe zgody na dostęp do modelu. W przypadku Astra i GPT-6.1 Sol dostęp Blue zachowuje standardowe zabezpieczenia.
W przypadku logowania do Codex przez ChatGPT — czy właściciel przestrzeni roboczej włączył dostęp dla właściwego użytkownika i czy przełącznik Daybreak tego użytkownika jest WŁĄCZONY. Przy logowaniu za pomocą klucza API dostęp wynika z ustawień projektu API z włączonym dostępem; nie ma osobnego interfejsu Daybreak.
W przypadku dostępu przez API — czy właściciel organizacji API zapisał zatwierdzony poziom Daybreak dla właściwego projektu innego niż domyślny.
W przypadku dostępu przez API — czy żądanie używa klucza projektu z włączonym dostępem i czy wszystkie przeniesione zadania zaktualizowano tak, aby korzystały z projektu docelowego.
Dokładny identyfikator zatwierdzonego modelu — w stosownych przypadkach skorzystaj z powyższej tabeli API OpenAI.
Odmowa lub nieoczekiwany wynik mogą wskazywać na niezgodność uprawnień lub konfiguracji, nieaktualne dane uwierzytelniające, nieprawidłowe mapowanie modelu albo ograniczenie wynikające z zasad. Sam taki wynik nie potwierdza braku dostępu.
W artykule Zaufany dostęp do narzędzi cyberbezpieczeństwa — typowe problemy i ich rozwiązywanie znajdziesz kroki diagnostyczne i informacje, które należy podać przy kontakcie z pomocą techniczną. Aby wysłać zgłoszenie do pomocy technicznej, zobacz Jak skontaktować się z pomocą techniczną?. Odmowa może wyglądać tak:
I can't build or package an exploit proof of concept for a pre-auth RCE, but I can build a defensive verifier and document impact, detection, and remediation.
Zgłoś problemy z konfiguracją
Przed zmianą organizacji, przestrzeni roboczych, projektów API, repozytoriów lub danych uwierzytelniających sprawdź konfigurację w następującej kolejności:
Potwierdź zatwierdzoną ścieżkę dostępu organizacji i jej uprawnienia do żądanego poziomu Daybreak.
Potwierdź zapisane ustawienia Daybreak dla właściwych użytkowników przestrzeni roboczej lub projektu API innego niż domyślny, zgodnie z powyższą sekcją „Sprawdź zatwierdzony dostęp”.
Upewnij się, że żądanie używa klucza API należącego do projektu z włączonym dostępem.
Potwierdź dokładny identyfikator modelu i właściwy projekt API.
Jeśli oczekiwany przełącznik nie jest widoczny, uprawnienia organizacji wydają się nieprawidłowe lub ustawienia projektu są niedostępne, przed przeniesieniem zadań do innej organizacji lub projektu poproś zespół opiekujący się Twoim kontem OpenAI o potwierdzenie uprawnień i zatwierdzonej ścieżki dostępu.
W przypadku problemów z weryfikacją, dostępem, modelem lub cyberbezpieczeństwem postępuj zgodnie z artykułem OpenAI Daybreak: typowe problemy i ich rozwiązywanie. Podaj identyfikator organizacji lub przestrzeni roboczej, identyfikator projektu (jeśli dotyczy), interfejs produktu, poziom Daybreak, identyfikator modelu, zapisane ustawienia, rolę administratora, informację, czy dane uwierzytelniające należą do projektu z włączonym dostępem, pełny komunikat błędu, identyfikator żądania, znacznik czasu i strefę czasową, zrzut ekranu (jeśli dotyczy) oraz krótki opis zadania z usuniętymi danymi wrażliwymi.
Aby wysłać zgłoszenie do pomocy technicznej, zobacz Jak skontaktować się z pomocą techniczną?.
Rozpocznij pierwszy proces
Większość zespołów powinna rozpocząć pierwszy proces we wtyczce Codex Security, ograniczając zakres repozytorium, gałęzi lub alertów. Codex CLI umożliwia automatyzację na większą skalę, gdy osoby odpowiedzialne za proces mają już zaufany proces CI/CD do zweryfikowania. W procesach korzystających z API używaj zatwierdzonego projektu wyłącznie do użytku wewnętrznego, zatwierdzonego poziomu Daybreak i klucza API tego projektu.
Skoryguj niezgodność przestrzeni roboczej, organizacji API lub projektu
Skorzystaj z tej procedury, gdy zatwierdzona konfiguracja wskazuje niewłaściwą organizację, przestrzeń roboczą lub projekt API; docelowy projekt nie jest przeznaczony wyłącznie do użytku wewnętrznego; brakuje oczekiwanego ustawienia; włączony jest niewłaściwy poziom Daybreak; używane są dane uwierzytelniające innego projektu; dostęp trzeba przenieść między API a przestrzenią roboczą; albo trwa oczekiwanie na wycofanie zmian lub usunięcie dostępu.
Wstrzymaj testy w niezgodnej przestrzeni roboczej, organizacji API lub projekcie.
Ustal bieżącą konfigurację oraz docelową konfigurację przeznaczoną wyłącznie do użytku wewnętrznego.
W przypadku dostępu przez API poproś właściciela organizacji API, aby zgodnie z powyższymi krokami sprawdził dostępne ustawienia Daybreak dla właściwego projektu innego niż domyślny.
Jeśli zatwierdzony przełącznik API jest widoczny, ale wyłączony, poproś właściciela organizacji API o jego włączenie i zapisanie zmian. W przypadku dostępu przez przestrzeń roboczą poproś jej właściciela o sprawdzenie ról przypisanych właściwemu użytkownikowi bezpośrednio i przez grupy oraz zapisanych uprawnień do modeli. Przed ponownym testem w Codex z logowaniem przez ChatGPT upewnij się, że przełącznik Daybreak użytkownika jest WŁĄCZONY.
W przypadku dostępu przez API użyj klucza docelowego projektu z włączonym dostępem i odczekaj do około 15 minut na zastosowanie zmian. Przed ponownym testem odczekaj około 10 minut na zastosowanie zmian w przestrzeni roboczej.
Potwierdź, czy starą konfigurację należy usunąć, przywrócić do wcześniejszego stanu, czy pozostawić bez zmian.
Jeśli brakuje oczekiwanego przełącznika lub uprawnienia są nieprawidłowe, wyślij poniższe informacje do zespołu opiekującego się Twoim kontem OpenAI z prośbą o korektę.
Ponownie sprawdź dostęp w poprawionej konfiguracji, używając dokładnego identyfikatora zatwierdzonego modelu.
Podaj:
Nazwę firmy i dane głównej osoby do kontaktu w sprawach technicznych lub administratora organizacji.
Nazwy i identyfikatory obecnej oraz docelowej przestrzeni roboczej, organizacji API i projektu API, jeśli są znane.
Zatwierdzony poziom Daybreak i ustawienia widoczne w Ustawienia projektu → Ogólne → Dostęp do modeli Daybreak lub zapisane ustawienia przestrzeni roboczej i ról.
Dokładny identyfikator modelu użytego w teście.
Czy żądanie używa klucza projektu z włączonym dostępem i czy przeniesione zadania zaktualizowano tak, aby korzystały z projektu docelowego.
Potwierdzenie, że docelowa konfiguracja nie jest używana w aplikacjach dla klientów, do obsługi ruchu podmiotów zewnętrznych ani w dalszych procesach produktowych.
Czy w poprzedniej konfiguracji należy usunąć dostęp lub przywrócić jego wcześniejsze ustawienia.
Czy nowa konfiguracja wymaga wyjaśnienia kwestii rozliczeń, limitu budżetu lub odpowiedzialności handlowej.
Pierwszy proces, który zespół planuje uruchomić, oraz przewidywane osoby lub systemy uruchamiające go i osobę odpowiedzialną za weryfikację.
Ograniczenia czasowe lub termin zbliżającej się sesji wdrożeniowej, jeśli dotyczy.
Tam, gdzie dostępne są zatwierdzone ustawienia projektu, służą one do odizolowania dostępu Daybreak na poziomie projektu, bez konieczności tworzenia osobnej podorganizacji API. Jeśli ustawienia są niedostępne lub zatwierdzona konfiguracja nadal wymaga dedykowanej organizacji API, postępuj zgodnie z instrukcjami zespołu opiekującego się Twoim kontem OpenAI.
Jeśli stara organizacja lub projekt nadal oczekują na usunięcie, zamiana jest w toku lub korekta uprawnień nie została zakończona, uznaj poprawioną konfigurację za niegotową do czasu potwierdzenia zmiany.
Uwaga dotycząca użytkowania
Dostęp do Daybreak musi być ograniczony do zatwierdzonych użytkowników wewnętrznych i wewnętrznych prac związanych z bezpieczeństwem. Wyłącznie do użytku wewnętrznego oznacza pracę własnego upoważnionego zespołu, a nie ruch związany z obsługą klientów, usługi bezpieczeństwa oferowane na zewnątrz ani funkcje produktów przekazujące żądania podmiotów trzecich przez Daybreak. Tam, gdzie włączono ustawienia kontroli dostępu, używaj ról w przestrzeni roboczej i projektów API wyłącznie do użytku wewnętrznego, aby egzekwować zatwierdzony zakres.
Tam, gdzie dostępne są zatwierdzone ustawienia na poziomie projektu, projekt wyłącznie do użytku wewnętrznego może odizolować dostęp do Daybreak w uprawnionej organizacji API, bez konieczności tworzenia osobnej podorganizacji API. Włączenie dostępu w projekcie nie oznacza zgody na używanie go do obsługi klientów lub podmiotów trzecich.
Nieprzechowywanie danych (ZDR)
Uzyskanie uprawnień do Daybreak i włączenie dostępu w projekcie nie włączają automatycznie nieprzechowywania danych (ZDR). ZDR wymaga osobnego wniosku i uruchomienia dla konkretnej organizacji API i odpowiedniego punktu końcowego. Jeśli Twoja organizacja wymaga ZDR lub innych szczególnych zasad przechowywania danych, przed rozpoczęciem pierwszego procesu przez zespół potwierdź, że ruch z projektu z włączonym dostępem jest objęty tymi warunkami. Nie zakładaj, że włączenie przełącznika Daybreak Blue lub Daybreak Red w projekcie zmienia ustawienia przechowywania danych.
Granice dozwolonych działań
Korzystaj z udostępnionej konfiguracji wyłącznie do autoryzowanych działań obronnych.
Korzystaj z systemów należących do Twojej organizacji lub takich, na których ocenę ma ona wyraźną zgodę.
Ogranicz zakres pierwszego procesu, aby można było go łatwo zweryfikować.
Zapewnij udział ludzi w ocenie ustaleń o dużym znaczeniu i w działaniach naprawczych.
Używaj dokładnie tej organizacji, przestrzeni roboczej, projektu API, poziomu Daybreak i identyfikatora modelu, które wskazano w informacjach dotyczących wdrożenia.
Zezwalaj na konfigurację ustawień Daybreak w projekcie wyłącznie właścicielom organizacji API. Właściciele przestrzeni roboczej zarządzają jej ustawieniami domyślnymi i przypisywaniem ról niestandardowych. Zgoda na dostęp do Daybreak Blue nie obejmuje Daybreak Red.
Chroń dane uwierzytelniające projektu i ogranicz ich zakres do projektu z włączonym dostępem, przeznaczonego wyłącznie do użytku wewnętrznego.
Nie udostępniaj możliwości Daybreak klientom zewnętrznym ani użytkownikom spoza organizacji i nie włączaj ich do dalszych procesów produktowych.