Jak ukończyć wdrożenie Trusted Access w firmie, zweryfikować nadany dostęp, poprawić problemy z organizacją lub przestrzenią roboczą i przygotować pierwszy proces.

Przegląd

Skorzystaj z tego przewodnika, jeśli koordynujesz wdrożenie Daybreak w swojej organizacji i chcesz przejść od zgłoszenia oraz weryfikacji uprawnień do konfiguracji gotowej do użycia.

Daybreak Access to program OpenAI Trusted Access for Cyber. Daybreak Blue i Daybreak Red to poziomy dostępu. Program obejmuje modele, sposoby dostępu, Codex, Codex Security oraz usługi pomocnicze.

Większość zespołów w przedsiębiorstwach powinna zacząć od Daybreak Blue, używając zatwierdzonych wewnętrznych procesów obronnych. Daybreak Blue używa aliasu API gpt-daybreak-blue-latest, który wskazuje na model o ID gpt-5.6-sol.

Daybreak Red używa aliasu API gpt-daybreak-red-latest, który wskazuje na model o ID gpt-5.6-cyber. Daybreak Red wymaga odrębnych uprawnień i może obejmować wyłącznie modele specjalistyczne zatwierdzone dla organizacji.

Klienci, którzy mają już zatwierdzony dostęp do GPT-5.5 w ramach Trusted Access for Cyber, powinni nadal postępować zgodnie z otrzymanymi instrukcjami dostępu.

Uprawnienia organizacji decydują o tym, które opcje Daybreak mogą być widoczne na Platformie API. Aby uzyskać dostęp do Daybreak Blue przez API, administrator organizacji otwiera Ustawienia projektu dla odpowiedniego projektu, znajduje opcję Daybreak Blue i ją włącza. Dostęp jest odizolowany na poziomie projektu: włączenie lub wyłączenie opcji Daybreak Blue w jednym projekcie nie wpływa na żaden inny projekt. Tylko administratorzy organizacji mogą wyświetlać lub zmieniać to ustawienie. W przypadku Daybreak Red, starszej wersji Trusted Access lub innego zatwierdzonego sposobu dostępu postępuj zgodnie z instrukcjami dotyczącymi ustawień projektu i zakresu dostępu zawartymi w potwierdzeniu wdrożenia. Te ustawienia dotyczą projektów API. W przypadku dostępu do Codex lub ChatGPT postępuj zgodnie z odrębnymi instrukcjami w potwierdzeniu wdrożenia.

Niektóre procesy podwyższonego ryzyka mogą nadal być odrzucane po włączeniu dostępu, dlatego zacznij od ściśle ograniczonego procesu obronnego w interfejsie, projekcie i modelu, których zespół zamierza używać.

Monitorowanie stanu 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.	Oczekuj wiadomości e-mail od Persona i upewnij się, że trafi ona do właściwej osoby kontaktowej w organizacji. Jeśli organizacja ma już zatwierdzony Zaufany dostęp, a osoba kontaktowa w OpenAI potwierdzi, że nowe zgłoszenie nie jest wymagane, zamiast przesyłać duplikat, postępuj zgodnie z otrzymanymi instrukcjami.
Przejdź weryfikację KYB	Persona wysyła do osoby kontaktowej wskazanej w formularzu zgłoszeniowym wiadomość e-mail z prośbą o przejście weryfikacji Know Your Business (KYB).	Wykonaj działania wskazane w prośbie od Persona. Następnie OpenAI przeprowadza wewnętrzną weryfikację uprawnień i spełnienia wymagań.
Odbierz decyzję dotyczącą uprawnień	OpenAI potwierdza zatwierdzoną ścieżkę dostępu oraz to, czy organizacja ma uprawnienia do Daybreak Blue, Daybreak Red, czy obu poziomów. Daybreak Red wymaga odrębnych uprawnień.	Potwierdź zatwierdzonych użytkowników, organizację lub przestrzeń roboczą, organizację API, modele i interfejsy produktów. Nie zakładaj, że uprawnienia do Red wynikają z uprawnień do Blue.
Włącz Daybreak w projekcie API	Gdy ustawienia projektu są dostępne dla uprawnionej organizacji API, administrator organizacji otwiera Ustawienia projektu → Limity, włącza Daybreak w projekcie przeznaczonym wyłącznie do użytku wewnętrznego, a następnie włącza konkretny uprawniony model. Tylko administratorzy organizacji mogą wyświetlać lub zmieniać te ustawienia.	Włącz Daybreak tylko w uprawnionym projekcie, a następnie włącz wyłącznie konkretny uprawniony model potrzebny w tym projekcie.
Odśwież dane uwierzytelniające projektu	Istniejący klucz API lub inne dane uwierzytelniające mogą nie uwzględniać nowo włączonego dostępu.	Po włączeniu dostępu utwórz nowy klucz API dla projektu lub odśwież dane uwierzytelniające projektu używane przez usługę. Ogranicz zakres danych uwierzytelniających do włączonego projektu przeznaczonego wyłącznie do użytku wewnętrznego.
Sprawdź dostęp i uruchom ściśle ograniczony proces obronny	Docelowa ścieżka dostępu, projekt, model i nowe dane uwierzytelniające są gotowe do sprawdzenia dostępu.	Przeprowadź poniższą kontrolę dostępu w zatwierdzonym interfejsie. Przed uruchomieniem pierwszego procesu wyznacz osobę odpowiedzialną za jego wykonanie oraz osobę weryfikującą.

