O czym jest ten film
- OpenCode, jedno z najpopularniejszych otwartych narzędzi AI do kodowania (alternatywa dla Claude Code), padło ofiarą jednego z największych włamań w tym roku — dotyczył 1,4% użytkowników jego konsoli, a przy milionach użytkowników to bardzo dużo.
- Chodziło o atak destylacyjny na wielką skalę: skradzione klucze API (OpenAI, Anthropic, Google) posłużyły do masowego „odpompowywania” odpowiedzi topowych modeli w celu wytrenowania własnych.
- Użytkownicy budzili się z podniesionymi rachunkami — od 168 do 1700 dolarów zniknęło z kont w ciągu jednej nocy.
- Wtargnięto przez system legacy, który OpenCode akurat wygaszało; analiza użycia skradzionych kluczy wskazuje na chińskie laboratoria AI.
- To pierwszy tak duży atak destylacyjny wymierzony w zwykłych użytkowników, a nie w wielkie laboratoria — dotąd „destylatorzy” zakładali masowo fałszywe konta u OpenAI i Anthropic.
- Kontekst: Anthropic przyłapała wcześniej DeepSeek, MoonShot i MiniMax na ponad 24 tys. fałszywych kont; w grę weszły NSA, CISA i FBI, a nowe zabezpieczenia Laboratorium zbiły skalę kradzieży średnio z 8800-krotności do 135-krotności „spokojnego dnia”.
- Przykład DeepSeek: nowy model (4.1 Flash 1017) przedstawia się jako ChatGPT, a jego „odcisk” wskazuje GPT-6 Astrę — czyli zdestylował czołowy model OpenAI.
- Autor przywołuje dane a16z: liczba podatności wysokich i krytycznych rośnie lawinowo, a niemal 90% wykorzystanych CVE atakujący eksploatuje w dniu ujawnienia lub wcześniej.
- Recepta autora: autonomiczne pętle agentowe w chmurze — skan bezpieczeństwa, przegląd zależności, kontrola kondycji systemu — działające bez udziału człowieka.
- Sporą część materiału stanowi promocja narzędzia autora, Cloudroom (darmowe, open source), w tym oferta wdrożenia dla firm z zespołami 2–30 osób.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Natychmiast sprawdź, czy atak na OpenCode cię dotyczy
Na czym polega: Włamanie objęło 1,4% użytkowników konsoli; poszkodowani dostali powiadomienia, a ich klucze API mogły przez noc „pracować” na cudzy rachunek.
Jak stosować: Sprawdź skrzynkę mailową powiązaną z kontem OpenCode oraz oficjalne komunikaty projektu; niezależnie od tego przejrzyj zużycie tokenów w konsolach OpenAI, Anthropic i Google za ostatnie dni. Cokolwiek się nie zgadza — unieważnij klucz i wystaw nowy.
Na co uważać: Po każdym głośnym incydencie kwitną phishingowe maile „w sprawie wycieku”. Nie klikaj linków z powiadomień — do konsoli producenta wchodź zawsze bezpośrednio.
2.Atak destylacyjny przestał być problemem samych gigantów
Na czym polega: Destylacja to trenowanie własnego modelu na odpowiedziach cudzego, mocniejszego modelu — wbrew regulaminowi usługi. Dotąd robiono to masowo na wielkich laboratoriach; teraz pierwszy raz na taką skalę sięgnięto po klucze zwykłych użytkowników, bo ruch „z ludzi” trudniej wykryć.
Jak stosować: Przyjmij, że twój klucz API jest atrakcyjnym celem samym w sobie — traktuj go jak dane logowania do konta bankowego.
Na co uważać: Nietypowy wzrost zużycia przy niezmienionym stylu pracy to pierwszy sygnał ostrzegawczy — sprawdzaj billing codziennie, a nie raz na miesiąc.
3.Klucz API to wydatek bez górnej granicy — ustaw limity
Na czym polega: Poszkodowani stracili od 168 do 1700 dolarów w jedną noc. Klucz działa dopóty, dopóki ktoś go nie zatrzyma — a haker użyje go do oporu.
Jak stosować: W każdej konsoli ustaw twarde limity miesięczne i alerty progowe. Narzędziom typu „przynieś własny klucz” wystawiaj dedykowane klucze z małym budżetem, nigdy „główny” klucz produkcyjny.
Na co uważać: Klucze w serwisach trzecich trzymaj oddzielnie i regularnie wygaszaj te, których już nie używasz — martwy klucz też może gdzieś żyć w wygaszanym systemie.
4.Ochrona musi działać bez twojego udziału
Na czym polega: Sedno porady autora: bezpieczeństwo uruchamiane ręcznie przychodzi zawsze za późno. Potrzebne są cykliczne, autonomiczne pętle agentowe — np. skan bezpieczeństwa co 2 godziny, przegląd zależności co godzinę, kontrola kondycji systemu co kwadrans.
Jak stosować: Zacznij od jednej pętli na całe repozytorium dwa razy dziennie — zdaniem autora to już wyprzedza 90% ludzi — a potem rozbudowuj.
Na co uważać: Pełną autonomię wdrażaj stopniowo: najpierw tryb „znajdź i zgłoś”, dopiero potem automatyczne naprawianie.
5.Znajdź pięć najsłabszych miejsc i przykryj je osobnymi pętlami
Na czym polega: Jeden agent puszczony na cały kod łatwo się rozprasza — wędruje po tych samych ścieżkach i pomija zakamarki. Autor zaleca podział kodu na sekcje i skoncentrowane pętle dla każdej z nich.
Jak stosować: Zacznij od promptu w rodzaju: „Wskaż pięć największych słabości bezpieczeństwa w tym projekcie — miejsca, które ktoś mógłby wykorzystać”. Potem stwórz dla każdego z nich dedykowaną pętlę.
Na co uważać: Dopasuj model i częstotliwość do wagi sekcji: mniej istotne mogą chodzić rzadziej i na tańszym modelu; sekcji bez zmian od kilku godzin nie trzeba skanować co pół godziny — to tylko spalanie tokenów.
6.Zależności to najczęstsze drzwi dla atakującego
Na czym polega: Większość włamań zaczyna się od skompromitowanego pakietu, który publikuje złośliwą wersję i czeka, aż systemy ofiar się zaktualizują. (Incydent OpenCode to wyjątek — tam pękł ich własny, wygaszany system.)
Jak stosować: Wprowadź automatyczny przegląd zależności: nowe CVE w używanych pakietach, nietypowe skoki wersji, podejrzane zmiany w repozytoriach źródłowych.
Na co uważać: Nie aktualizuj ślepo wszystkiego natychmiast — złośliwy kod bywa w najnowszej wersji. Trzymaj się lockfile’a i czytaj changelogi.
7.Czas reakcji skurczył się do zera — planuj na zero-daye
Na czym polega: Według danych a16z niemal 90% wykorzystanych podatności było eksploatowanych w dniu ujawnienia lub wcześniej; atakujący z LLM-ami uderzają w godziny, czasem w minuty.
Jak stosować: Zamiast modelu „naprawiam po zgłoszeniu” wdrażaj ciągłe automatyczne skanowanie oraz gotowe procedury: izolacja, rollback, unieważnianie kluczy.
Na co uważać: To trend, nie jednorazowy skok — liczba podatności wysokich i krytycznych rośnie lawinowo od początku roku i nic nie zapowiada odwrócenia.
8.Zagrożeniem jest nie tylko twój kod, ale i to, co „zaraz i tak wyłączymy”
Na czym polega: Włamywacze dostali się do systemu legacy, który OpenCode akurat likwidowało — stare systemy często wciąż trzymają żywe klucze i dane.
Jak stosować: W audycie bezpieczeństwa zaczynaj od tego, co odchodzi: stare serwisy, konta, integracje, klucze dostępu. Klucze wygaszaj razem z systemem, nie po nim.
Na co uważać: „To i tak niedługo zostanie wyłączone” to klasyczne zdanie, które poprzedza wycieki.
9.Przeglądaj pracę agentów jak code review
Na czym polega: Przyszłość pracy to według autora zarządzanie pętlami agentów: przegląd wyników, kalibracja czułości, dostrajanie uprawnień i kontekstu — pokazane na przykładach pętli sprawdzających skutki uboczne ostatnich zmian i zgłoszenia użytkowników.
Jak stosować: Każda pętla powinna zostawiać czytelny dziennik. Gdy coś zgłosi, rozstrzygnij: realny problem, nadwrażliwość agenta czy brakujący kontekst (uprawnienia, klucz, prompt systemowy).
Na co uważać: Pętla zbyt czuła mnoży fałszywe alarmy — a przyzwyczajenie do ich ignorowania to prosta droga do przegapienia prawdziwego zagrożenia.
10.Przy „cudownie tanich” modelach sprawdzaj pochodzenie wydajności
Na czym polega: Nowy model DeepSeek w większości testów przedstawiał się jako ChatGPT, a jego odcisk wskazywał GPT-6 Astrę — ślad destylacji czołowego modelu OpenAI. Autor docenia otwarte badania DeepSeek, ale przypomina, że jedno z drugim współistnieje.
Jak stosować: Przy wyborze modelu zadaj pytanie o źródło wydajności i o ryzyko regulacyjne oraz wizerunkowe korzystania z modeli trenowanych wbrew cudzym regulaminom.
Na co uważać: Istnieje też „pasywna” destylacja — teksty generowane przez nowe modele zalewają internet i trafiają do kolejnych treningów — więc granica między „czystym” a „zdestylowanym” modelem systematycznie się zaciera.
Redakcyjne tłumaczenie
Wstęp: włamanie roku w świecie narzędzi AI
OpenCode właśnie padło ofiarą włamania. To jedno z najpopularniejszych narzędzi do programowania z pomocą AI — w praktyce otwartoźródłowa odpowiedź na Claude Code — i właśnie przeżyło jeden z największych wycieków tego roku. Spora część z was jest zapewne dotknięta.
Oto, co napisało oficjalne konto OpenCode: „W nocy doszło u nas do naruszenia bezpieczeństwa związanego z atakiem destylacyjnym na dużą skalę. Objął on 1,4% użytkowników konsoli OpenCode”. Sam procent niewiele mówi — dopóki nie przypomnimy sobie, że z OpenCode korzystają dosłownie miliony ludzi. Jeśli jesteś użytkownikiem, sprawdź skrzynkę mailową: powiadomienia już poszły.
Przygnębiające jest jednak coś innego: to był atak destylacyjny. Nie jednorazowa wpadka, nie dzieło pojedynczego intruza — zorganizowana, masowa operacja. I to trzeba sobie dobrze rozłożyć na czynniki.
Czym jest atak destylacyjny
To wciąż świeży termin, spopularyzowany przede wszystkim przez Anthropic, choć używają go też inne laboratoria. Znaczenie: trenowanie własnych modeli na odpowiedziach cudzego, mocniejszego modelu — wbrew regulaminowi usługi. Bierzesz duży model, na przykład OpenAssistant czy Fable, i „przelewasz” go do modelu mniejszego, dostając za darmo ogromny zasób danych treningowych. To jedna z podstawowych metod pozyskiwania tokenów z bardziej inteligentnych modeli na masową skalę — po to, by zbudować własny model i sprzedawać go taniej.
Od razu nasuwa się pytanie: kto za tym stoi? Do tego wrócimy, gdy przejdziemy przez dowody.
W tym materiale wyjaśnię, co się właściwie stało, dlaczego jest to dopiero czubek góry lodowej, jeśli chodzi o hakerstwo napędzane AI, oraz co to oznacza dla mnie i dla ciebie. Bo skoro OpenCode — wcale nie mała firma — dało się tak włamać, moje i twoje zabezpieczenia są z pewnością jeszcze gorsze. Na końcu pokażę, jak się chronić, i co w tej sprawie robię ja oraz moja firma.
Rano z obciążonymi kontami
Tak wyglądał poranek części użytkowników: nieoczekiwane obciążenia na 200–300 dolarów, u kogoś 168, jednemu zniknęło 1700 dolarów. Z dnia na dzień podskoczyły rachunki za API — a konkretnie za klucze wydane przez OpenAI i Anthropic, które ludzie podpięli do OpenCode w modelu „przynieś własny klucz” (Informacja dodatkowa: popularny schemat, w którym użytkownik sam dostarcza klucz API do narzędzia i sam płaci za zużycie).
Ale pieniądze nie były tu najgorsze. Najgorsze, że to nie był przypadkowy wybór celu, tylko zmasowane, celne uderzenie w OpenCode — jeden z największych startupów AI, z którego korzystają miliony ludzi.
Nowy rozdział: celem ataku zostali zwykli użytkownicy
Kiedyś ataki destylacyjne wymierzano głównie w Anthropic i OpenAI, czyli w wielkie laboratoria. Logika prosta: to one mają najlepsze modele i najwięcej tokenów. Tym razem jednak uderzono w OpenCode — i to otwiera zupełnie nową puszkę Pandory. To pierwszy atak destylacyjny takiej skali, którego celem są konsumenci, czyli ludzie tacy jak ty i ja. Dotychczas „destylatorzy” — a w większości były to chińskie laboratoria — zakładali tysiące kont, by odciągać tokeny z Claude’a i GPT. Teraz sięgają po klucze API zwykłych ludzi i destylują na ich koszt.
Krótka odpowiedź na pytanie, czy jesteś poszkodowany: sprawdź maila, jeśli używasz OpenCode. Dalej w materiale pokażę, jak bronić się przed atakami z użyciem AI, bo klasyczne metody tu nie wystarczą. Jeśli ktoś atakuje cię bez żadnych ograniczeń, otwartymi modelami, musisz do obrony też używać AI. Nie licz, że samodzielnie — ewentualnie z jednym agentem — odeprzesz napastnika dysponującego setką agentów. Poziom cyberobrony trzeba podnieść, więc pokażę, co robię ja, żebyś mógł to po prostu skopiować.
Jak doszło do włamania: system, który miał zniknąć
Wtargnięto do systemu typu legacy — przestarzałej infrastruktury, którą OpenCode właśnie wygaszało. Prawdopodobnie w ciągu kilku dni albo tygodni i tak przestałaby być używana. Tymczasem ktoś ją skompromitował i wyciągnął z niej klucze API — głównie OpenAI, Anthropic i Google. Te trzy podmioty były głównym celem, bo to ich tokeny są na wagę złota.
Pomyśl: gdybyś dziś zakładał nowe laboratorium AI, jakie dane treningowe chciałbyś zdobyć? Pewnie odpowiedzi GPT-6 Astry i GPT-6 Solar, zdecydowanie Opusa 5.5 — to dziś najlepszy model — do tego trochę Fable 5.1 i może Gemini 4 Argon dla urozmaicenia.
Co do sprawców: dowody wskazują na Chiny. Analiza tego, jak wykorzystywano skradzione klucze, pokazała mnóstwo zapytań zadawanych po chińsku.
Atak objął około 1,4% użytkowników, ale dosięgnął nawet pracowników OpenCode. „Moje prywatne konta też są właśnie atakowane” — napisał Dax (Informacja dodatkowa: Dax Raad, znany deweloper open source, jedna z osób stojących za projektem OpenCode). Witamy w nowym świecie, w którym hakerstwo napędza sztuczna inteligencja.
Jeśli nie potraktujesz tego poważnie, prędzej czy później coś u ciebie pęknie: skompromitowany pakiet w którymś z projektów albo ktoś, kto wziął cię na cel. Kto wie? Może nic się nie stanie — ale nie mogę tego obiecać, bo byłoby to kłamstwo. Ataki z użyciem AI cię nie ominą. Ktoś wprzęgnie — w otoczkę agentową — modele bez zabezpieczeń i skieruje je na ciebie lub twoją firmę. Jeśli nie będziesz gotowy, poznasz tę lekcję w najdroższy możliwy sposób.
Jak się broni autor: pierwsze spojrzenie
Aby dać przedsmak mojego podejścia: u mnie w chmurze chodzi kilka pętli agentowych (Informacja dodatkowa: pętla agentowa to automatyczne, cyklicznie uruchamiane zadanie wykonywane przez agenta AI bez udziału człowieka), działających w pełni samodzielnie, na najmocniejszych modelach. Jedna co kwadrans sprawdza kondycję systemu. Druga co godzinę przegląda zależności mojego kodu. Trzecia co dwie godziny wykonuje szeroki skan bezpieczeństwa. Wszystko w narzędziu Cloudroom; wyniki mogę potem przejrzeć na czytelnej osi czasu. Część pętli, gdy znajdą problem, czeka na moją decyzję — reszta radzi sobie całkiem sama.
I przy okazji: szukam dwóch–trzech firm (zespoły od 2 do 30 osób), którym pomogę naprawić cyberbezpieczeństwo i wdrożyć Cloudroom, żeby cały zespół pracował wydajniej. Jeśli poważnie myślisz o ochronie w tej erze agentowego hakerstwa: cloudroom.dev, zakładka z cenami, formularz oferty biznesowej. Wybiorę dwa–trzy najlepiej dopasowane zespoły i będę z nimi pracować bezpośrednio — przez prywatny kanał na Slacku, z dostępem do mnie i całego zespołu programistów. Zgłoszenie nic nie kosztuje, link znajdziesz pod filmem.
Dlaczego akurat OpenCode? Wielkie laboratoria się okopały
Powód jest prosty: giganci — tacy jak Anthropic i OpenAI — odbili ataki i mocno podnieśli własne bezpieczeństwo. Na początku roku Anthropic przyłapała DeepSeek, MoonShot i MiniMax na distylowaniu Claude’a z ponad 24 tysięcy fałszywych kont. Laboratoria dziś mocno się bronią, m.in. za pomocą behawioralnego odcisku palca, którym wykrywają złodziei tokenów i blokują ich konta. W sprawę włączyła się też ciężka artyleria — amerykańskie agencje rządowe: NSA, CISA i FBI — według których chińskie laboratoria pobrały miliardy tokenów.
Pięć dni temu Anthropic opublikowało artykuł o wzmacnianiu obrony przed atakami destylacyjnymi — link pod filmem, bardzo solidna lektura. Najciekawszy jest wykres: po włączeniu nowych zabezpieczeń liczba udanych prób spadła drastycznie. Na osi pionowej widnieje wielokrotność „najspokojniejszego dnia”. Średnio wychodziło 8800-krotność — mówimy więc o skali logarytmicznej, a nie o kilku tokenach. Najgorszy dzień to niemal 56 000-krotność. Po wdrożeniu zabezpieczeń średnia spadła do 135-krotności. Całości nie dało się zatrzymać — to gra w kotka i myszkę i zawsze znajdą się nowe sposoby destylacji.
Wszystko i tak zostanie zdestylowane
Jest jeszcze metoda, o której mało kto myśli, a która wydaje mi się całkiem niebanalna: każdy model z czasem zostanie zdestylowany. Ludzie używają Opusa 5.5 i GPT-6 Astry do pisania — tekstów, maili, postów w mediach społecznościowych. To wszystko trafia do sieci, a sieć jest zeskrobywana przez kolejne generacje modeli. To wolniejsza forma destylacji, bo nie da się kontrolować, co ludzie pytają — ale to nadal destylacja. Za rok internet będzie pełen tokenów Opusa 5.5 i każdy, kto wtedy trenuje model, nieuchronnie wchłonie mnóstwo tych danych. Wszystko więc zostanie zdestylowane; tutaj chodzi o powstrzymanie destylacji celowej, wymierzonej w konkretne modele.
Model, który „jest ChatGPT”: przypadek DeepSeek
W sieci ludzie właśnie dokopują DeepSeek. Firma wydała nowy model — nawiasem mówiąc, ktokolwiek u nich odpowiada za marketing, powinien się wstydzić: zamiast nazwać go po prostu „DeepSeek V4.2”, wymyślili „4.1 Flash 1017”. Fatalnie, wszyscy się tylko gubią. Tak czy inaczej model jest świetny: mały, o otwartych wagach i znakomitym stosunku jakości do kosztów na tle konkurencji.
Ale posłuchajcie dalej: gdy się z nim rozmawia — w testach w 26 na 30 przypadków — przedstawia się słowami: „Jestem ChatGPT, asystent stworzony przez OpenAI”. Ktoś drążył głębiej i okazało się, że odcisk modelu jest rozpoznawany dokładnie jako GPT-6 Astra. Mówiąc wprost: DeepSeek zdestylował Astrę — plus oczywiście własne ulepszenia, bo bądźmy sprawiedliwi: ta firma zrobiła ogromną robotę, otwierając swoje badania i oddając społeczności AI mnóstwo wartości. Tylko że jednego z drugim się nie wyklucza — tu mocno destylowano Astrę. Efekt praktyczny: jeśli chcesz większość możliwości Astry za ułamek ceny, ten model jest dla ciebie.
Kto stoi za włamaniem — i dlaczego my jesteśmy celem
Wszystkie te wskazówki naprowadzają na to, kto mógł stać za włamaniem do OpenCode: najpewniej chińskie laboratorium, może nawet kilka naraz. Powód? Właśnie takie wpisy jak ten Anthropic. Wielkie laboratoria zabezpieczyły się na tyle, że atakowanie ich stało się za trudne. Szuka się więc łatwiejszych celów — a OpenCode to firma względnie mniejsza (choć wciąż większa niż świeży startup; chodzi o kierunek, w którym to zmierza). Łatwiej włamać się do tlumu konsumentów, przejąć klucze ludzi takich jak my, rozkręcić zużycie, zanim ktokolwiek zauważy — a destylacja „od zwykłych użytkowników” jest dla Anthropic i OpenAI znacznie trudniejsza do wykrycia, bo ruch wygląda jak normalny ruch normalnych ludzi.
I to jest najstraszniejszy wniosek z całej sprawy: celami jesteśmy my — zwykli użytkownicy AI. Posunę się do stwierdzenia, że to wręcz poziom państwowy. Może to pojedyncze laboratorium, może kilka — ale wszystkie są finansowane i w pełni wspierane przez państwa. Mowa o najważniejszej technologii w dziejach, a jej celami jesteśmy teraz my.
Pętle agentowe zamiast jednorazowych skanów
Co więc robić? Używać AI do obrony. Pokażę dokładnie, co robię ja.
W Cloudroom mam kilka pętli agentowych nastawionych na wzmacnianie własnych systemów. Trzeba w nich używać najmocniejszych modeli — Opusa 5.5, GPT-6 Solar, GPT-6 Astry, Fable 5.1 albo ich kombinacji — i uruchamiać je na własnych projektach i bazach kodu. Robić to strategicznie, czyli automatycznie. Nie uruchomić raz i odpuścić: włamań przybywa, a tempo tylko narasta. Jeśli ktoś sądzi, że jednorazowy skan wystarczy, to jest po prostu oderwane od rzeczywistości. Dlatego potrzebne są pętle agentowe nastawione na obronę — mam ich kilka w chmurze i kilka na MacBooku.
Ryzyko rośnie lawinowo: dane a16z
Tu autor prosi na żywo własne narzędzie: „Znajdź dane a16z o tym, jak rośnie liczba cyberataków, i pokaż mi wykres”. (Informacja dodatkowa: a16z to Andreessen Horowitz, jeden z największych funduszy venture capital na świecie.)
Pierwszy wykres mówi, że ryzyko rośnie wykładniczo. Od pierwszego i drugiego kwartału tego roku liczba podatności wysokich i krytycznych po prostu strzela w górę. I będzie tylko dalej: agenty się poprawiają, otoczki (Informacja dodatkowa: harness — narzędzie, w którym pracuje agent, np. Claude Code, Codex czy Cursor) też, i niezabezpieczone modele również. Za kilka lat każdy z nas będzie musiał mieć taką wiedzę o bezpieczeństwie, jaką kilka lat temu miał zawodowiec — a przynajmniej osiągać ten poziom wraz ze swoimi agentami. Bo to dopiero początek. Zapewniam: jesteśmy w pierwszych dniach tej ery.
Drugi wykres: zero-daye. „Prawie 90%” — to odsetek wykorzystanych podatności z katalogu CVE, które zaatakowano w dniu ujawnienia albo wcześniej. Kiedyś miałeś czas na przygotowanie obrony. Dziś go nie ma. Atakujący używają LLM-ów i uderzają tego samego dnia — w godziny, czasem w minuty. Trzeba się więc chronić, i to automatycznie.
Pentesting płynący z jednego promptu
Pokażę nową pętlę, którą stworzyłem dosłownie jednym promptem, wypowiedzianym po ludzku. W Cloudroom to banalnie proste: takie automatyzmy działają w pełni w chmurze, więc pracują nawet przy zamkniętym laptopie — skanują, szukają podatności, robią testy penetracyjne twojego własnego oprogramowania.
Konkretnie: pętla sprawdziła aplikację, nie znalazła nic i sama się zarchiwizowała — dokładnie tak ma wyglądać sytuacja, gdy nic nie znajduje. Wyobraź sobie, że wynajmujesz profesjonalistę, białego hakerza — testera penetracyjnego — który analizuje cały twój kod (tutaj: aplikację webową), a potem wraca ze słowami: „Słuchaj, zrobiłem pełny audyt i nic nie znalazłem”. Dokładnie tego chcesz. Czasem znajdzie dziurę albo coś do wzmocnienia — i o to chodzi. Pętla działa samodzielnie w chmurze, na najlepszym możliwym modelu: Opus 5.5 Million (wersja z kontekstem miliona tokenów) przy maksymalnym poziomie rozumowania. A limity w planie Claude Code są na tyle hojne, że może chodzić bez przerwy.
Przy okazji: Cloudroom to narzędzie, które zbudowałem. Jest darmowe i otwarte — możesz przejrzeć kod, zrobić własnego forka, samemu zrobić mu pentest, zrozumieć architekturę. Start jest darmowy: cloudroom.dev, link pod filmem.
„Przeanalizuj mi repozytorium” już nie wystarcza
Wielu ludzi zrobiłoby tak: wybiera projekt i pisze: „Przeanalizuj moje repozytorium i sprawdź, czy z bezpieczeństwem wszystko gra”. Lepiej niż nic — ale tak się nie broni; z takim podejściem zostaniesz rozbity. Pół roku czy rok temu — może wystarczyło. Dziś trzeba to zautomatyzować, i tu wchodzą pętle agentowe oraz fabryki oprogramowania.
Zacznij od znalezienia słabych punktów: może to autoryzacja, może API, może frontend ma za dużo logiki, a może backend ciągnie za sobą mrowie zależności. Możesz po prostu zapytać model: „W tym projekcie wskaż pięć największych słabości bezpieczeństwa — pięć miejsc, które ktoś mógłby wykorzystać”. Spokojnie możesz podkraść ten prompt i uruchomić we własnym projekcie. A potem stwórz dla tych pięciu miejsc dedykowane pętle, które działają bez ciebie.
Powtórzę, bo to najważniejsze: wszystko, co robisz w zakresie bezpieczeństwa, musi działać bez ciebie. Jeśli za każdym razem musisz to uruchamiać osobiście, będzie za późno — w tym momencie będziesz już skompromitowany.
Kondycja systemu, skutki uboczne, zgłoszenia użytkowników
U mnie pętla co kwadrans sprawdza kondycję systemu — to nie jest zabezpieczenie, ale mówi mi, czy nic się nie sypie. Prompt wygląda mniej więcej tak: „Po ludzku wyjaśnij mi, czy w systemie są jakieś problemy i czy z ostatnich 24 godzin wynikają jakieś obawy związane z bezpieczeństwem. Przeanalizuj ponownie i odpowiedz krótko. Nie ujawniaj prywatnych danych — nagrywam film”. Dzięki temu mam dziennik z całego dnia. Warto też kontrolować kondycję bazy danych czy czas ładowania frontendu — wiele problemów da się wyłapać z wyprzedzeniem, a część w ogóle nie wymaga agenta, wystarczy czysty kod.
Ale gdy chodzi o agentowy pentesting — o ludzi, którzy próbują cię zhakować, i o ciebie, który hakujesz samego siebie — zasada jest jedna: zhakuj się, zanim zrobi to ktoś inny. Tak, to pali tokeny; mam z tego powodu kilka subskrypcji. Ale jeśli tego nie będziesz robić, nie zbudujesz dobrego oprogramowania. Taka jest rzeczywistość. Nie da się też spierać z danymi — to nie moje liczby, to a16z, numer jeden wśród funduszy VC, które analizowały firmy takie jak Adobe, AMD, Apple, AWS, Google czy GitHub. Wielkie organizacje — i one też znajdują u siebie podatności, bo agenty AI po prostu kodują ponadludzko.
Segmentuj kod, zamiast męczyć jednego agenta całością
Nową pętlę, na samą aplikację webową, zrobiłem tuż przed nagrywaniem, bo chciałem lepszego pokrycia — na bazę i billing już mam swoje. Jak to rozumieć: wyobraź sobie bazę kodu jako pudełko. Możesz puścić jedną pętlę na całość — lepiej niż nic, ale nie najlepiej. Model łatwo się rozprasza: raz pójdzie w jedno miejsce, następnym razem znowu tam samo. Modele mają swoje preferencje i ignorują zakamarki, więc w efekcie nie przetestujesz wszystkiego.
Dlatego projekt trzeba pociąć na sekcje — i znowu, możesz to zrobić razem z modelem, ucząc się przy okazji. Już sama jedna pętla na całe repo, uruchamiana dwa razy dziennie, stawia cię przed 90% ludzi — mówię całkiem poważnie, miałbym się z tego cieszyć. Ale jeśli chcesz wyprzedzać 99%, segmentuj. Podziel kod — powiedzmy na dziewięć części — i puść na każdą skoncentrowaną pętlę. A potem dostosuj: mniej ważne sekcje mogą chodzić na dobrym, tańszym modelu albo co 24 godziny; ważniejsze co godzinę albo co pół godziny. I jeśli w danej sekcji nic się nie zmieniło przez ostatnie pół godziny, spokojnie wydłuż interwał — choćby do pięciu godzin.
U mnie: szeroki skan bezpieczeństwa chodzi co dwie godziny jako pętla chmurowa, przegląd zależności co cztery — a właśnie zmieniam mu interwał na godzinę. Cała operacja: mówię po ludzku „zmień na co godzinę” i zatwierdzam. Tyle.
Człowiek jest wąskim gardłem
Celem Cloudroom jest zbudowanie otwartej platformy dla agentów chmurowych. W przyszłości będziemy uruchamiać setki, a docelowo tysiące agentów — i one muszą pracować produktywnie. Dziś, gdybyś odpalił tysiąc agentów, nie miałbyś pojęcia, co się dzieje. Kluczem jest produktywność, a osiągniesz ją, usuwając siebie z procesu. Nie da się wszystko zrobić samemu. Niech samo sprawdzi: pytam Room CLI: „Ile mam teraz otwartych wątków w Cloudroom? Nie ujawniaj prywatnych danych — nagrywam film, który obejrzą dziesiątki tysięcy ludzi. Odpowiedz krótko”.
Wąskim gardłem jesteśmy my, ludzie. Przy obecnej generacji modeli to już nie Claude Code, Codex czy pi ograniczają wyniki — agenty są po prostu wystarczająco dobre. Twoim zadaniem staje się więc usunięcie siebie z pętli. Zamiast ręcznie odpalać skan bezpieczeństwa, zamień go w pętlę agentową. A gdy takich pętli przybędzie, budujesz własną fabrykę oprogramowania.
Brzmi groźnie? Zacznij od pierwszej pętli, potem drugiej, trzeciej. I na początku nie dawaj im pełnej autonomii.
Zakładka Review, czyli przeglądaj i kalibruj
W najnowszej wersji Cloudroom (107) jest zakładka Review — pokazuje, co się działo. Np. pętla sprawdzająca skutki uboczne odpaliła się sama, w trakcie tego nagrania: bada zmiany wdrożone w ostatnich 24–48 godzinach pod kątem skutków drugiego rzędu. Właśnie tak rodzi się mnóstwo błędów: poprawiasz przycisk we frontendzie, wydaje ci się, że nic się nie stanie, a gdzieś indziej ta sama logika jest używana — i wkrada się nietypowy przypadek brzegowy. Ta automatyzacja sprawdza dokładnie to.
Inna pętla zbiera feedback użytkowników: każdy, kto używa Cloudroom, może powiedzieć „zgłoś Davidowi, że aplikacja dziś muli” albo kliknąć „zgłoś błąd” w czacie i opisać sprawę. Pętla to zbiera i pilnuje, by każde zgłoszenie zostało zbadane i naprawione.
A pętla testów webowych pokazuje, jak będzie wyglądać przyszła praca: przeglądasz wyniki — „wygląda dobrze, wygląda dobrze” — a gdy coś nie gra, badasz. Może agent potrzebuje większych uprawnień, może poprawki promptu systemowego, może brakuje mu klucza API albo jakiegoś MCP. A może faktycznie znalazł problem. Albo jest po prostu nadwrażliwy i widzi problemy tam, gdzie ich nie ma — wtedy go skalibruj. Taka będzie przyszłość pracy (nagrałem o tym niedawno osobny film — obejrzyjcie go po tym): my orkiestrujemy agenty, tworzymy kolejne pętle i pilnujemy, żeby fabryka oprogramowania chodziła sprawnie. A jej najważniejszą częścią jest bezpieczeństwo.
Chmurowe piaskownice zamiast lokalnych kopii repozytorium
Jak łatwo zrobić taką pętlę? Jednym zdaniem: „Stwórz nową automatyzację chmurową. Przetestuj bezpieczeństwo naszej aplikacji webowej — frontendu i backendu. Użyj modelu Opus 5.5 Max. Ma to być nowa pętla w Cloudroom, w chmurze, nie lokalna. Ustaw tak, żeby każde uruchomienie otwierało nowy wątek”. I gotowe — pętla powstała. Dwie uwagi: nie atakuje żywej strony, tylko własną kopię w piaskownicy; a każdy wątek chmurowy działa we własnej, odizolowanej piaskownicy — osobnym systemie Linux.
To istotne, bo agenty uruchamiane lokalnie — nawet z użyciem drzew roboczych (Informacja dodatkowa: „worktree” to funkcja gita pozwalająca trzymać kilka równoległych wersji repozytorium) — konkurują o zasoby: procesor, GPU i pamięć. A drzewa robocze pożerają dysk: po kilku dniach zastanawiasz się, gdzie ci zniknęło 100–200 gigabajtów. Stąd wątki chmurowe: optymalna architektura to własna piaskownica dla każdego agenta — tak jak każdemu pracownikowi dajesz własny komputer, zamiast kazać mu dzielić jeden z pięcioma osobami. Ty decydujesz o każdym wątku osobno: chmura czy lokalnie.
Cloudroom — jedyne według autora narzędzie na świecie z agentami chmurowymi dla wszystkich popularnych otoczek, korzystające z twoich subskrypcji — pod spodem potrafi chodzić na Claude Code CLI, Codex CLI, Cursor CLI, pi, Hermes czy OpenCode. Wyjdzie nowy model — używasz tego samego interfejsu, tego samego narzędzia i subskrypcji, które już opłacasz. Bo zamknięte chmury Claude’a czy Codexa tego nie pozwolą: nie użyjesz tam swojej subskrypcji Claude, Groka ani OpenCode Gold.
Jeśli chcesz mieć przewagę, nie możesz robić tego, co wszyscy. Trzeba widzieć, dokąd zmierza przyszłość, i stawiać kroki we właściwym kierunku — a oczywistym krokiem jest budowa pętli agentowych i fabryk oprogramowania działających na twoim własnym kodzie: po to, żebyś to ty znalazł wszystkie luki i podatności, zanim zrobią to złoczyńcy i wykorzystają je przeciwko twojemu biznesowi i twojemu życiu.
Zakończenie: era ataków agentowych
Żyjemy w czasach ataków hakerskich napędzanych agentami. Incydent OpenCode jest tego mocnym dowodem — i będzie tylko gorzej. Jeśli nie chcesz skończyć jak OpenCode, wiesz, co robić. Zacznij w Cloudroom, opisując pętlę zwykłym językiem; model — czy to Opus 5.5, czy GPT-6 Solar — to twój wybór. Główny apel brzmi: stwórz swoją pierwszą pętlę agentową na własnym projekcie, na własnej bazie kodu. W przeciwnym razie bierzesz na siebie niepotrzebne ryzyko, a kompromitacja to wyłącznie kwestia czasu.
cloudroom.dev jest w pełni open source — mamy już prawie tysiąc gwiazdek na GitHubie — i można zacząć od darmowego planu. A jeśli prowadzisz firmę z zespołem od 2 do 30 osób i chcesz wdrożyć Cloudroom z bezpośrednim dostępem do mnie i całego zespołu inżynierów, wypełnij formularz oferty biznesowej — zgłoszenie jest bezpłatne, link pod filmem.
Dziękuję za obejrzenie. Życzę wam produktywnego tygodnia.