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 musisz przejść od przyjęcia zgłoszenia przez nadanie dostępu do konfiguracji gotowej do uruchomienia.

Daybreak to program OpenAI skoncentrowany na pracy z cyberbezpieczeństwem, obejmujący modele, ścieżki dostępu, Codex, Codex Security oraz usługi pomocnicze.

Większość zespołów korporacyjnych używa GPT-5.5 z Trusted Access for Cyber do zatwierdzonych wewnętrznych procesów obronnych. W przypadku tej ścieżki dostępu OpenAI nadaje dostęp organizacji lub przestrzeni roboczej wskazanej w procesie przyjmowania zgłoszenia po zakończeniu weryfikacji Persona KYB i wewnętrznych kontroli kwalifikowalności. Dostęp może dotyczyć organizacji Codex lub ChatGPT, organizacji API albo obu tych opcji, zależnie od zatwierdzonej konfiguracji.

Niektóre procesy wyższego ryzyka mogą nadal zostać odrzucone po nadaniu dostępu, dlatego zacznij od ograniczonego procesu obronnego dokładnie w tym obszarze, którego zespół planuje używać.

Śledź stan wdrożenia i nadawania dostępu

Faza	Opis	Co zrobić dalej
Prześlij formularz przyjęcia	Twoja organizacja wypełniła firmowy formularz przyjęcia Trusted Access	Wypatruj wiadomości e-mail od Persona i ukończ weryfikację KYB. Upewnij się, że wiadomość e-mail od Persona trafi do właściwego kontaktu w organizacji.
Odbierz i wypełnij wiadomość KYB od Persona	Po przesłaniu formularza przyjęcia Persona wysyła wiadomość e-mail do osoby kontaktowej wskazanej w formularzu, aby ukończyć weryfikację Know Your Business (KYB).	Wypełnij żądanie Persona KYB. Po ukończeniu KYB OpenAI przeprowadza wewnętrzne kontrole kwalifikowalności i nadaje dostęp dopiero po ich pozytywnym zakończeniu.
Odbierz powiadomienie o nadaniu dostępu	OpenAI zastosowało dostęp do organizacji lub przestrzeni roboczej wskazanej w formularzu przyjęcia.	Sprawdź, czy dostęp został poprawnie nadany w żądanym obszarze. Pamiętaj, że dostęp nie jest obecnie widoczny w panelu przestrzeni roboczej dostępnym dla klienta.
Sprawdź, czy masz dostęp, i rozpocznij ograniczony proces obronny	Nadana organizacja lub przestrzeń robocza została potwierdzona, a zamierzona kontrola dostępu zakończyła się powodzeniem	Wybierz jeden ograniczony pierwszy proces obronny, wskaż osobę uruchamiającą proces i recenzenta, a następnie użyj wtyczki Codex Security lub zatwierdzonej organizacji Responses API.

Zrozum udostępnioną ścieżkę dostępu

Potwierdzenie od OpenAI powinno wskazywać, która ścieżka dostępu została udostępniona, kto może z niej korzystać oraz której organizacji lub przestrzeni roboczej należy użyć najpierw.

W przypadku praktycznych procesów w repozytoriach zacznij od Codex lub wtyczki Codex Security. Do zatwierdzonej automatyzacji użyj Codex CLI lub Codex GitHub Action. Jeśli dostęp nadano organizacji API, ogranicz żądania i poświadczenia do tej organizacji.

Udostępniona ścieżka dostępu	Kto może z niej korzystać	Gdzie obowiązuje dostęp	Pierwszy obszar do weryfikacji dostępu
Dostęp przez Codex	Członkowie wskazanej wewnętrznej organizacji lub przestrzeni roboczej Codex albo ChatGPT	Udostępniona organizacja lub przestrzeń robocza. Dla tej ścieżki dostęp obejmuje całą organizację	W przypadku pracy nad bezpieczeństwem zasobów statycznych zacznij od wtyczki Codex Security.
Dostęp przez organizację API	Użytkownicy lub usługi uwierzytelnione w wskazanej wewnętrznej organizacji API	Udostępniona organizacja API	Responses API lub inny zatwierdzony proces API Codex.

W przypadku GPT-5.5 z Trusted Access for Cyber dostęp do przestrzeni roboczej jest nadawany wskazanej organizacji Codex lub ChatGPT, a dostęp API — wskazanej organizacji API. Jeśli potwierdzenie wskazuje inną ścieżkę na poziomie użytkownika lub właściwą dla modelu, zastosuj dokładnie te instrukcje zamiast zakładać dostęp obejmujący całą organizację. Jeśli udostępniona ścieżka dostępu jest niejasna, przed testowaniem poproś kontakt w OpenAI o jej potwierdzenie.

Zweryfikuj nadany dostęp

Gdy OpenAI potwierdzi nadanie dostępu, uruchom to polecenie dokładnie w potwierdzonym obszarze. Może to być Codex po zalogowaniu do organizacji lub przestrzeni roboczej przeznaczonej wyłącznie do użytku wewnętrznego albo Responses API z poświadczeniami z potwierdzonej organizacji API.

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 zwróci oczekiwanego ograniczonego wyniku, najpierw potwierdź zalogowaną tożsamość oraz organizację lub przestrzeń roboczą. Wynik może wskazywać na niepełne nadanie dostępu, niezgodność routingu albo granicę zasad. Jeśli nadanie dostępu zostało ukończone, a problem nadal występuje, postępuj zgodnie z artykułem Trusted Access for Cyber – typowe problemy i rozwiązywanie problemów, aby wykonać kroki diagnostyczne i poznać szczegóły, które należy podać przy kontakcie z pomocą techniczną. Aby otworzyć zgłoszenie do pomocy technicznej, zobacz: Jak skontaktować się z pomocą techniczną? Odmowa może wyglądać tak:

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ę.