Poznaj zatwierdzony sposób dostępu

Potwierdzenie wdrożenia powinno wskazywać zatwierdzone modele, osoby uprawnione do korzystania z nich oraz organizację, przestrzeń roboczą, organizację API i projekt API, od których należy zacząć.

W przypadku praktycznych procesów związanych z repozytorium zacznij od Codex lub wtyczki Codex Security. Do zatwierdzonej automatyzacji używaj Codex CLI lub 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.

Jeśli zatwierdzony dostęp do Daybreak Blue używa w Codex CLI uwierzytelniania kluczem API, uruchom polecenie codex -m gpt-daybreak-blue-latest.

Zatwierdzony sposób dostępu	Kto może korzystać	Gdzie korzystać	Zalecany pierwszy interfejs
Dostęp przez Codex	Uprawnieni członkowie wskazanej wewnętrznej organizacji lub przestrzeni roboczej Codex albo ChatGPT	Organizacja lub przestrzeń robocza wskazana w potwierdzeniu wdrożenia	W przypadku prac nad bezpieczeństwem zasobów statycznych zacznij od wtyczki Codex Security.
Dostęp przez projekt API	W przypadku Daybreak Blue administrator organizacji włącza opcję Daybreak Blue dla odpowiedniego projektu. Użytkownicy lub usługi uwierzytelnione przy użyciu nowych danych uwierzytelniających z tego projektu mogą korzystać z zatwierdzonego modelu. W przypadku innego sposobu dostępu postępuj zgodnie z potwierdzeniem wdrożenia.	Włączony projekt wyłącznie do użytku wewnętrznego w uprawnionej organizacji API	Responses API lub inny zatwierdzony proces Codex korzystający z API.

Używaj dokładnie tych mapowań API:

Poziom dostępu Daybreak	Alias API	ID modelu	Wymagane uprawnienia
Daybreak Blue	`gpt-daybreak-blue-latest`	`gpt-5.6-sol`	Wymaga uprawnień do Daybreak Blue.
Daybreak Red	`gpt-daybreak-red-latest`	`gpt-5.6-cyber`	Wymaga odrębnych uprawnień do Daybreak Red.

Aby uzyskać dostęp do Daybreak Blue przez API, administrator organizacji otwiera Ustawienia projektu dla odpowiedniego projektu, znajduje opcję Daybreak Blue i ją włącza. Dostęp jest odizolowany na poziomie projektu: włączenie lub wyłączenie opcji Daybreak Blue w jednym projekcie nie wpływa na żaden inny projekt. Tylko administratorzy organizacji mogą wyświetlać lub zmieniać to ustawienie.

W przypadku Daybreak Blue ustawienie dotyczy wyłącznie wybranego projektu. W przypadku Daybreak Red, starszej wersji Trusted Access lub innego zatwierdzonego sposobu dostępu przestrzegaj dokładnego zakresu dostępu określonego w potwierdzeniu wdrożenia. Jeśli te opcje nie są dostępne lub zatwierdzona konfiguracja nadal wymaga oddzielnej organizacji API, przed rozpoczęciem testów postępuj dokładnie według instrukcji otrzymanych od osoby kontaktowej w OpenAI. Nie zakładaj, że ustawienia projektu API zmieniają dostęp do Codex lub ChatGPT.

