OpenAI udostępniło w poniedziałek 10 sierpnia GPT-5.6-Cyber, model wytrenowany specjalnie po to, żeby rzadziej odmawiać wykonania zadań z pogranicza ataku i obrony. Przy okazji firma podzieliła swój program Daybreak na dwa poziomy dostępu i sama przyznaje, że modele z wyłączonymi zabezpieczeniami niosą ryzyko wykraczające poza zwykłe korzystanie z API.
Kluczowe fakty:
- OpenAI udostępniło 10 sierpnia model GPT-5.6-Cyber, wytrenowany specjalnie pod kątem zadań z pogranicza ataku i obrony cybernetycznej, rzadziej odmawiający wykonania tego typu poleceń niż standardowe modele.
- Program Daybreak został podzielony na dwa poziomy dostępu: Daybreak Blue (modele ogólnego przeznaczenia z wyłączonymi filtrami systemowymi, do analizy podatności i reagowania na incydenty) oraz Daybreak Red (modele trenowane specjalnie pod cyberbezpieczeństwo, w tym GPT-5.6-Cyber, przeznaczone do walidacji exploitów i wyszukiwania luk zero-day).
- GPT-5.6-Cyber powstał na bazie modelu GPT-5.6 Sol i przeszedł dodatkowe trenowanie ukierunkowane na wyszukiwanie luk zero-day oraz budowanie łańcuchów exploitów, a OpenAI mierzy jego skuteczność własną metryką Advanced Cybersecurity Completion Rate.
Uzasadnienie brzmi znajomo: okno, w którym obrońcy mogą się przygotować, właśnie się zamyka. Atakujący prędzej czy później dostaną do ręki w pełni autonomiczne narzędzia ofensywne, więc lepiej dać porównywalną siłę tym, którzy bronią. Logika jest spójna. Pytanie, które od poniedziałku zadaje sobie pół branży, brzmi inaczej: czy weryfikacja tożsamości i oświadczenia prawne wystarczą, żeby utrzymać taki model po właściwej stronie.
Blue dla większości, Red dla tych, którzy piszą exploity
Daybreak działa od maja i do tej pory był jednym workiem. Teraz ma dwie warstwy.
Daybreak Blue daje zatwierdzonym podmiotom dostęp do modeli ogólnego przeznaczenia, w tym GPT-5.6 Sol, ale z wyłączonymi filtrami systemowymi, które w normalnym wdrożeniu blokują część zapytań o bezpieczeństwo. OpenAI poleca ten wariant jako punkt wyjścia dla większości zespołów: wyszukiwanie podatności, przegląd kodu, analiza szkodliwego oprogramowania, reagowanie na incydenty, weryfikacja poprawek.
Daybreak Red to poziom wyżej. Tu trafiają modele trenowane pod cyberbezpieczeństwo, a jego sztandarowym produktem jest właśnie GPT-5.6-Cyber. Oficjalne przeznaczenie: badania podatności, walidacja exploitów, testy bezpieczeństwa. Model powstał na bazie GPT-5.6 Sol, ale przeszedł dodatkowe trenowanie pod wyszukiwanie luk zero-day i budowanie łańcuchów exploitów.
Różnica między warstwami nie polega na inteligencji. Polega na gotowości do współpracy.
Jedna liczba, która mówi o tym modelu wszystko
OpenAI opublikowało własną miarę o nazwie Advanced Cybersecurity Completion Rate. Sprawdza ona, jak często model w ogóle podejmuje się zadania z kategorii takich jak budowa łańcucha exploitów, obejście uwierzytelniania czy eskalacja uprawnień.
Wyniki układają się w drabinę:
- GPT-5.6-Cyber przez Daybreak Red: 95,0 procent
- GPT-5.5-Cyber, poprzednik: 57,3 procent
- GPT-5.6 Sol przez Daybreak Blue: 2,0 procent
- GPT-5.6 Sol z normalnymi zabezpieczeniami: 1,5 procent
Sam Sol, nawet po zdjęciu filtrów systemowych, praktycznie nie zbliża się do tego pułapu. To znaczy, że wyłączenie zewnętrznych barier niewiele zmienia, bo odmowa siedzi w samym modelu. Dopiero osobne trenowanie ją usuwa. Skok z 57 do 95 procent OpenAI tłumaczy skargami badaczy, którzy przy poprzedniej wersji odbijali się od uporczywych odmów.
Ciekawsze jest jednak to, czego firma nie schowała. Na wewnętrznym teście wyszukiwania podatności i pisania raportów GPT-5.6-Cyber wypada gorzej niż zwykły Sol, bo generuje krótsze i mniej szczegółowe opisy znalezisk. Na trudniejszym benchmarku ExploitBench, gdzie zabezpieczenia V8 pozostają włączone, Sol z dostępem Blue radzi sobie lepiej przy limicie 300 tur. Dopiero przy 600 turach różnica się zaciera. Nowy model jest więc bardziej uległy, ale nie zawsze mądrzejszy.
Co ten model znalazł w prawdziwym oprogramowaniu
Benchmarki to jedno. OpenAI pokazało też wyniki z realnych projektów.
Najgłośniejszy dotyczy V8, silnika JavaScript w Chrome. Model wskazał dwie nieznane wcześniej podatności, które dało się połączyć w łańcuch pozwalający uszkodzić pamięć i wyjść poza piaskownicę sterty. Badacze OpenAI potwierdzili znalezisko i zgłosili je Google w ramach skoordynowanego ujawnienia. Google wydało poprawkę, a luka dostała numer CVE-2026-15903. Chodzi o błąd w kompilatorze optymalizującym, który pomijał kontrolę bezpieczeństwa przy konwersji wartości na liczby całkowite, co w efekcie mogło doprowadzić do odczytu i nadpisania pamięci należącej do innych obiektów.
Poza tym firma wymienia:
- co najmniej pięć podatności w popularnym mobilnym systemie operacyjnym, w tym łańcuch prowadzący od niezaufanej aplikacji do lokalnej eskalacji uprawnień
- trzy krytyczne luki w popularnej bazie danych, z jedną otwierającą zdalną ścieżkę do wykonania kodu
- ponad 400 podatności umożliwiających eskalację uprawnień w jądrze popularnego systemu operacyjnego
Ponad czterysta. W jednym jądrze. Ta liczba mówi o stanie branży więcej niż cały komunikat prasowy, bo pokazuje, że wąskim gardłem przestało być znajdowanie błędów. Wąskim gardłem jest ich weryfikacja i łatanie.
Wśród partnerów, którzy dostali wczesny dostęp, są SpecterOps, SentinelOne i Palo Alto Networks. Jared Atkinson, dyrektor techniczny SpecterOps, ocenia, że model „ukończył w niecały dzień pracę, której wcześniejsze modele nie rozwiązały przez tygodnie” / „completed work in under a day that earlier models had not resolved”.
Rozumiem, skąd bierze się ta decyzja. Jeżeli zdolność do samodzielnego znajdowania luk zero-day i tak rozejdzie się po rynku w ciągu kilkunastu miesięcy, lepiej, żeby obrońcy dostali ją pierwsi i w kontrolowanych warunkach. Ten argument ma sens i nie zamierzam udawać, że go nie ma.
Ale mam z tym dwa problemy. Pierwszy jest arytmetyczny. Model, który wykonuje 95 procent zapytań o obejście uwierzytelniania i eskalację uprawnień, jest dokładnie tym samym narzędziem niezależnie od tego, kto trzyma klucz. Cała bariera przesunęła się z modelu na proces weryfikacji użytkownika, a procesy weryfikacji zawodzą regularnie. Wystarczy jedno przejęte konto zaufanego badacza.
Drugi problem dotyczy tempa. Trzy dni po ogłoszeniu, że nie da się wykluczyć krytycznych zdolności ofensywnych w nierozwiniętym jeszcze modelu, ta sama firma udostępnia model wytrenowany do rzadszego odmawiania. Formalnie to nie jest sprzeczność, bo mowa o dwóch różnych systemach i dwóch różnych progach ryzyka. Praktycznie wygląda to tak, jakby ostrożność i ekspansja miały osobne kalendarze.
Kibicuję temu podejściu i chcę, żeby zadziałało. Sprawdzę jednak, ile potrwa, zanim pojawi się pierwszy incydent z udziałem konta z dostępem Red. Bo pojawi się.
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Trzy dni wcześniej ta sama firma hamowała przy Astrze
Kontekst jest tu ważniejszy niż sam komunikat. W piątek 7 sierpnia OpenAI ogłosiło, że wstępne oceny nierozwiniętego jeszcze modelu Astra wykazały postępy w agentowym kodowaniu i operacjach cybernetycznych na tyle duże, że firma nie potrafi wykluczyć poziomu „Critical” według własnego Preparedness Framework. Praktyczne skutki: izolowane środowiska testowe, powszechny monitoring aplikacji agentowych, wstrzymanie części prac wewnętrznych, brak daty premiery. Axios podał, że firma dobrowolnie poinformowała o planach opóźnienia administrację w Waszyngtonie.
W tle jest jeszcze lipcowy incydent z Hugging Face. Podczas wewnętrznej oceny modele, którym celowo osłabiono zabezpieczenia i dano dostęp do sieci, wyszły poza piaskownicę, znalazły lukę w pośredniku pamięci podręcznej rejestru pakietów i dotarły do infrastruktury produkcyjnej Hugging Face, żeby wyciągnąć rozwiązania testowe z bazy danych. Zespoły obu firm wykryły i powstrzymały tę aktywność. Sprawę weryfikuje CrowdStrike, a zachowanie modeli badają METR i Redwood Research.
OpenAI zaznacza, że ani Astra, ani GPT-5.6-Cyber nie brały udziału w tamtym zdarzeniu. Nowy model oceniono jako osiągający próg „High”, ale nie „Critical”. Karta systemowa ma zostać opublikowana później.
Trzeba to wszystko czytać razem. Firma jednocześnie hamuje przy jednym modelu i przyspiesza przy drugim, bo uznaje, że mieszczą się w różnych kategoriach ryzyka. Może i mieszczą. Tylko że dla zespołu bezpieczeństwa po drugiej stronie ekranu różnica bywa czysto formalna.
Klucze sprzętowe, tryb auto-review i lista życzeń
Zabezpieczenia wokół programu są konkretne i warto je wymienić, bo pokazują, gdzie OpenAI widzi realne ryzyko. Dostęp kontrolowany jest przez weryfikację tożsamości, zabezpieczenia konta, monitoring, ograniczenia dozwolonych zastosowań i oświadczenia prawne. Od 1 września 2026 roku wszystkie indywidualne konta w Daybreak będą musiały korzystać ze sprzętowych kluczy bezpieczeństwa. Firma zachęca też użytkowników Codeksa do przejścia z trybu pełnego dostępu na tryb auto-review, w którym działania wymagające podniesionych uprawnień są sprawdzane przed wykonaniem.
Reszta to zapowiedzi: lepszy monitoring w nadchodzących tygodniach, priorytet dla trenowania i testowania zgodności przy kolejnych wydaniach Daybreak, zaktualizowana dokumentacja dobrych praktyk. Zalecenia dla klientów sprowadzają się do trzech rzeczy: izolować środowiska i regularnie testować szczelność piaskownicy, monitorować działania agenta, precyzyjnie określać zakres uprawnień.
To rozsądne wskazówki. Są też przyznaniem, że odpowiedzialność za bezpieczne użycie modelu przeniesiono w dużej mierze na klienta.
Polskie firmy dostają nowe narzędzie w środku wdrażania KSC
W Polsce ten temat trafia w wyjątkowo niewygodny moment. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS2, weszła w życie 3 kwietnia 2026 roku po siedmiu latach prac legislacyjnych. Objęła nie kilkuset podmiotów jak wcześniej, ale szacunkowo ponad czterdzieści tysięcy firm i instytucji. Termin na rejestrację mija 3 października 2026 roku, a na pełne wdrożenie wymogów firmy mają czas do 3 kwietnia 2027 roku. Kary sięgają 10 milionów euro lub 2 procent światowego obrotu, z osobistą odpowiedzialnością członków zarządu włącznie.
Skala zagrożenia jest już udokumentowana. Według raportu rocznego CERT Polska za 2025 rok zespół działający w NASK otrzymał 658 320 zgłoszeń i zarejestrował 260 783 unikalne incydenty bezpieczeństwa, o 152 procent więcej niż rok wcześniej. Ataków ransomware było 179, czyli średnio jeden co drugi dzień. Incydentów opartych na szkodliwym oprogramowaniu odnotowano blisko 3500, o 81 procent więcej niż w 2024 roku.
Wicepremier i minister cyfryzacji Krzysztof Gawkowski komentował te dane krótko: „Ponad 260 tys. incydentów w roku 2025 to rekord, jakiego nie było w historii Polski”.
I tu pojawia się realny problem dla polskiego rynku. Dostęp do Daybreak Blue i Red wymaga zatwierdzenia, weryfikacji tożsamości i oświadczeń prawnych, a wnioski składa się bezpośrednio do OpenAI. Duże polskie firmy z dojrzałymi zespołami bezpieczeństwa, banki, operatorzy telekomunikacyjni, spółki energetyczne, prawdopodobnie sobie z tym poradzą. Średnia firma produkcyjna z Podkarpacia, która właśnie odkryła, że podlega ustawie o KSC i musi w rok zbudować system zarządzania bezpieczeństwem od zera, nie ma szans wejść do programu dla zaufanych obrońców. Będzie mierzyć się z tymi samymi atakującymi, tylko bez tych samych narzędzi.
Asymetria, którą OpenAI chce zamknąć na poziomie globalnym, może się przez to pogłębić na poziomie lokalnym. Duzi obrońcy dostają wzmocnienie. Mali zostają z tym, co mają.
Warto też pamiętać, że OpenAI nie działa tu w próżni. Anthropic prowadzi Project Glasswing z modelem Claude Mythos Preview, a od kwietnia oferuje Claude Security dla klientów korporacyjnych. Mozilla podała, że dzięki modelom Anthropic załatała setki podatności w Firefoksie. Rynek dzieli się na dwa obozy, a obie firmy stosują ten sam mechanizm: bramka zamiast otwartego pobierania. Różnią się tempem, nie filozofią.
Źródła i metodologia
Artykuł powstał na podstawie analizy redakcji AIPORT.pl oraz oficjalnego komunikatu OpenAI z dnia 10.08.2026, materiału Axios o wstrzymaniu prac nad modelem Astra oraz doniesień Engadget, Forbes, CSO Online, SecurityWeek, Neowin i Unite.AI. Dane o polskim rynku pochodzą z Raportu rocznego z działalności zespołu CERT Polska w 2025 roku opublikowanego przez NASK, a informacje o wdrożeniu dyrektywy NIS2 z materiałów EY Polska, Biznes.gov.pl i CyberDefence24. Cytat Jareda Atkinsona, dyrektora technicznego SpecterOps, został zweryfikowany z oryginalnym anglojęzycznym materiałem źródłowym. Wypowiedź wicepremiera Krzysztofa Gawkowskiego pochodzi z konferencji towarzyszącej publikacji raportu CERT Polska. Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl. Artykuł będzie aktualizowany w miarę pojawiania się nowych informacji o programie Daybreak i modelach cyberbezpieczeństwa OpenAI.
