O czym jest ten film
- Branża przeżywa „czarny październik”: w ciągu 48–72 godzin praktycznie co godzinę wybuchał incydent o najwyższej możliwej wadze (9,5–10 na 10).
- Za falą stoi dziesiątki tysięcy agentów AI — należących do osób, firm i podmiotów państwowych — które przeszukują internet w poszukiwaniu luk i łączą je w coraz groźniejsze łańcuchy ataków; krzywa nowych wpisów CVE rosła łagodnie przez 25 lat, teraz skoczyła pionowo.
- PHP, fundament około 70 procent internetu, dostało dwie podatności z maksymalną oceną — zdalne wykonanie kodu bez logowania; szczegóły exploitów wyciekły około 15 godzin przed wydaniem łatki.
- Skalę pokazuje Cloudflare: tysiące prób wykorzystania luki przed publicznym ostrzeżeniem, dziesiątki tysięcy w 45 minut po nim, setki tysięcy po dwóch godzinach, dziś — miliony atakujących.
- Do kompletu: krytyczna podatność w GitLabie ukryta przez 12 lat oraz 30 poważnych luk w jednym dniu w PHP, Node.js, Nginx, Go, GitLab i Moodle.
- eMudhra, indyjski wystawca certyfikatów, losowała klucze prywatne z zakresu 0–256 zamiast spośród 2^256 możliwych wartości; jeden z „tajnych” kluczy to liczba 4 — dało się podrobić certyfikat dowolnej strony, także banku.
- Railway, platforma wdrożeniowa, przegrała z atakiem na magazyn sekretów: część kluczy klientów leżała odszyfrowana, klucze API rozkradano, a stare sekrety nigdy nie były czyszczone.
- Teza autora: jedyną sensowną obroną są automatyczne pętle agentów, które nieustannie „atakują” własny kod — w chmurze, także gdy laptop jest zamknięty.
- Architektura podwójnej kontroli: jeden model szuka błędów, drugi — z konkurencyjnej firmy — weryfikuje znaleziska jak sceptyczny recenzent; fałszywe alarmy znikają same.
- Prognozy: masowe odchudzanie zależności, coraz więcej krytycznych luk każdego dnia, a w perspektywie 6–12 miesięcy pętle bezpieczeństwa jako standard — ich brak autor nazywa rażącym zaniedbaniem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przegląd przez najsilniejszy model przed każdym wdrożeniem
Na czym polega: Kod pisany przez agentów AI wymaga przeglądu bezpieczeństwa wykonanego przez model z absolutnej czołówki (obecnie Opus 5.5 i GPT-6.1 Soul), ustawiony na maksymalny poziom rozumowania. Taki przegląd wyłapuje to, co najłatwiejsze do zaatakowania: oczywiste podatności i podstawowe zaniedbania.
Jak stosować: Zanim cokolwiek trafi na produkcję, przepuść kod przez najlepszy model Anthropic i najlepszy model OpenAI. Przy krytycznych komponentach użyj obu po kolei — każdy zauważy co innego.
Na co uważać: Do tego celu nie nadaje się tani lokalny model rzędu 20 miliardów parametrów. I pamiętaj: to zabezpieczenie jednorazowe — nowa luka w zależności może pojawić się jutro, więc przegląd przed wdrożeniem nie zwalnia z ciągłego monitorowania.
2.Pętla na łańcuch dostaw: łataj w minuty, nie w dni
Na czym polega: Nowe podatności w bibliotekach są dziś ogłaszane niemal co godzinę. Pętla przeglądu łańcucha dostaw co kilkanaście–kilkadziesiąt minut przeszukuje Twittera/X, GitHuba i serwisy informacyjne przez interfejs scrapujący; gdy pojawia się luka dotykająca twoich zależności, analizuje całą bazę kodu i wprowadza (lub proponuje) łatkę.
Jak stosować: Tę pętlę autor zaleca puszczać w pełni autonomicznie — liczy się czas od publikacji zgłoszenia do łatki. Do samego skanowania wystarczą tańsze modele (Sonnet 5.5, Haiku 5.5, DeepSeek Flash); najsilniejszy model zużywaj tylko do analizy i naprawy.
Na co uważać: Koszt tokenów przy agresywnym interwale (np. 5 minut) — dlatego rozdzielaj model do skanowania od modelu do naprawy. Drobne poprawki można wypychać automatycznie, poważniejsze — tylko z twoją aprobatą.
3.Podziel kod na sekcje i każdemu fragmentowi przydziel osobną pętlę
Na czym polega: Jeden agent nie obejmie całej bazy kodu tak dobrze jak kilka wąsko nastawionych pętli. Autor dzieli kod na 5–10 sekcji (rozliczenia, uwierzytelnianie, frontend, backend, API) i każdej przypisuje pętlę skupioną wyłącznie na niej, uruchamianą co 1–4 godziny, a przy krytycznych fragmentach nawet co 5 minut.
Jak stosować: Zacznij od generalnego przeglądu bezpieczeństwa całej bazy (priorytet P1), potem dokładaj pętle sekcyjne. Prompt nie musi być długi: wskaż fragment kodu i zadanie. Pętla ma działać w chmurze — niezależnie od tego, czy twój laptop jest otwarty.
Na co uważać: Zabezpieczenie, które działa „jak pamiętam”, nie jest zabezpieczeniem. Uważaj też na zasypywanie siebie wątkami — pętla powinna sama archiwizować puste przebiegi i zostawiać otwarte wyłącznie realne znaleziska.
4.Sceptyczny recenzent odsiewa fałszywe alarmy
Na czym polega: Model poproszony o szukanie błędów zawsze coś znajdzie — nawet tam, gdzie poważnych błędów nie ma, bo chce dotrzymać „obietnicy” z promptu. Dlatego po głównym agencie (np. Opus) uruchamiany jest drugi model z innej firmy (np. GPT-6.1 Soul) w roli recenzenta z poleceniem: „załóż, że to może być przewrażliwienie; jeśli bug jest realny, zostaw otwarte”.
Jak stosować: Gdy oba modele się zgodzą, znalezisko trafia do ciebie z gotową poprawką; gdy recenzent je odrzuci, oba wątki archiwizują się same i nic nie zabiera ci czasu. Poziom rozumowania ustawiaj na bardzo wysoki lub maksymalny i rotuj role — dziś główny jest Opus, jutro GPT.
Na co uważać: Recenzent z tej samej „rodziny” modeli co główny agent wychwyci mniej błędów typowych dla całej rodziny — różnorodność firm jest tu celem, nie kaprysem.
5.Rotuj modele — każdy widzi inne luki
Na czym polega: Różne modele znajdują różne rodzaje błędów, zupełnie jak różni ludzcy audytorzy. Autor cyklicznie zmienia głównego agenta (Opus → GPT → Muse) i do recenzji włącza coraz szerszą paletę: modele Mety (Muse Wander), zapowiadanego Kimi K3.1, tańsze DeepSeeki.
Jak stosować: Przygotuj zestaw 5–10 modeli od różnych firm i przydzielaj je do różnych sekcji kodu oraz rotacji w roli recenzenta. Model „niemal z czołówki” wystarczy do mniej wrażliwych repozytoriów.
Na co uważać: Najlepszy dostępny model rezerwuj dla najważniejszych baz kodu. Oszczędności na modelach do skanowania są w porządku; oszczędności na modelu do analizy krytycznej — nie.
6.Każda zależność to kolejne drzwi dla atakującego
Na czym polega: Skoro modele AI napiszą potrzebny komponent na życzenie, równowaga „gotowa biblioteka czy własny kod” przechyla się ku własnemu kodowi. Każda zależność powiększa powierzchnię ataku i każdą trzeba audytować, gdy pojawi się w niej luka.
Jak stosować: Uruchom cykliczną pętlę „diety zależności”, która wylicza, co można usunąć i czym zastąpić własnym kodem — u autora rezygnacja z trzech bibliotek zdejmuje z projektu odpowiednio 21, 18 i 13 pakietów.
Na co uważać: Nie rzucaj się na „zero zależności” z dnia na dzień — sprawdzona, dobrze utrzymywana biblioteka nadal bywa lepszym wyborem niż własny kod. Decyduj pojedynczo, ważąc koszt utrzymania przeciwko ryzyku.
7.Szyfruj sekrety, czyść martwe klucze, rotuj po każdym incydencie
Na czym polega: Incydent Railway ujawnił trzy klasyczne zaniedbania: sekrety klientów przechowywane częściowo w formie odszyfrowanej, tysiące kluczy w jednym scentralizowanym systemie oraz stare, nieużywane klucze, których nikt nigdy nie usuwał.
Jak stosować: Jeśli prowadzisz jakąkolwiek platformę: szyfruj hasła i klucze (to absolutna podstawa, znana od dekad), uruchom automatyczne czyszczenie nieużywanych sekretów, a po włamaniu każ klientom — i sobie — rotować wszystkie klucze, także w zmiennych środowiskowych wdrożeń.
Na co uważać: Centralny magazyn sekretów to pojedynczy punkt awarii dla wszystkich klientów naraz. Funkcja „przynieś własny klucz” też nie jest darmowa — klucze API bywają atakowane wprost, na przykład w celu nielegalnej destylacji modeli.
8.Jednorazowy audyt na dziś: lista podatności plus najsilniejszy model
Na czym polega: Autor zaleca szybką akcję dla każdego, kto korzysta z dotkniętych narzędzi: zrób zrzut ekranu aktualnej listy podatności, pokaż go modelowi z czołówki i każ mu się ich „nauczyć”, przeskanować cały komputer i wszystkie projekty oraz wskazać, co wymaga łatania.
Jak stosować: Metoda działa przy każdej nowej fali luk — źródłem listy mogą być bieżące komunikaty bezpieczeństwa (CVE) i serwisy branżowe. Wykonaj raz, dokładnie, dziś.
Na co uważać: To zastrzyk jednorazowy. Bez automatyzacji z punktów 2–4 za kilka dni twoja wiedza o zagrożeniach znowu będzie nieaktualna — a fala, wbrew nadziejom, nie opada.
9.Pętla działa zawsze, ekspert sprawdza raz
Na czym polega: Człowiek-audytor, nawet bardzo dobry, wykona przegląd jednorazowo i odejdzie. Pętla agentów uruchomiona raz pracuje bez końca, za ułamek kosztu — tańsze modele do rutyny, najmocniejsze do analiz krytycznych.
Jak stosować: Zacznij minimalnie: dwie pętle (generalny przegląd bezpieczeństwa oraz przegląd łańcucha dostaw) na repozytoria, które realnie mają znaczenie. Rozbudowuj dopiero, gdy pierwsza zadziała.
Na co uważać: Nie odkładaj tego „na spokojniej”: autor wprost nazywa brak takich pętli rażącym zaniedbaniem, a okno na przewagę zamyka się w skali miesięcy, gdy praktyka stanie się standardem.
10.Automatyzacja bezpieczeństwa to nowa normalność, nie epizod
Na czym polega: Krzywa odkrywanych podatności nie wraca do dawnego trendu — pieli się w górę. Autor przewiduje 3–6 miesięcy przejściowego chaosu, po których odpalanie „maksimum agentów na własnym kodzie” stanie się powszechnie przyjętym standardem.
Jak stosować: Traktuj ciągłe, zautomatyzowane testy bezpieczeństwa jako stały element infrastruktury — tak jak backupy czy monitoring — z budżetem na tokeny i przypisanym właścicielem.
Na co uważać: Na myślenie „wróci do normy” i na rezygnację z automatyzacji po pierwszym spokojnym tygodniu. Pytanie nie brzmi „czy dołączyć”, tylko „kiedy” — zanim zrobi się to za ciebie, w najgorszym sensie.
Redakcyjne tłumaczenie
„Czarny październik”: 48 godzin, po których nic nie jest takie jak przedtem
Nazywam się David Ondrej i hakerstwo wspomagane sztuczną inteligencją właśnie przestało być prognozą. Przeszliśmy chyba najbardziej szalone 48 godzin w historii cyberbezpieczeństwa. Ludzie nazywają je już „czarnym październikiem” — ze względu na liczbę podatności, exploitów i włamań, a przede wszystkim na ich wagę. Praktycznie co godzinę, przez ostatnie dwa, trzy dni, wybuchał incydent o wadze 9,5–10 na 10.
Co się dzieje? Po internecie pełza dziś tysiące, a pewnie i dziesiątki tysięcy agentów AI — należących do pojedynczych ludzi, firm i podmiotów państwowych — które nieustannie przeszukują sieć i szukają słabych punktów w każdym napotkanym oprogramowaniu. Popatrzcie na wykres liczby CVE, czyli nowych wpisów w publicznym rejestrze znanych luk bezpieczeństwa, prowadzony od 25 lat. Krzywa, przez dekady łagodna, w ostatnich miesiącach — a szczególnie w ostatnich dwóch dobach — poszła pionowo w górę. Cyberbezpieczeństwo przeżywa przez to boom, ale zarazem ogromna część oprogramowania, również tego, które piszemy ty i ja, przestaje być bezpieczna.
W samym tylko jednym dniu odkryto trzydzieści poważnych podatności: w PHP, Node.js, Nginx, Go, GitLab i Moodle. W tym materiale rozbiorę trzy najcięższe przypadki — lukę w PHP dającą atakującemu powłokę na serwerze, aferę certyfikatów eMudhra oraz incydent na platformie Railway. Wyjaśnię, co poszło nie tak w każdym z nich, a potem pokażę moje pętle agentów (ang. agent loops), czyli cyklicznie uruchamiane, w pełni automatyczne zadania powierzane agentom AI — pracują one u mnie na okrągło, na wszystkich repozytoriach i bazach kodu. Wchodzimy w czasy tak bezprecedensowe, że nikt nie wie, jak będą wyglądać. Dosłownie roje agentów atakują dziś całe oprogramowanie świata. Jedyna rozsądna obrona: własne roje agentów, które znajdą dziury w twoim kodzie szybciej niż czyjś.
PHP: dwie „dziesiątki” i piętnaście godzin przewagi atakujących
Trudno wskazać najgorszy incydent — wszystkie były koszmarne — ale te w PHP należą do czołówki. Dla mniej technicznych: PHP to język programowania, który w jakiejś formie napędza około 70 procent internetu. Ujawniono w nim dwie podatności z maksymalną oceną. I nie był to drobiazg: zdalne wykonanie kodu, czyli możliwość uruchomienia dowolnego kodu na cudzym serwerze bez logowania. To samo w sobie katastrofa, ale doszło do tego coś gorszego — szczegóły exploitów wyciekły mniej więcej piętnaście godzin przed wydaniem łatki. Piętnaście godzin, w których atakujący mogli działać, a administratorzy nie mieli czym się bronić.
Sprawa dotyczy każdego serwera WordPress, MediaWiki — a więc Wikipedii — Magento, Laravela i wielu innych aplikacji. Szef Cloudflare mówi wprost o milionach prób. Konkretne liczby z tej sieci, na której stoi dziesiątki milionów stron: w ciągu dziesięciu godzin przed publicznym ogłoszeniem luki odnotowano tysiące prób jej wykorzystania. W 45 minut po ogłoszeniu — dziesiątki tysięcy. Po dwóch godzinach — setki tysięcy. Dziś po serwery PHP dobierają się miliony różnych przestępców.
Do kompletu doszła jeszcze krytyczna podatność w GitLabie, siedząca w kodzie niezauważona od dwunastu lat i dotykająca znacznej części wdrożeń tej platformy. Każdy z tych incydentów w każdym wcześniejszym roku byłby historią roku w cyberbezpieczeństwie — a tu wszystkie spadły na nas w ciągu 48 godzin. Cztery niezależne zespoły namierzyły bugi w PHP z pomocą agentów AI. Nic dziwnego: z agentami można przejrzeć niewyobrażalnie więcej potencjalnych błędów, a dodatkowo łączyć pojedyncze luki w łańcuchy i eskalować je do coraz groźniejszych ataków.
Pierwsza rada: najmocniejszy model na przegląd, zanim cokolwiek wdrożysz
Zanim przejdę do zaawansowanych mechanizmów, najprostsza praktyczna wskazówka. Cokolwiek budujecie — a budujecie przecież z agentami AI — przed wdrożeniem na produkcję przepuszczajcie kod przez najlepszy dostępny model: najmocniejszy model Anthropic i najmocniejszy model OpenAI, oba na maksymalnym poziomie rozumowania. Nie chodzi o wyłapanie wszystkiego, tylko o zebranie tego, co najłatwiejsze: oczywistych podatności i podstawowych zaniedbań. Dwie rzeczy są kluczowe: model klasy frontier, czyli ścisła czołówka, oraz maksymalne rozumowanie. Tańszy lokalny model dwudziestomiliardowy się nie nadaje.
Pętle agentów: obrona, która nie śpi
Teraz pokażę, jak konkretnie chronię własny kod, oprogramowanie i firmy — pętlami agentów, które bez przerwy atakują moje repozytoria. Bo jeśli ktoś puszcza rój agentów na twoją firmę i twój produkt, musisz robić dokładnie to samo: znajdować dziury, zanim zrobi to on.
Wchodzę w Cloudroom — w lewym górnym rogu jest zakładka z pętlami. Widać wszystkie moje aktywne pętle, rozpisane na dwa priorytety. Pierwsza z nich: test bezpieczeństwa aplikacji webowych. Uruchamia się co cztery godziny i korzysta z Opusa 5.5 — w wersji z kontekstem miliona tokenów, na maksymalnym poziomie rozumowania. Podkreślam: model musi być z czołówki. Obecnie po stronie Anthropic to Opus 5.5, po stronie OpenAI — GPT-6 Astra albo GPT-6.1 Soul, przy czym Soul wydaje mi się odrobinę lepszy, choć to zależy od zastosowania. A przy najgroźniejszych sprawach? Używam obu. Za chwilę pokażę, jak je łączyć i kiedy które.
Najważniejsze, że to pętle chmurowe: ruszają nawet wtedy, gdy mój MacBook jest zamknięty. Zabezpieczenia muszą działać zawsze — inaczej nie istnieją. I zresztą zabawna odwrócona logika: dwanaście, osiemnaście miesięcy temu nieodpowiedzialnym było, gdy ktoś powierzał przegląd całego kodu agentom AI. Dziś nieodpowiedzialne jest, gdy tego nie robi.
Sedno metody: dzielisz bazę kodu na pięć–dziesięć sekcji, a pętla krąży między nimi i testuje je po kolei. Ta, o której mówię, robi pełne okrążenie co cztery godziny; maksymalne rozumowanie, najlepszy model Anthropic, prosty harmonogram, priorytet pierwszy. A prompt? Krótki. Nie potrzebujecie długich instrukcji — wystarczy wskazać modelowi konkretny fragment kodu i powiedzieć, co ma zrobić. Każde uruchomienie pętli otwiera nowy wątek; jeśli nic nie znajdzie, wątek sam się archiwizuje i pasek boczny nie zarasta pustymi rozmowami. Jeśli znajdzie coś wartego naprawy — zostaje otwarty i czeka na twój przegląd. Pod koniec pokażę też, jak zbudować pętle w pełni samodzielne: same naprawiają i wypychają zmiany prosto na GitHub, a nawet na produkcję — jeśli tak zechcesz.
Wojna o zależności
Druga pętla: czuwanie nad zależnościami — sprawdza wszystko, co zewnętrzne, w moich projektach. I tu prognoza, w którą wierzę bez zastrzeżeń: zobaczymy coraz więcej osób budujących oprogramowanie od zera, z możliwie minimalną liczbą zależności. Kiedyś pakiet albo gotowa biblioteka oszczędzały czas — brałeś dopracowany komponent i jechałeś dalej. Dziś wystarczy opisać zadanie Opusowi, Astrze albo GPT-6, a model zbuduje dokładnie to, czego potrzebujesz; granicą jest wyłącznie wyobraźnia. W tym nowym układzie tysiące zależności w projekcie to nie oszczędność, lecz balast i ryzyko: każda z nich to kolejne drzwi dla atakującego. Nie zniknie to z dnia na dzień i nieraz biblioteka wciąż będzie uzasadniona, ale czekają nas masowe audyty całych systemów, których celem będzie wyrzucenie z projektów możliwie największej liczby obcych komponentów — bo każda zależność powiększa powierzchnię ataku, czyli liczbę sposobów, w jakie można cię uderzyć.
Mam dwie pętle do spraw zależności. Ta pierwsza co pół godziny przemierza Twittera przez Deep API — szczerze mówiąc, powinienem przyspieszyć do dziesięciu minut — i gdy tylko pojawia się podatność, analizuje całą bazę kodu i od razu ją łata. Właśnie tę pętlę polecam puszczać w pełni autonomicznie: w takich sprawach liczy się czas od zgłoszenia do łatki.
eMudhra: gdy kluczem prywatnym jest liczba cztery
Teraz historia, którą uważam za najdzikszą ze wszystkich — być może najgorszą w dziejach cyberbezpieczeństwa, bo nic podobnego się wcześniej nie wydarzyło. eMudhra, indyjska firma wystawiająca certyfikaty internetowe, po prostu zawaliła sprawę; nie umiem tego określić inaczej niż rażącą niekompetencją na wielką skalę.
(Informacja dodatkowa: eMudhra to indyjski urząd certyfikacji — firma, której wystawione certyfikaty przeglądarki uznają automatycznie za wiarygodne.)
Firma wystawiała certyfikaty, a każdy klucz prywatny powinien być w nich liczbą o 116 cyfrach, wypisaną z przestrzeni rzędu dwóch do potęgi 256 możliwych wartości — tylu kombinacji, że odgadnięcie jest praktycznie niemożliwe. Tymczasem eMudhra losowała liczby od zera do 256. Jeden z kluczy prywatnych to była po prostu czwórka. Cztery!
Skutek: przez tę niekompetencję oberwała połowa internetu. Sam spędziłem wiele godzin na łataniu oprogramowania i aktualizacji zależności. Bo skoro każdy może podrobić taki certyfikat — zwłaszcza gdy „tajny” klucz to czwórka — każdy może udawać ciebie albo administratora przy wejściu na stronę. Mechanizm jest prosty: przeglądarka — Chrome, Brave, Safari — ufa stronom na podstawie certyfikatów. Jeśli twój wystawiła eMudhra, a było to twoje nieszczęście, każdy mógł posłużyć się „kluczem numer cztery” albo innym, równie żałosnym, podrobić certyfikat, podszyć się pod ciebie albo wejść do twojej aplikacji. Osiem z tych kluczy to mikroskopijne wartości, wszystkie mieściły się w przedziale od zera do 256 — po prostu nie wiedzieli, co robią. Dało się podrobić każdą stronę: twój bank, twoją pocztę, cokolwiek.
Narzędzie, w którym to wszystko uruchamiam
Zanim pokażę kolejne pętle, słowo o tym, co oglądacie. Cloudroom to narzędzie, które sam zbudowałem. Jest w pełni open source, a start nie kosztuje nic. To środowisko programistyczne dla agentów AI — i, o ile wiem, jedyne na świecie, w którym agenty chmurowe uruchomisz za darmo: darmowy plan jest darmowy na zawsze, a każdy agent działa we własnej, odizolowanej piaskownicy. Nikt przed nami tego nie rozgryzł. Jesteśmy też pierwsi w obsłudze dowolnego harnessu — czyli silnika, w którym pracuje agent: Hermes, Spy, Codex czy Claude. Podłączasz ulubione modele, ulubione środowisko i subskrypcje, które już opłacasz.
Można w nim po prostu kodować, rozmawiając z agentami jak dotychczas, ale prawdziwa przyszłość tkwi w pętlach agentów i fabrykach oprogramowania. Za chwilę nie będziemy odblokowywać jednego agenta naraz — będziemy zarządzać całymi pętlami, orkiestrować je i pilnować, żeby nasza fabryka kodu dostarczała go coraz lepszej jakości, wyłapywała więcej błędów i chroniła nas samych. I ostatnie: dziś uruchomiliśmy szablony. Każdą pętlę z tego filmu dodasz do własnego repozytorium jednym kliknięciem, również na darmowym planie. Chcesz zacząć chronić swój biznes i swój kod? Pobierz Cloudroom — projekt jest open source, znajdziesz go na GitHubie i możesz go wręcz przetestować atakiem własnych agentów.
Przegląd łańcucha dostaw i dieta zależności: jak to wygląda w praktyce
Wróćmy do pętli. Przegląd łańcucha dostaw pilnuje ataków na zależności i korzysta z Deep API — narzędzia, które zbudowałem przed Cloudroom. To zestaw scraperów na Twittera, GitHuba i serwisy informacyjne, znajdujący takie historie dosłownie w minuty, a agent korzysta z nich przez jedno API. Zauważcie przy okazji, co robią agenty: piszą sobie skrypty powłoki, żeby nie przepisywać tego samego kodu przy każdym uruchomieniu — bo każde przejście pętli to przecież nowy wątek.
Zwykle ta pętla rusza co godzinę, ale po ostatnich 48 godzinach przyspieszę ją — chyba dosłownie do pięciu minut. Oczywistym ograniczeniem są tokeny, więc Opus 5.5 nie musi napędzać wszystkiego; zostawcie go dla najważniejszych pętli. Poziom niżej mamy dziś bardzo porządne modele: do samego skanowania i wyszukiwania wystarczy Sonnet 5.5, GPT-6 Luna, Haiku 5.5 albo DeepSeek V4.1 Flash 1017 — kto u nich wymyśla nazwy, powinien dostać naganę, wystarczyło V4.2 Flash. Model ma tu mniejsze znaczenie: byle dobry, z czołówki lub tuż obok niej, z dostępem do interfejsu scrapującego i uruchamiany często.
Jak to wygląda w praktyce? Przegląd bezpieczeństwa zwraca listę najbardziej ryzykownych miejsc — u mnie na przykład self-hosted runner CI. A pętla „Dependency Diet” podpowiada, co mógłbym wyrzucić: TypeScript 7, remark-gfm, recharts — rezygnacja z nich zdjęłaby z projektu odpowiednio 21, 18 i 13 pakietów, które można zastąpić własnym kodem, w pełni pod moją kontrolą i możliwie najniższego poziomu. Sedno w tym, że wszystko działa autonomicznie, na pętlach, które sam projektujesz.
Railway: lekcja przechowywania sekretów klientów
Trzeci incydent, równie ciężki jak poprzednie: Railway — platforma do wdrażania aplikacji, głównie backendowych, choć spokojnie także frontendów czy cache Redis. Scenariusz bardzo podobny do tego z mojego filmu o Open Code sprzed kilku dni, gdzie również doszło do ataku na klucze użytkowników: sporo osób korzystało tam z trybu „przynieś własny klucz”, wpisywało klucze API OpenAI i Anthropic — i właśnie te klucze stały się celem, bo pozwalały „destylować” modele na cudzy koszt.
(Informacja dodatkowa: Open Code to otwarte narzędzie do programowania z agentami AI; kilka dni wcześniej autor opisał na kanale włamanie wymierzone w klucze API jego użytkowników. Destylacja — tutaj: masowe odpytywanie cudzych modeli na skradzionych kluczach, na przykład po to, żeby z ich odpowiedzi zbudować własny model.)
Zanim opowiem, co się stało, rada natychmiastowa, tycząca się zresztą całego materiału: jeśli korzystacie z Railway, przepuśćcie przez najlepszy dostępny model — idealnie Opusa 5.5 na maksymalnym rozumowaniu — najpierw swój komputer, a potem wszystkie repozytoria. I dosłownie: zróbcie zrzut ekranu listy podatności z tego wideo, pokażcie go modelowi i każcie mu się ich nauczyć, przeskanować cały sprzęt i całe oprogramowanie oraz wskazać, co wymaga łatania. To jednorazowa akcja — zróbcie ją dziś. Ale ostrzegam: będzie tylko gorzej. Chyba że chcesz co noc nie spać, ręcznie łatać wszystko i pilnować, czy klienci nie zostali zhakowani — musisz to zautomatyzować pętlami agentów.
A co się wydarzyło? Platforma zaczęła mieć przerwy w działaniu, a klienci zgłaszali, że ktoś rozkrada ich klucze API — zużywa je na ich koszt. Wdrożenia leżały, więc nie dało się nawet ponownie wdrożyć; jedynym wyjściem była natychmiastowa rotacja wszystkich kluczy. To był bardzo zły incydent i sporo osób przewiduje, że może okazać się końcem Railway — bo firma jeszcze wcześniej w tym roku otwarcie chwaliła się, że dla szybkości wdrażania pomija część kroków bezpieczeństwa. Łatwy łup: mnóstwo klientów, podobnie jak w przypadku OpenCode. Jeden z użytkowników obudził się z powiadomieniem „twoje konto AWS mogło zostać przejęte” — i wszystko sprowadzało się do Railway. Screenshotów mam za dużo, żeby pokazać je wszystkie.
Mechanizm wygląda tak: firmy wdrażają swoje projekty na Railway, a razem z nimi zmienne środowiskowe — klucze OpenAI, adresy baz danych, sekrety Stripe, AWS, OpenRouter, Anthropic, cokolwiek. Przy włamaniu takie klucze mogą wyciec. W idealnym świecie byłyby zaszyfrowane, zabezpieczone, odseparowane albo zdecentralizowane; jest na to wiele sposobów, choć każdy zwykle coś kosztuje w wygodzie. Railway najwyraźniej nie miał odpowiednich zabezpieczeń, więc wyciek był ciężki.
Atakujący dotarł do systemu przechowującego sekrety klientów — a część z nich była odszyfrowana. Dotykamy tu absolutnych podstaw cyberbezpieczeństwa, znanych od 20–30 lat: przechowujesz hasła albo klucze API — szyfrujesz. Nie może być tabeli, w której login leży obok hasła jawnym tekstem. Hasła i wrażliwe dane klientów muszą być zaszyfrowane. Kropka.
Railway zażądał od użytkowników rotacji wszystkich kluczy we wszystkich wdrożeniach. Problem był jednak strukturalny: jedna, scentralizowana platforma trzymała tysiące kluczy API w jednym miejscu, a stare klucze nigdy nie były usuwane — leżały w martwych usługach, bez żadnego automatycznego sprzątania. Można powiedzieć, że to wina klientów, ale jeśli prowadzisz platformę wdrożeniową, powinieneś mieć na to gotowe mechanizmy.
Pętla pierwszego priorytetu: generalny przegląd bezpieczeństwa
Pokażę teraz pętlę, którą uważam za jedną z najważniejszych: generalny przegląd bezpieczeństwa. Jest w szablonach — jednym kliknięciem dodasz ją do dowolnego repozytorium i powinieneś dodać do wszystkich, które mają znaczenie. Na najważniejszych — firmowych, prywatnych — puszczasz najsilniejszy model, jak Opus 5.5; na mniej wrażliwych wystarczy Sonnet 5.5 albo DeepSeek Flash. Ale coś musisz uruchomić. Jakiś model AI ma pracować cały czas — co godzinę, co dwie, czasem co pięć minut — i szukać błędów, wad i dziur w różnych częściach kodu: w rozliczeniach, w uwierzytelnianiu, we frontendzie, w backendzie, w API. Podziel bazę kodu na pięć–dziesięć sekcji, żeby każda pętla była wąska i skupiona wyłącznie na swoim fragmencie.
Prompt, jak mówiłem, jest prosty. Szablon przychodzi z już wybranym modelem, poziomem rozumowania, harnessem, częstotliwością i promptem. Jeśli pętla nic nie znajdzie, archiwizuje się i nie zaśmieca paska bocznego; zostaje tylko wtedy, gdy trafi na coś poważnego — z gotową poprawką i opisem, co robić. Ten generalny przegląd ma u mnie priorytet pierwszy, bo analizuje całą bazę kodu pod kątem najgorszych scenariuszy.
Drugi model w roli recenzenta
Najlepsza architektura, jaką znam, to drugi model w roli recenzenta. Moja pętla krąży między modelami: GPT, potem Opus, potem Muse, znowu GPT. To obecnie ścisła czołówka i warto ją rotować, bo każdy model znajduje co innego — zupełnie jak trzech różnych specjalistów: badacz bezpieczeństwa, inżynier i programista zauważą inne luki.
Jest jeszcze jedno zabezpieczenie, kluczowe dla jakości: ochrona przed fałszywymi alarmami. Narysuję schemat. Główny agent — zwykle Opus — ma dwa wyjścia. Albo nie znajduje nic: wspaniale, kod był bezpieczny. Albo coś znajduje — i tu uwaga: to może być prawdziwy problem, ale może też być przewrażliwieniem albo drobiazgiem. Bo gdy powiesz modelowi „szukaj bugów”, on zawsze coś znajdzie, nawet gdy poważnych błędów nie ma — chce dotrzymać obietnicy, a to siedzi w samej architekturze, w mechanizmie przewidywania kolejnego tokena.
Jak temu zaradzić? Uruchamiasz drugi model — na przykład GPT-6.1 Soul na maksymalnym rozumowaniu — w roli recenzenta nastawionego sceptycznie. Prompt brzmi mniej więcej tak: „sprawdź to i załóż, że to może być przewrażliwienie; jeśli jednak bug jest realny, zostaw otwarte”. Recenzent ocenia: to, co znalazł Opus, jest naprawdę krytyczne i warte naprawy, czy to drobiazg? Jeśli warte — znalezisko wraca do Opusa i czeka na twoją aprobatę. Jeśli nie — oba wątki archiwizują się same. Ty nic nie widzisz, nic nie zabiera ci czasu, a kod został sprawdzony przez dwie czołówki z dwóch konkurencyjnych firm. Dopiero gdy oba modele się zgodzą, można przyjąć, że problem jest prawdziwy. Poziomy rozumowania ustawiaj na bardzo wysoki albo maksymalny. I rotuj, który model jest główny, a który recenzuje.
Różne modele, różne luki
Przy okazji: nie niedoceniajcie nowych modeli Mety, z jej laboratoriów superinteligencji. Muse Wander i Muse Wander Full są naprawdę dobre — należą do światowej czołówki, nie tak mocne jak Opus, ale porównywalne z GPT-6.1 Soul — z powodzeniem użyję ich do recenzji. Kimi szykuje właśnie K3.1, również warto włączyć do rotacji. Chodzi o to, żeby paleta modeli była jak najszersza. Nawet jeśli z danym modelem nie pracuje się najwygodniej — tutaj to bez znaczenia. Przeglądasz kod pod kątem luk bezpieczeństwa, więc im więcej firm w grze — pięć, dziesięć — tym lepiej, bo każda patrzy na inną część kodu innym okiem.
Od czego zacząć dziś
Wiem, że to może przytłaczać, więc upraszczam: w szablonach masz priorytety. P1 — niezbędne, P2 — zalecane; P3 i P4 to miłe dodatki, są ci niepotrzebne. Zacznij od włączenia priorytetowych, ewentualnie jeszcze drugiego poziomu.
Bo to nie jest opcja. To jest przyszłość cyberbezpieczeństwa: roje agentów atakujące twoje własne bazy kodu, znajdujące jak najwięcej problemów i łatające je prewencyjnie, same. W promptach sam decydujesz, czy pętla ma wypychać poprawkę prosto na produkcję, czy zatrzymać się i czekać na ciebie — z opisem problemu i propozycją naprawy. Zależy to od tego, co budujesz, ile masz ludzi w zespole i ilu klientów, a także od samej pętli: drobne rzeczy możesz puszczać w pełni autonomicznie, poważniejsze — półautonomicznie, z twoją aprobatą.
Jeśli masz z tego materiału zapamiętać jedną rzecz: zacznij uruchamiać pętle agentów. Wybierz jedną, dwie i puść je na własny kod. Ich nieużywanie jest dziś po prostu rażącym zaniedbaniem. Przyszłość cyberbezpieczeństwa to nie tylko zatrudnianie ekspertów. Ekspert sprawdzi kod raz: zapłacisz badaczowi kilka tysięcy dolarów, znajdzie luki — a potem wróci do domu, do żony i dzieci, i przestanie się tobą interesować. Pętlę agenta uruchamiasz raz, a działa bez końca. Tak, kosztuje tokeny, ale do większości zadań wystarczą tańsze modele: Sonnet 5.5, Haiku 5.5, DeepSeek Flash. Mnóstwo świetnych modeli jest niemal darmowych — i mogą bez przerwy grzebać w twoim kodzie, szukając błędów i dziur bezpieczeństwa. Pomijanie tego to poważne przeoczenie.
Konkretnie: wejdź na cloudroom.dev i pobierz aplikację. Pełny open source, bardzo hojny plan darmowy — z agentami chmurowymi w pakiecie. Po pobraniu kliknij w lewym górnym rogu zakładkę z pętlami, wybierz szablon — polecam generalny przegląd bezpieczeństwa oraz przegląd łańcucha dostaw — i dodaj go jednym kliknięciem do swoich repozytoriów. To wszystko. Pętla pobierze model i ruszy; jeśli coś znajdzie, zobaczysz to w pasku bocznym, a jeśli nic — sam się zaarchiwizuje i nigdy go nie zobaczysz.
To dopiero początek
Wchodzimy w szalone czasy i jedno mam wam do przekazania: to dopiero początek. Jeśli myślisz, że to były jednorazowe 48 godzin i zaraz wróci normalność — jesteś w poważnym błędzie. Ta krzywa będzie się dalej pięła w górę, a krytycznych podatności będzie przybywać każdego dnia. Moim zdaniem czekają nas trzy–sześć miesięcy przejściowego chaosu, zanim wszyscy zrozumieją, że agenty AI są realnością — że trzeba odpalać maksimum agentów i spalać maksimum tokenów na własnym kodzie, żeby się chronić. Za sześć, dwanaście miesięcy będzie to zupełnie normalne i przyjęte za standard. Pytanie tylko, czy dołączysz do tego grona wcześnie, czy na samym końcu.
Mam nadzieję, że materiał był wartościowy. Życzę wam świetnego, produktywnego tygodnia. Do zobaczenia!