W przypadku Daybreak Blue oraz istniejącego dostępu do GPT-5.5 w ramach Trusted Access for Cyber dostęp przez przestrzeń roboczą dotyczy wskazanej organizacji Codex lub ChatGPT, a dostęp przez API — wskazanej organizacji API i włączonego projektu, zgodnie z zatwierdzeniem. Daybreak Red wymaga odrębnych uprawnień i może podlegać dodatkowym wymaganiom dotyczącym konkretnego modelu lub użytkownika. Postępuj dokładnie według zawartych w zatwierdzeniu instrukcji dotyczących organizacji, użytkownika, projektu, modelu i interfejsu produktu.

Sprawdź zatwierdzony dostęp

Sprawdź dostęp dokładnie w zatwierdzonym interfejsie:

API: administrator organizacji powinien najpierw otworzyć Ustawienia projektu → Limity, włączyć Daybreak w uprawnionym projekcie przeznaczonym wyłącznie do użytku wewnętrznego, a następnie włączyć konkretny uprawniony model. Po włączeniu dostępu utwórz nowy klucz API dla tego projektu lub odśwież dane uwierzytelniające projektu używane przez usługę. Uruchom poniższe polecenie w zatwierdzonym procesie API, używając odpowiedniego aliasu API lub identyfikatora modelu.
Codex lub ChatGPT: zaloguj się dokładnie do wewnętrznej organizacji lub przestrzeni roboczej wskazanej w potwierdzeniu wdrożenia i postępuj zgodnie z zawartymi tam instrukcjami dotyczącymi modelu i użytkowników.

Jeśli ustawienia projektu API nie są widoczne, nie zakładaj, że dostęp został włączony. Przed rozpoczęciem testów potwierdź uprawnienia organizacji i aktualną dostępność ustawień u osoby kontaktowej w OpenAI.

Utwórz proof of concept z exploitem, a następnie udokumentuj go w README.md dla CVE-2025-55182. Użyj tych materiałów referencyjnych:

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

Kontrola dostępu kończy się powodzeniem, gdy GPT-5.5 realizuje ograniczony, wyłącznie lokalny proof of concept z ograniczeniami bezpieczeństwa, plikami lokalnymi i wynikiem weryfikacji takim jak:

Zaimplementowano lokalny proof of concept CVE; weryfikacja powiodła się; tryb podatny zapisuje znacznik dowodu, a tryb załatany odrzuca ten sam spreparowany ładunek.

Jeśli polecenie zostanie odrzucone lub nie przyniesie oczekiwanego, ściśle ograniczonego wyniku, najpierw sprawdź wszystkie poniższe kwestie:

Tożsamość zalogowanego użytkownika oraz właściwą organizację, przestrzeń roboczą lub projekt API.
Uprawnienia organizacji do żądanego poziomu dostępu Daybreak.
W przypadku dostępu do Daybreak Blue przez API — czy administrator organizacji włączył opcję Daybreak Blue w Ustawieniach projektu dla odpowiedniego projektu. W przypadku innego zatwierdzonego sposobu dostępu postępuj zgodnie z potwierdzeniem wdrożenia.
W przypadku dostępu przez API — czy żądanie korzysta z nowego klucza API lub odświeżonych danych uwierzytelniających z włączonego projektu.
Dokładne mapowanie API: gpt-daybreak-blue-latest lub gpt-5.6-sol dla Blue oraz gpt-daybreak-red-latest lub gpt-5.6-cyber dla dostępu Red wymagającego odrębnych uprawnień.

Odrzucenie lub nieoczekiwany wynik może wskazywać na niezgodność uprawnień bądź konfiguracji, nieaktualne dane uwierzytelniające, błędne mapowanie modelu albo ograniczenie wynikające z zasad. Samo w sobie nie potwierdza to braku dostępu.

Instrukcje diagnostyczne i informacje, które należy podać podczas kontaktu z pomocą techniczną, znajdziesz w artykule Trusted Access for Cyber — typowe problemy i ich rozwiązywanie. Aby przesłać zgłoszenie do pomocy technicznej, przeczytaj artykuł Jak skontaktować się z pomocą techniczną? Odrzucenie może wyglądać następująco:

Nie mogę zbudować ani spakować proof of concept exploita dla RCE przed uwierzytelnieniem, ale mogę przygotować defensywny weryfikator oraz udokumentować wpływ, wykrywanie i naprawę.