Eskaluj problemy z konfiguracją

Przed zmianą przestrzeni roboczych, organizacji API, repozytoriów lub poświadczeń poproś zespół opiekunów konta OpenAI o potwierdzenie, że nadawanie dostępu zostało ukończone oraz że zamierzona organizacja, przestrzeń robocza i ścieżka dostępu są poprawne.

W przypadku problemów z weryfikacją, dostępem, modelem lub bezpieczeństwem cybernetycznym postępuj zgodnie z artykułem Trusted Access for Cyber – typowe problemy i rozwiązywanie problemów. Zawiera on kroki diagnostyczne oraz informacje, które należy podać przy kontakcie z pomocą techniczną, takie jak identyfikator organizacji, obszar produktu, model, pełny komunikat o błędzie, identyfikator żądania, znacznik czasu i strefa czasowa, zrzut ekranu, jeśli ma zastosowanie, oraz krótki, zredagowany opis zadania.

Aby otworzyć zgłoszenie do pomocy technicznej, zobacz: Jak skontaktować się z pomocą techniczną?

Rozpocznij pierwszy proces

W przypadku większości zespołów pierwszy proces powinien rozpocząć się we wtyczce Codex Security z wąskim zakresem repozytorium, gałęzi lub alertu. Codex CLI to ścieżka automatyzacji na większą skalę, gdy właściciele procesu mają już zaufany proces CI/CD, który trzeba zweryfikować.

Popraw niezgodność przestrzeni roboczej lub organizacji API

Użyj tej ścieżki, gdy zatwierdzona konfiguracja wskazuje niewłaściwą organizację, przesłana organizacja nie jest przeznaczona wyłącznie do użytku wewnętrznego, dostęp trzeba przenieść między ścieżkami API i przestrzeni roboczej albo oczekuje wycofanie lub usunięcie.

Wstrzymaj testowanie w niezgodnej przestrzeni roboczej lub organizacji API.
Zidentyfikuj bieżącą konfigurację, która została przesłana lub której nadano dostęp.
Zidentyfikuj zamierzoną przestrzeń roboczą przeznaczoną wyłącznie do użytku wewnętrznego, organizację API albo obie te opcje.
Potwierdź, czy starą konfigurację należy usunąć, wycofać czy pozostawić bez zmian.
Prześlij poniższe szczegóły zespołowi opiekunów konta OpenAI jako prośbę o korektę.
Poczekaj, aż OpenAI potwierdzi ukończenie korekty.
Ponownie uruchom kontrolę potwierdzającą dostęp w poprawionej konfiguracji.

Uwzględnij:

nazwę firmy oraz główny kontakt techniczny lub kontakt administratora przestrzeni roboczej
nazwę i identyfikator bieżącej przestrzeni roboczej lub organizacji API, jeśli są znane
nazwę i identyfikator zamierzonej przestrzeni roboczej lub organizacji API przeznaczonej wyłącznie do użytku wewnętrznego, jeśli są znane
potwierdzenie, że zamierzona konfiguracja nie jest używana na potrzeby aplikacji dostępnych dla klientów, ruchu zewnętrznego ani podrzędnych procesów produktowych
czy dostęp należy usunąć z poprzedniej konfiguracji, czy go wycofać
czy nowa konfiguracja rodzi pytania dotyczące rozliczeń, limitu budżetu lub właściciela komercyjnego
pierwszy proces, który zespół planuje uruchomić, oraz oczekiwane osoby uruchamiające proces
ograniczenia czasowe lub nadchodzącą sesję aktywacyjną, jeśli dotyczy

Jeśli usunięcie starej organizacji nadal oczekuje albo oczekuje zamiana, traktuj poprawioną konfigurację jako niegotową, dopóki OpenAI nie potwierdzi ukończenia zmiany.

Uwaga dotycząca użycia

Każda przestrzeń robocza lub organizacja API z włączonym Trusted Access powinna być wyłącznie wewnętrzna. „Wyłącznie wewnętrzna” oznacza, że dostęp jest używany przez Twój własny autoryzowany zespół do prac obronnych organizacji i nie jest powiązany z ruchem kierowanym do klientów, zewnętrznie oferowanymi usługami bezpieczeństwa ani żadną dalszą funkcją produktu, która przekazuje przez ten dostęp żądania lub treści osób trzecich.

Nieprzechowywanie danych (ZDR)

Nadanie dostępu Trusted Access nie włącza automatycznie nieprzechowywania danych (ZDR). ZDR trzeba zamówić i nadać osobno dla dokładnej organizacji. Jeśli Twoja organizacja wymaga ZDR lub innego konkretnego sposobu przechowywania danych, przed rozpoczęciem pierwszego procesu przez zespół potwierdź, że organizacja, której planujesz użyć, jest objęta tymi warunkami.

Granice operacyjne

Używaj przydzielonej konfiguracji wyłącznie do autoryzowanych prac obronnych.
Używaj systemów, które należą do Twojej organizacji lub do których oceny ma ona wyraźne upoważnienie.
Utrzymuj pierwszy proces wąski i możliwy do przeglądu.
W przypadku ustaleń o dużym wpływie i działań naprawczych zachowaj udział człowieka w pętli.
Używaj przestrzeni roboczej, konfiguracji API i dostępu do modelu wymienionych w szczegółach wdrożenia.
Nie rozszerzaj możliwości Trusted Access na klientów zewnętrznych, użytkowników zewnętrznych ani dalsze procesy produktów.

Wdrożenie Enterprise Daybreak