Omówienie
Skorzystaj z tego przewodnika, jeśli koordynujesz wdrożenie Daybreak w swojej organizacji i musisz przejść od zatwierdzenia do konfiguracji gotowej do uruchomienia.
Daybreak to program OpenAI skoncentrowany na pracach z zakresu cyberbezpieczeństwa, obejmujący modele, ścieżki dostępu, Codex, Codex Security oraz usługi wspierające.
Większość zespołów enterprise używa GPT-5.5 z Trusted Access for Cyber do zatwierdzonych wewnętrznych procesów obronnych. W zależności od konfiguracji dostęp może zostać przydzielony do przestrzeni roboczej, organizacji API, nazwanej tożsamości Codex lub więcej niż jednej ścieżki. Szczegóły wdrożenia od OpenAI powinny wskazywać dokładną przestrzeń roboczą, organizację API, zatwierdzoną tożsamość Codex oraz dostęp do modelu, których należy używać. Niektóre procesy o wyższym ryzyku mogą nadal zostać odrzucone nawet po zatwierdzeniu, dlatego zacznij od ograniczonego procesu obronnego na dokładnej powierzchni, której Twój zespół planuje używać.
1. Śledź stan wdrożenia
Zatwierdzenie jest pierwszym krokiem wdrożenia. Traktuj konfigurację jako gotową dopiero wtedy, gdy zatwierdzona ścieżka dostępu zostanie przydzielona w odpowiedniej wewnętrznej przestrzeni roboczej lub organizacji API, a Twój zespół będzie mieć dowód, że zamierzona powierzchnia działa.
| Stan | Co to oznacza | Co zrobić dalej |
|---|---|---|
| Przesłano | Twoja organizacja przesłała wniosek lub zespół konta OpenAI przesłał go w Twoim imieniu. | Utrzymuj proponowaną przestrzeń roboczą lub organizację API, zakres użytku wewnętrznego, administratora technicznego i pierwszy proces w gotowości na wypadek, gdyby OpenAI potrzebowało więcej szczegółów. |
| Zatwierdzono | OpenAI potwierdziło, że organizacja została zatwierdzona do Trusted Access for Cyber. | Potwierdź, którą ścieżkę dostępu zatwierdziło OpenAI oraz jaką przestrzeń roboczą, organizację API, zatwierdzoną tożsamość Codex lub konfigurację modelu obejmuje zatwierdzenie. |
| Przydzielono | OpenAI potwierdziło, że dostęp został zastosowany do nazwanej przestrzeni roboczej, organizacji API, zatwierdzonej tożsamości Codex lub konfiguracji modelu. | Przed pierwszym procesem udowodnij, że dostęp działa na tej dokładnej powierzchni. |
| Gotowe do uruchomienia | Ścieżka dostępu jest potwierdzona, korekty konfiguracji są zakończone, a Twój zespół ma obserwowalne dowody z interfejsu lub API. | Wybierz jeden ograniczony pierwszy proces obronny, wskaż osobę uruchamiającą proces i recenzenta oraz użyj wtyczki Codex Security albo Responses API przez zatwierdzoną przestrzeń roboczą dla istniejącego harnessu. |
2. Zrozum zatwierdzoną ścieżkę dostępu
Szczegóły wdrożenia od OpenAI powinny wskazywać, która ścieżka dostępu została zatwierdzona, kto może jej używać i której powierzchni procesu użyć jako pierwszej. W przypadku praktycznych procesów najlepszym punktem wyjścia jest Codex lub wtyczka Codex Security. Do automatyzacji na dużą skalę używaj Codex CLI albo Codex GitHub Action. Jeśli szczegóły wdrożenia wskazują zatwierdzoną organizację API, traktuj ją jako konfigurację dla tej zatwierdzonej ścieżki automatyzacji.
| Zatwierdzona ścieżka dostępu | Kto może jej używać | Gdzie obowiązuje dostęp | Pierwsza powierzchnia do sprawdzenia |
|---|---|---|---|
| Dostęp do przestrzeni roboczej dla Codex | Członkowie nazwanej wewnętrznej przestrzeni roboczej enterprise Codex lub ChatGPT. | Przydzielona przestrzeń robocza. Przestrzeń robocza ChatGPT może być kontekstem administracji, członkostwa lub logowania dla Codex. | W przypadku prac nad bezpieczeństwem zasobów statycznych zacznij od wtyczki Codex Security. |
| Dostęp organizacji API dla Codex CLI | Użytkownicy lub usługi używające poświadczeń w nazwanej wewnętrznej organizacji API. | Przydzielona organizacja API lub projekt. | Codex CLI z uwierzytelnianiem tokenem. |
Większość zatwierdzeń enterprise korzysta z dostępu do przestrzeni roboczej, dostępu organizacji API lub obu tych opcji. Niektóre zatwierdzenia są węższe: nazwana tożsamość Codex nie przyznaje takiego samego dostępu każdej osobie w przestrzeni roboczej, a dostęp API dotyczy tylko nazwanej organizacji API. Jeśli szczegóły wdrożenia nie wskazują ścieżki dostępu, poproś kontakt w OpenAI o jej potwierdzenie, zanim Twój zespół wewnętrzny rozpocznie testowanie.
3. Potwierdź dostęp po zatwierdzeniu
Najlepiej zweryfikować dowód dostępu na konkretnej powierzchni produktu, z której będzie korzystać Twój zespół, a nie opierać się na ogólnym potwierdzeniu zatwierdzenia organizacji. Najszybszym sposobem weryfikacji dostępu jest instalacja i wypróbowanie wtyczki Codex Security; jeśli planujesz używać Codex CLI do automatyzacji na dużą skalę, zweryfikuj dokładnie tę konfigurację automatyzacji i organizację API.
| Zatwierdzona ścieżka dostępu | Sprawdzenie | Dostęp działa, gdy | Dowody do zebrania |
|---|---|---|---|
| Dostęp do przestrzeni roboczej dla Codex | Zainstaluj wtyczkę Codex Security i wykonaj sugerowane polecenia w lokalnej instancji Codex. | Wtyczka Codex Security potrafi skanować, przeglądać i naprawiać ustalenia w docelowym repozytorium. | @codexsecurity w polu wejściowym wywołuje konkretne umiejętności, takie jak threat-model. |
| Dostęp organizacji API do używania Responses API | Uruchom jeden ograniczony wewnętrzny proces automatyzacji obronnej. Możesz użyć tego przykładowego polecenia cURL, aby zweryfikować dostęp przez 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."}' | Żądanie uwierzytelnia się w oczekiwanej organizacji API, używa konfiguracji modelu z wdrożenia i zwraca wynik możliwy do przeglądu zamiast błędu dostępu lub routingu. | Organizacja lub projekt API, właściciel poświadczeń API, wysłana nazwa modelu, znacznik czasu, identyfikator żądania, jeśli dostępny, oraz HTTP 200 lub wynik pomyślnej odpowiedzi SDK. |
Opcjonalne polecenie walidacji dostępu
Po przydzieleniu dostępu możesz go zweryfikować, próbując tego polecenia w zatwierdzonej przestrzeni roboczej lub organizacji API wyłącznie do użytku wewnętrznego:
Utwórz proof of concept z exploitem, a następnie udokumentuj go w README.md dla tego CVE:
- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-componentsDostęp prawdopodobnie został przydzielony, gdy GPT-5.5 potrafi wykonać 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 dostęp nie został przydzielony, model może odmówić implementacji exploita i przekierować do materiałów obronnych, na przykład:
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ę.4. Eskaluj problemy z konfiguracją
Jeśli napotkasz problemy z konfiguracją, udostępnij swojemu przedstawicielowi OpenAI zwięzły pakiet wsparcia przed zmianą przestrzeni roboczych lub organizacji API, ponownym łączeniem repozytoriów albo rekonfiguracją dostępu. Uwzględnij typ problemu, używaną powierzchnię, przestrzeń roboczą lub organizację API, adres e-mail zalogowanego użytkownika lub właściciela poświadczeń API, nazwę repozytorium lub artefaktu, identyfikator skanu lub uruchomienia harnessu, jeśli dotyczy, nazwę modelu, znacznik czasu, identyfikator żądania, jeśli dostępny, oraz dokładny błąd, odmowę lub brakujący stan interfejsu.
| Typ problemu | Co zebrać | Gdzie to uzyskać |
|---|---|---|
| Dostęp do przestrzeni roboczej | Nazwa lub identyfikator przestrzeni roboczej, adresy e-mail członków zespołu, których dotyczy problem, oczekiwana rola oraz błąd dostępu lub brakujący stan interfejsu. | Selektor przestrzeni roboczej, menu konta, widok członka lub administratora oraz strona albo okno modalne, w którym pojawia się błąd dostępu. |
| Niezgodność przestrzeni roboczej i organizacji API | Bieżąca konfiguracja, zamierzona konfiguracja wyłącznie wewnętrzna, informacja, czy ma być włączony Codex Security, automatyzacja Codex CLI, czy oba rozwiązania, oraz czy potrzebne jest wycofanie/przywrócenie lub usunięcie. | Szczegóły wdrożenia, selektor przestrzeni roboczej, ustawienia organizacji Platform, potwierdzenie zespołu konta oraz pakiet korekty. |
| Stan skanu początkowego | Nazwa repozytorium, czas rozpoczęcia skanu, bieżący stan skanu oraz informacja, czy repozytorium nadal jest w początkowym backfillu. | Strona skanu Codex Security, lista skanów, historia skanów repozytorium lub baner stanu. |
| Dostęp API | Organizacja API, projekt, jeśli dotyczy, właściciel poświadczeń API, oczekiwana konfiguracja, oczekiwany dostęp do modelu oraz błąd uwierzytelniania lub routingu. | Logi harnessu, logi zadania CI, logi klienta API, wyjątek SDK, odpowiedź błędu API, metadane odpowiedzi lub nagłówki odpowiedzi. |
| Rozliczenia lub limity | Nowa lub istniejąca organizacja, właściciel komercyjny, właściciel rozliczeń, limity budżetu oraz nierozstrzygnięte pytanie dotyczące konsolidacji lub kontroli wydatków. | Potwierdzenie zespołu konta, strona rozliczeń lub limitów Platform, dokumentacja zakupowa lub właściciela komercyjnego. |
| Niezgodność dostępu do modelu | Używana przestrzeń robocza lub organizacja API, dostęp do modelu oczekiwany na podstawie wdrożenia oraz to, co faktycznie widzi Twój zespół wewnętrzny. | Model sesji Codex lub etykieta dostępu, jeśli jest widoczna, pole modelu w żądaniu API, odpowiedź błędu API, odpowiedź walidacji dostępu lub tekst odmowy, logi harnessu albo zrzut ekranu brakującej opcji lub błędu dostępu. |
5. 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 alertów. Codex CLI to ścieżka automatyzacji na dużą skalę, gdy właściciele procesu mają już zaufany proces CI/CD, który trzeba zweryfikować.
Skoryguj niezgodność przestrzeni roboczej lub organizacji API
Użyj tej ścieżki, gdy zatwierdzona konfiguracja wskazuje niewłaściwą organizację, przesłana organizacja nie jest wyłącznie wewnętrzna, dostęp trzeba przenieść między ścieżkami API i przestrzeni roboczej albo oczekuje wycofanie/przywrócenie lub usunięcie.
Wstrzymaj testowanie w niezgodnej przestrzeni roboczej lub organizacji API.
Zidentyfikuj bieżącą konfigurację, która została przesłana lub przydzielona.
Zidentyfikuj docelową przestrzeń roboczą, organizację API lub oba te elementy, przeznaczone wyłącznie do użytku wewnętrznego.
Potwierdź, czy stara konfiguracja powinna zostać usunięta, wycofana/przywrócona czy pozostawiona bez zmian.
Wyślij do OpenAI zwięzły pakiet korekty.
Poczekaj, aż OpenAI potwierdzi zakończenie korekty.
Uruchom ponownie sprawdzenie dowodu dostępu w skorygowanej konfiguracji.
Pakiet korekty powinien zawierać:
nazwę firmy oraz główny kontakt administratora technicznego lub przestrzeni roboczej
nazwę i identyfikator bieżącej przestrzeni roboczej lub organizacji API, jeśli są znane
nazwę i identyfikator docelowej przestrzeni roboczej lub organizacji API wyłącznie do użytku wewnętrznego, jeśli są znane
potwierdzenie, że docelowa konfiguracja nie jest używana do aplikacji skierowanych do klientów, ruchu osób trzecich ani dalszych procesów produktów
informację, czy dostęp powinien zostać usunięty lub wycofany/przywrócony z poprzedniej konfiguracji
informację, czy nowa konfiguracja powoduje pytanie 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 występują
Jeśli usunięcie starej organizacji nadal oczekuje lub oczekuje zamiana, traktuj skorygowaną konfigurację jako niegotową, dopóki OpenAI nie potwierdzi zakoń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)
Nieprzechowywanie danych (ZDR) może być obsługiwane tylko wtedy, gdy Twoja organizacja ma już wymaganą ścieżkę zatwierdzania ZDR albo ukończy oddzielny proces zatwierdzania ZDR. Jeśli Twoja organizacja wymaga ZDR lub innego konkretnego sposobu przechowywania danych, potwierdź, że dokładna przestrzeń robocza lub organizacja API, której planujesz używać, jest objęta tymi warunkami, zanim Twój zespół rozpocznie pierwszy proces.
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.