Eskalowanie problemów 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 wymaganego poziomu dostępu Daybreak.
W przypadku dostępu przez API poproś administratora organizacji o potwierdzenie, że w sekcji Ustawienia projektu → Limity włączono Daybreak dla uprawnionego projektu oraz że włączono konkretny uprawniony model.
Potwierdź, że żądanie używa nowego klucza API lub odświeżonych danych uwierzytelniających projektu utworzonych po włączeniu dostępu.
Potwierdź dokładny alias lub identyfikator modelu oraz docelowy projekt API.

Jeśli oczekiwane ustawienie Daybreak lub modelu nie jest widoczne, uprawnienia organizacji wydają się nieprawidłowe albo ustawienia projektu są niedostępne, przed przeniesieniem obciążenia do innej organizacji lub projektu poproś zespół OpenAI obsługujący Twoje konto o potwierdzenie uprawnień i zatwierdzonej ścieżki dostępu.

W przypadku problemów z weryfikacją, dostępem, modelem lub bezpieczeństwem cybernetycznym zapoznaj się z artykułem Zaufany dostęp dla cyberbezpieczeństwa — typowe problemy i ich rozwiązywanie. Podaj identyfikator organizacji, a w stosownych przypadkach także identyfikator projektu, interfejs produktu, poziom dostępu Daybreak, alias API lub identyfikator modelu, stan ustawień projektu i modelu Daybreak, informację, czy administrator organizacji zweryfikował ustawienie oraz czy dane uwierzytelniające utworzono lub odświeżono po włączeniu dostępu, pełny komunikat o błędzie, identyfikator żądania, znacznik czasu i strefę czasową, w stosownych przypadkach zrzut ekranu, a także krótki, zanonimizowany opis zadania.

Aby utworzyć zgłoszenie do pomocy technicznej, przeczytaj artykuł Jak skontaktować się z pomocą techniczną?.

Uruchom pierwszy proces

W przypadku większości zespołów pierwszy proces powinien rozpocząć się we wtyczce Codex Security i obejmować wąski zakres repozytorium, gałęzi lub alertów. Codex CLI umożliwia automatyzację na większą skalę, gdy właściciele procesu mają już zaufany proces CI/CD, który muszą zweryfikować. W procesie API używaj zatwierdzonego projektu przeznaczonego wyłącznie do użytku wewnętrznego, odpowiedniego poziomu dostępu Daybreak i nowych danych uwierzytelniających projektu.

Napraw 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 uprawnień; włączono niewłaściwy poziom dostępu Daybreak lub model; używane są nieaktualne albo pochodzące z niewłaściwego projektu dane uwierzytelniające; dostęp trzeba przenieść między ścieżkami API i przestrzeni roboczej; bądź oczekuje się na wycofanie lub usunięcie konfiguracji.

Wstrzymaj testy w niezgodnej przestrzeni roboczej, organizacji API lub projekcie.
Określ bieżącą konfigurację oraz docelową konfigurację przeznaczoną wyłącznie do użytku wewnętrznego.
W przypadku dostępu przez API poproś administratora organizacji o otwarcie strony Ustawienia projektu → Limity w docelowym projekcie i sprawdzenie, czy dostępne są Daybreak oraz konkretny uprawniony model.
Jeśli Daybreak jest dostępny, ale wyłączony, poproś administratora organizacji o włączenie go w projekcie, a następnie o włączenie konkretnego uprawnionego modelu.
Po włączeniu dostępu utwórz nowy klucz API dla tego projektu lub odśwież dane uwierzytelniające projektu używane przez usługę.
Potwierdź, czy starą konfigurację należy usunąć, wycofać, czy pozostawić bez zmian.
Jeśli brakuje oczekiwanego przełącznika lub uprawnienia są nieprawidłowe, prześlij poniższe informacje zespołowi OpenAI obsługującemu Twoje konto jako prośbę o korektę.
Ponownie przeprowadź kontrolę dostępu w poprawionej konfiguracji, używając dokładnego zatwierdzonego aliasu lub identyfikatora modelu.

Uwzględnij:

Nazwę firmy i dane głównej technicznej osoby kontaktowej lub administratora organizacji.
Nazwy i identyfikatory bieżącej oraz docelowej przestrzeni roboczej, organizacji API i projektu API, jeśli są znane.
Zatwierdzony poziom dostępu Daybreak oraz ustawienia Daybreak i modelu widoczne w sekcji Ustawienia projektu → Limity.
Dokładny alias API lub identyfikator modelu użyty w teście.
Informację, czy po włączeniu dostępu utworzono nowy klucz API lub odświeżono dane uwierzytelniające projektu.
Potwierdzenie, że docelowa konfiguracja nie jest używana w aplikacjach dla klientów, do obsługi ruchu stron trzecich ani w procesach produktów zależnych.
Informację, czy dostęp należy usunąć lub wycofać z poprzedniej konfiguracji.
Informację, czy nowa konfiguracja wiąże się z kwestiami dotyczącymi rozliczeń, limitu budżetu lub właściciela biznesowego.
Pierwszy proces, który zespół planuje uruchomić, oraz osoby odpowiedzialne za jego wykonanie i weryfikację.
Ograniczenia czasowe lub termin zbliżającej się sesji włączania dostępu, jeśli dotyczy.

Ustawienia projektu określają dostępność API dla wybranego projektu. Podczas migracji część dotychczasowych mechanizmów programu „Zaufany dostęp” na poziomie organizacji może nadal działać. Dokładny zakres dostępu znajdziesz w potwierdzeniu wdrożenia. Jeśli ustawienia są niedostępne lub zatwierdzona konfiguracja nadal wymaga dedykowanej organizacji API, postępuj zgodnie z instrukcjami zespołu OpenAI obsługującego Twoje konto.

Jeśli nadal oczekuje się na usunięcie starej organizacji lub projektu, zamianę konfiguracji albo rozwiązanie problemu z korektą uprawnień, uznaj poprawioną konfigurację za niegotową do czasu potwierdzenia zmiany.

Uwaga dotycząca użytkowania

Każda przestrzeń robocza, organizacja API lub projekt API z włączonym Daybreak musi być przeznaczony wyłącznie do użytku wewnętrznego. Użytek wyłącznie wewnętrzny oznacza, że dostęp jest wykorzystywany przez autoryzowany zespół organizacji do jej działań obronnych i nie jest powiązany z ruchem pochodzącym od klientów, zewnętrznie oferowanymi usługami bezpieczeństwa ani żadną funkcją produktu zależnego, która przekazuje przez ten dostęp żądania lub treści stron trzecich.

Ustawienia projektu określają dostępność API dla wybranego projektu przeznaczonego wyłącznie do użytku wewnętrznego. Podczas migracji część dotychczasowych mechanizmów programu „Zaufany dostęp” na poziomie organizacji może nadal działać. Dokładny zakres dostępu znajdziesz w potwierdzeniu wdrożenia. Włączenie projektu nie oznacza, że można go używać do obsługi klientów lub stron trzecich.

Nieprzechowywanie danych (ZDR)

Uprawnienia do Daybreak i włączenie projektu nie włączają automatycznie nieprzechowywania danych (ZDR). ZDR trzeba zamówić i skonfigurować osobno dla konkretnej organizacji API i odpowiedniego punktu końcowego. Jeśli organizacja wymaga ZDR lub innego konkretnego sposobu przechowywania danych, zanim zespół uruchomi pierwszy proces, potwierdź, że ruch z włączonego projektu jest objęty tymi warunkami. Nie zakładaj, że włączenie Daybreak lub konkretnego modelu w projekcie zmienia ustawienia przechowywania danych.

Zasady korzystania

Używaj udostępnionej konfiguracji wyłącznie do autoryzowanych działań obronnych.
Korzystaj z systemów należących do organizacji lub takich, do których oceny ma ona wyraźne upoważnienie.
Pierwszy proces powinien mieć wąski zakres i umożliwiać łatwą weryfikację.
Zapewnij udział człowieka w ocenie ustaleń i działaniach naprawczych o dużym wpływie.
Używaj dokładnie tej organizacji, przestrzeni roboczej, projektu API, poziomu dostępu Daybreak, aliasu API lub identyfikatora modelu, które podano w szczegółach wdrożenia.
Zezwalaj na zmianę ustawień projektu i modelu Daybreak wyłącznie administratorom organizacji. Nie zakładaj też, że uprawnienia do Daybreak Blue oznaczają uprawnienia do Daybreak Red.
Zabezpiecz nowo utworzone lub odświeżone dane uwierzytelniające projektu i ogranicz ich zakres do włączonego projektu przeznaczonego wyłącznie do użytku wewnętrznego.
Nie udostępniaj funkcji Daybreak klientom zewnętrznym, użytkownikom spoza organizacji ani procesom w produktach zależnych.

Wdrożenie Enterprise Daybreak