O czym jest ten film
- W ciągu kilku dni świat zobaczył serię incydentów: włamanie do narzędzia OpenCode, atak na lodówki setek francuskich supermarketów, cyberalarm w Japonii po fali ataków oraz kradzież danych klientów kilku banków w Korei Południowej — dzieło, jak się wydaje, jednej osoby.
- OpenCode to darmowe narzędzie do programowania z AI (16 mln programistów miesięcznie); firma potwierdziła nocne włamanie „powiązane z atakiem destylacyjnym na wielką skalę”, a wycieknąć mogły klucze API zapisane w serwisie Console.
- Klucz API działa jak numer karty kredytowej dla AI — jednemu programiście narosło przez noc ponad 400 dolarów opłat, na długo przed oficjalnym komunikatem OpenCode.
- Atak destylacyjny to masowe odpytywanie czołowych modeli (z fałszywych kont i różnych adresów IP) oraz trenowanie na tych odpowiedziach własnych, tańszych modeli — tej praktyce zarzucano już m.in. DeepSeekowi i Qwenowi.
- Deweloper OpenCode Dax Raad mówił o 48 godzinach nieprzerwanych ataków, obejmujących także jego prywatne konta, i stwierdził wprost: „potrzebujemy agentów działających 24/7, bo oni dokładnie takie mają”.
- Recepta na „kieszonkowego hakera” jest prosta i tania: niescenzurowany model (lokalnie lub przez API) plus harness, czyli zestaw narzędzi — choćby nawigacja w sieci czy testy penetracyjne.
- Ataki na koreańskie banki analitycy CrowdStrike przypisali pojedynczej osobie, której głównym narzędziem był DeepSeek, a pomocniczym — model GLM 5.3.
- Liczba cyberataków w tym roku rośnie wykładniczo, a ministrowie finansów G7 uzgodnili ćwiczenia i symulacje ataków AI na banki.
- Autor zaleca dwa ustawienia w kontach AI: miesięczny limit wydatków klucza oraz alerty użycia (zwykle trzeba je włączyć ręcznie).
- Na koniec prezentacja Lockpick — darmowego skanera bezpieczeństwa dla aplikacji budowanych z AI, skilli i repozytoriów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Traktuj klucz API jak numer karty kredytowej — usuń stare, wygeneruj osobne dla każdej aplikacji
Na czym polega: Jeden klucz współdzielony przez wiele narzędzi to proszenie się o kłopoty: wyciek z jednego serwisu (jak konsola OpenCode) wystawia na ryzyko wszystkie połączone konta. A klucz bez zabezpieczeń działa jak karta bez limitu — posiadacz narobi kosztów, zanim cokolwiek zauważysz.
Jak stosować: Jeszcze dziś wejdź w panele dostawców (Anthropic, OpenAI, Google itd.), do sekcji kluczy API. Skasuj wszystkie nieużywane, a dla każdej aplikacji wygeneruj dedykowany klucz, nadaj mu czytelną nazwę i wklej wyłącznie w tej aplikacji.
Na co uważać: Największą pułapką są stare, zapomniane klucze z projektów sprzed miesięcy — wciąż działają i nikt ich nie monitoruje.
2.Daj kluczowi sufit wydatków — ustaw miesięczny limit
Na czym polega: Bez limitu klucz pozwala wydawać bez końca. Limit działa jak abonament z górną granicą: nawet po kradzieży straty mają naturalny pułap.
Jak stosować: W ustawieniach klucza lub konta wskaż miesięczny próg (np. 20–30 dolarów), dopasowany do realnego zużycia danej aplikacji. Powtórz dla każdego aktywnego klucza.
Na co uważać: Zbyt niski limit może w połowie miesiąca odciąć własną aplikację — zostaw margines i koryguj wartość po każdym wzroście ruchu.
3.Włącz alerty użycia, zanim o kradzieży poinformuje Cię rachunek
Na czym polega: Przy kradzieży karty dzwoni bank, przy logowaniu z nowego urządzenia wyskakuje weryfikacja. W świecie kluczy AI pierwszym sygnałem bywa faktura. Alerty istnieją u większości dostawców, ale często wymagają ręcznego włączenia.
Jak stosować: W ustawieniach konta aktywuj powiadomienia o przekroczeniu progu zużycia i ustaw go wyraźnie poniżej limitu z punktu 2 — alert musi zdążyć przyjść, zanim zrobi się naprawdę drogo.
Na co uważać: Alert to czujka, nie zamek: informuje o problemie, ale nie zatrzymuje wydatków. Dopiero para „limit plus alert” daje pełną ochronę.
4.Zrozum, po co kradnie się klucze: destylacja modeli
Na czym polega: Skradzionych kluczy nie używa się wyłącznie do darmowych rozmów. Masowe odpytywanie czołowego modelu — po to, by wytrenować na odpowiedziach własny, tańszy model — działa lepiej z kont zweryfikowanych, którymi dostawcy wydają się ufać. Dlatego łupem padają właśnie konta z kluczami.
Jak stosować: Obserwuj nietypowe wzorce: ruch nocą, nagłe skoki liczby zapytań, zużycie z regionów, w których nie działasz. Poszkodowany z incydentu OpenCode zorientował się dopiero przy rachunku za ponad 400 dolarów.
Na co uważać: Skok zużycia nie zawsze oznacza atak — najpierw sprawdź własne zadania automatyczne i integracje, zanim unieważnisz klucz produkcyjny.
5.Zrób inwentaryzację: gdzie właściwie leżą Twoje klucze
Na czym polega: Autor wskazuje oczywiste, a pomijane miejsca: klucz wpisany na sztywno w treści skilla „dla wygody”, plik .env ze wszystkimi poświadczeniami na dysku, wtyczki instalowane bez żadnego przeglądu. Wyciek jednego pliku otwiera wszystkie konta naraz.
Jak stosować: Wypisz wszystkie miejsca przechowywania kluczy: pliki projektów, skille, notatki, repozytoria. Usuń klucze z kodu i historii repozytoriów, unieważnij te, które mogły trafić na cudzy serwer, i wygeneruj nowe — zgodnie z punktem 1.
Na co uważać: Skasowanie klucza z bieżącej wersji pliku nie wystarczy, jeśli został w historii zmian albo w cudzej kopii projektu.
6.Weryfikuj wtyczki i integracje tak samo skrupulatnie jak aplikacje
Na czym polega: Wtyczki instalowane mimochodem rzadko przechodzą jakikolwiek przegląd bezpieczeństwa — a dostają dostęp do naszych danych, a czasem i do kluczy.
Jak stosować: Przed instalacją sprawdź, kto jest wydawcą, jakie uprawnienia żąda narzędzie i czy prosi o dostęp do kluczy. Repozytoria i skille można zeskanować przed uruchomieniem (np. darmowym Lockpick), a nie dopiero po awarii.
Na co uważać: Popularność nie jest gwarancją bezpieczeństwa — liczy się wiarygodność dostawcy i to, co narzędzie faktycznie robi z poświadczeniami.
7.Nie przestawaj sprawdzać pracy AI — to właśnie wtedy się poparzasz
Na czym polega: Zdaniem autora żyjemy w czasach budowania po omacku: modele stały się tak dobre, że przestaliśmy weryfikować ich kod i decyzje. Moment, w którym przestajemy sprawdzać, to dokładnie moment, w którym palimy się najmocniej.
Jak stosować: Wszystko, co działa publicznie albo dotyka danych klientów, skanuj i przeglądaj przed wdrożeniem oraz po każdej istotnej zmianie. Wyniki skanu potraktuj jako listę poprawek, którą można wrzucić z powrotem do AI.
Na co uważać: Automatyczny skaner nie zastąpi przeglądu człowieka przy danych wrażliwych — sami twórcy takich narzędzi przyznają, że nie są nie do przebicia.
8.Obrona też musi pracować całą dobę
Na czym polega: Atakujący nie męczy się, bo nie jest człowiekiem — to zautomatyzowani agenci, którzy bez przerwy pukają do wszystkich drzwi naraz. Zespół OpenCode mówi wprost, że do odparcia ataku potrzebuje agentów działających 24/7.
Jak stosować: Przenieś logikę obrony na automaty — przynajmniej na limity i alerty. Ten sam „kieszonkowy haker”, który może atakować, nadaje się do ciągłego testowania własnych systemów; właśnie tak wykorzystuje go zespół autora.
Na co uważać: Asymetria cen działa na korzyść atakujących — najlepsze narzędzia obronne nie zwalniają z podstawowej higieny kluczy.
9.Załóż, że przeciwnik dysponuje „kieszonkowym hakerem”
Na czym polega: Niescenzurowany model (pobrany lokalnie albo dostępny przez API za ułamek ceny) połączony z zestawem narzędzi — dostępem do sieci, testami penetracyjnymi — potrafi przeprowadzać wyrafinowane ataki. Nie musi być człowiekiem, nie męczy się i zmienia taktykę po nieudanej próbie.
Jak stosować: W ocenie ryzyka własnych systemów zakładaj przeciwnika o kompetencjach dobrego modelu AI, działającego bez przerw. Testuj własne aplikacje tak, jak testowałby je taki automat — lepiej ty pierwszy niż ktoś obcy.
Na co uważać: Nie lekceważ lokalnych modeli jako „za słabych” — ich opóźnienie względem czołówki liczy się w miesiącach i stale się kurczy.
10.Bezpieczeństwo AI to stały proces, nie jednorazowy projekt
Na czym polega: Krzywa ataków rośnie wykładniczo, rządy G7 ćwiczą scenariusze ataków AI na banki, a kolejne fale incydentów pokazują, że mówimy o trendzie, nie o epizodzie. Autor przewiduje, że to będzie główna historia 2027 roku.
Jak stosować: Wprowadź stały rytuał: comiesięczny przegląd kluczy, limity i alerty przy każdym nowym projekcie, skan przed każdym wdrożeniem — trochę jak kopie zapasowe, które robi się regularnie, a nie „kiedyś”.
Na co uważać: Celem jest przygotowanie, nie panika. Na każdy zamek kiedyś trafi się odpowiedni klucz — licz na ograniczenie strat, a nie na ich niemożliwość.
Redakcyjne tłumaczenie
Wstęp: najważniejsza historia AI 2027 roku właśnie się zaczęła
Mam wrażenie, że największa historia AI 2027 roku dopiero co wystartowała. W ciągu zaledwie kilku dni hakerzy włamali się do narzędzia do programowania z AI o nazwie OpenCode. Ktoś podkręcił temperaturę w lodówkach setek francuskich supermarketów. W Japonii — po fali ataków, którą w zeszłym tygodniu widać było w trendach na X — ogłoszono cyberalarm. A w Korei Południowej ktoś użył darmowego narzędzia hakerskiego opartego na AI, żeby wykraść dane klientów z kilku banków, i wygląda na to, że sprawcą była jedna osoba.
Jeśli kiedykolwiek oddałeś aplikacji klucz do swoich kont Claude, Codex albo Gemini, pierwsza z tych historii dotyczy właśnie Ciebie. W kolejnych minutach pokażę, co z tym można zrobić.
Jedna z kluczowych osób stojących za OpenCode, Dax Raad, mówi, że zespół od 48 godzin jest atakowany bez przerwy. I dodał coś istotnego: potrzebuje agentów AI pracujących na okrągło, bo — jak się wydaje — dokładnie to samo ma po drugiej stronie.
(Informacja dodatkowa: wzmianka o lodówkach nawiązuje do ataków na infrastrukturę chłodniczą francuskich sieci handlowych, opisywanych już w 2025 r.)
Co się właściwie stało
Dla porządku: OpenCode to darmowe narzędzie do programowania z AI, bliski krewny Claude Code czy Codex. Firma podaje, że co miesiąc korzysta z niego 16 milionów programistów. Narzędzie ma serwis o nazwie Console, w którym zapisuje się klucze łączące konta Claude Code, Codex i inne. Taki klucz to w praktyce numer karty kredytowej dla AI — kto go posiada, może w jedną noc narobić Ci ogromnych kosztów. Według OpenCode cały incydent sprowadza się do czegoś, co nazywa się atakiem destylacyjnym; zaraz rozłożę to pojęcie na czynniki pierwsze.
To zresztą film trochę inny niż moje zwykłe. Zazwyczaj pokazuję, jak coś zbudować albo co osiągnąć z pomocą AI. Tym razem chodzi raczej o to, co się dzieje, gdy te same możliwości ma druga strona. Widzę coraz więcej sygnałów ostrzegawczych, o których mówi zdecydowanie za mało ludzi. Nieustanna ekscytacja kolejnym modelem, kolejnym frameworkiem, kolejną granicą AI to jedno — ale w pewnym momencie ta cała konstrukcja może runąć. Skoro od kilku miesięcy coraz głębiej wchodzę w cyberbezpieczeństwo, opowiem po ludzku, co się wydarzyło z OpenCode — jako zapowiedź tego, co może nadejść w niezbyt odległej przyszłości.
Kilka dni temu ktoś dostał się do starego systemu OpenCode, właśnie wygaszanego przez zespół. Mogły z niego wyciec klucze, które ludzie zapisali w konsoli. Jeden z programistów relacjonował, że jego klucz „ożył” o drugiej w nocy, a o 9:36 rano opublikował post: ponad 400 dolarów opłat za jedną noc. Minęło sporo godzin, zanim OpenCode odezwało się oficjalnie. I oczywiście nie był sam. Tego samego popołudnia firma wystawiła komunikat: „Wczoraj w nocy doszło u nas do naruszenia bezpieczeństwa związanego z atakiem destylacyjnym na wielką skalę”.
Czym jest atak destylacyjny
Wróćmy więc do tego terminu. Atak destylacyjny polega mniej więcej na tym, że ktoś zasypuje czołowy model — zwykle taki ze ścisłej światowej czołówki, tzw. frontier — milionami pytań. Robi to masowo: z fałszywych kont i z rozproszonych adresów IP. Odpowiedzi służą potem do wytrenowania własnych, tańszych modeli. Wielu przedstawicieli chińskiej sceny AI, w tym DeepSeek i Qwen, oskarżano o tę praktykę od dawna. Stąd znany ciekawostkowy efekt: gdy zapytasć Qwena, kim jest, potrafi odpowiedzieć, że jest Claude’em od Anthropic.
(Informacja dodatkowa: Qwen to rodzina modeli chińskiej grupy Alibaba; GLM tworzy firma Zhipu AI, a DeepSeek to kolejny chiński dostawca.)
Ostatecznie powstaje model-naśladowca: nie był trenowany tak jak oryginał, ale przejął całą jego wiedzę — zdestylował ją i zsyntetyzował tak, żeby rozumieć świat przez pryzmat oryginału. Cały sens kradzieży kluczy sprowadza się więc do znalezienia zweryfikowanych kont, z których destylację można prowadzić dalej — z kont, którym dostawcy zdają się ufać.
OpenCode traktuję tu wyłącznie jako przykład, ale dla spokoju użytkowników: firma podała, że jeśli nie otrzymaliście od niej e-maila, najpewniej nie zostaliście poszkodowani. W każdym razie zajrzyjcie do dokumentacji i na stronę — dla pewności. Jeśli korzystacie wyłącznie z aplikacji typu ChatGPT czy Claude, nie macie się czym martwić, przynajmniej na razie. Ale jeśli kiedykolwiek przekazaliście jakąkolwiek aplikacji klucz API do konta AI, zróbcie dziś wieczorem dokładnie to: wejdźcie tam, gdzie klucz powstał — u Claude, OpenAI, Google, kogokolwiek — i usuńcie go. Potem wygenerujcie nowy klucz dla każdej aplikacji osobno i wklejcie go wyłącznie w te narzędzia, których faktycznie używacie. Na końcu pokażę dwa proste ustawienia, dzięki którym klucz ma naturalny sufit wydatków — a gdyby mimo wszystko wyciekł, promień rażenia będzie znikomy. Ale szczerze: klucz to tylko drobna cegiełka tej większej historii.
„Potrzebujemy agentów 24/7, bo dokładnie to mają oni”
Wróćmy do Daxa. Pół godziny po komunikacie OpenCode napisał, że atak objął też jego konta prywatne. A następnego ranka opublikował zdanie, które właściwie zainspirowało cały ten materiał: „W zasadzie potrzebujemy agentów na 24/7, bo dokładnie to mają oni”.
Przemyślmy to. Ktoś puka bez przerwy, bez zmęczenia, do każdych drzwi, jakie posiadasz. I jeśli Dax ma rację, ten „ktoś” nie jest człowiekiem. To oprogramowanie: zestaw agentów AI spiętych w całość, najpewniej opartych na niescenzurowanych modelach — pozbawionych zabezpieczeń i bramek etycznych — i puszczonych na żywo, żeby przeprowadzały wyrafinowane ataki.
Nie jestem ekspertem od cyberbezpieczeństwa, ale pracowałem jako starszy programista w różnych firmach, prowadzę doradztwo Prompt Advisors i widziałem więcej kodu i incydentów, niż chciałbym przyznać. I mogę powiedzieć jedno: to nie to samo, co boty sprzed ery AI. Co innego stary automat, co innego bot z własnym harnessem — czyli zestawem narzędzi — i z modelem na tyle sprytnym, że zauważa, iż atak nie wychodzi, zmienia podejście i próbuje ponownie. Kiedyś liczył się brute force: przerzucenie programowo wszystkich możliwych drzwi. Dziś każdy, kto umie pobrać niescenzurowany model albo wydać kilka dolarów na dostęp przez API, może — jeśli tylko zechce — siać spustoszenie.
OpenCode nie powiedziało, kto stoi za atakiem ani dokładnie, jak sprawca się dostał. Kimkolwiek jednak był, niepokoi mnie coś innego.
Od „Reverse Engineer Anything” do włamania w cokolwiek
Wspominałem na kanale, choćby przy okazji, o modelach niescenzurowanych: to modele zdjęte ze smyczy — bez zabezpieczeń, bez bramek etycznych. Tydzień temu większość twórców, ja włącznie, opisywała projekt „Reverse Engineer Anything”: repozytorium pakujące całkiem wyrafinowane narzędzia w przystępną formę — do inżynierii odwrotnej wszystkiego, od aplikacji desktopowych po webowe.
I właśnie dlatego nagrywam ten film: widzę już tor, po którym toczy się ta historia — od „rozkładania na czynniki pierwsze czegokolwiek” do „włamania się w cokolwiek”. Choć lokalne, niescenzurowane modele odstają dziś od czołówki o 6–9 miesięcy, doliczcie kolejne pół roku — i okaże się, że tuż po Nowym Roku, idąc tą logiką, będziemy mieć modele w rodzaju Opus 5.5 czy GPT 6.1 Astra.
Nie chcę uzbrajać ludzi o złych intencjach, ale żeby było jasne, jak niewiele trzeba: wystarczy harness — zestaw narzędzi, którym operuje jeden „mózg w słoju” — oraz drugi model, zwykle niescenzurowany, pobrany lokalnie (jeśli sprzęt udźwignie) albo wywoływany przez jedno z niescenzurowanych API za ułamek ceny. Gdy takiej parze dasz odpowiednie narzędzia — nawigację po sieci, testy penetracyjne — masz kieszonkowego hakera.
Mój zespół i ja używamy takiego mini-hakera po stronie obrony. Ale coraz więcej osób na świecie bierze go na warsztat ofensywnie — zwłaszcza odkąd odkryło, że koszt to dosłownie kilka dolarów. Dlatego jestem przekonany, że to stanie się trendem i jednym z głównych motywów 2027 roku.
Jedna osoba i dwa chińskie modele: ataki na koreańskie banki
Przypomnijcie sobie koreańskie banki z początku materiału. Specjaliści CrowdStrike — firmy zajmującej się cyberbezpieczeństwem — doszli do wniosku, że za atakami stała najprawdopodobniej jedna osoba. Jakiego AI używała? Głównie DeepSeeka, a jednym z modeli pomocniczych był GLM 5.3 — kolejny chiński model, który każdy może pobrać na własny komputer.
Anthropic, mówiąc o modelach lokalnych i wynikających z nich zagrożeniach, nie grzeszy przejrzystością — i nietrudno się domyślić, dlaczego firma chce zniechęcić większość ludzi do ich używania. Ale jedno ich twierdzenie chyba się broni: modele alternatywne — GLM, Qwen, DeepSeek — zawdzięczają swoją sprawność w dużej mierze trenowaniu na modelach firm amerykańskich.
Dlaczego krzywa pnie się w górę
Na przyszły rok widzę kilka mniejszych trendów, które potęgują mój niepokój. I znów: nie chodzi o straszenie. Chodzi o to, żebyście — skoro już siedzicie w AI — nie interesowali się wyłącznie fajnymi konstrukcjami, które można zbudować i odtworzyć, ale też zabezpieczyli się na rzeczy, które pójdą źle.
Miesiącami temu zachowałem sobie materiał reporterski biuletynu Andrew & Horwitz, który mówi wprost: jesteśmy w środku „cyber momentu”. Autorzy zmapowali wszystkie cyberataki od początku roku — i krzywa po prostu zakręca wykładniczo. A skoro dziś wszystko to mogę uruchomić na zwykłym Macu mini, widzę wyłącznie jeden kierunek: będzie gorzej. Do tego ministrowie finansów G7 uzgodnili właśnie, że przeprowadzą ćwiczenia i symulacje ataku AI na własne banki — żeby sprawdzić, czy ich infrastruktura jest na to gotowa. Traktujcie to jako próbę generalną.
Dwa ustawienia, które warto włączyć jeszcze dziś
Zauważcie asymetrię: gdy ktoś ukradnie Ci kartę, dzwoni bank. Gdy ktoś zaloguje się na Twoją pocztę z nowego urządzenia, wyskakuje alert albo prośba o potwierdzenie. A gdy ktoś zabierze Twój klucz AI, pierwsza o tym „wie” faktura. Dlatego sprawdź dwa ustawienia — w dowolnych aplikacjach, których używasz.
Po pierwsze: zaloguj się na konto, wejdź w sekcję kluczy API i skasuj wszystkie, z których nie korzystasz na bieżąco. Te aktywne nazwij tak, żeby po miesiącu wiedzieć, czemu służą. Następnie ustaw miesięczny limit — zupełnie jak w telefonii z górnym progiem wydatków. Dwadzieścia, trzydzieści dolarów: jeśli ktoś przejmie taki klucz, tyle właśnie będzie mógł wydać — i ani centa więcej.
Po drugie: włącz alerty użycia. Większość aplikacji je ma, ale zwykle trzeba je samodzielnie aktywować. Po przekroczeniu progu dostaniesz e-mail od dostawcy. Wiem, że kusi, żeby wpisać to na listę „na kiedyś” — na dziś, na przyszły tydzień, jak będzie chwila. Ale uwierz: zrób to natychmiast. Bo tym, którzy Cię atakują, ktoś pomaga — i ta pomoc nie śpi.
Skille, pliki .env i wtyczki, czyli kłopoty pod ręką
Dlatego właśnie uważam, że cyberbezpieczeństwo — wszystkie ataki i szkody wynikłe z tego, że ludzie potrafią zmusić AI do ich prowadzenia — będzie kluczową historią 2027 roku. Nie tylko dlatego, że z AI korzysta już mnóstwo firm i ludzi, ale też dlatego, że nie powiedziałem jeszcze ani słowa o liczbie drzwi, którymi można wejść. Pomyśl o skillach — pakietach instrukcji i narzędzi dla agentów AI — w których klucz API siedzi wpisany na sztywno, dla wygody. O pliku .env leżącym na Twoim komputerze, ze wszystkimi poświadczeniami w jednym miejscu. O wtyczkach, które nie przechodzą żadnego przeglądu bezpieczeństwa i których pochodzenia nawet nie sprawdzasz.
Żyjemy w czasach budowania po omacku i bezwarunkowego zaufania do tego, co AI robi i mówi. Modele stały się tak dobre, że ludzie przestali sprawdzać ich pracę — a to dokładnie ten moment, w którym człowiek się poparza.
Lockpick: darmowy skaner dla tych, którzy budują z AI
(Informacja dodatkowa: „vibecoding” to potoczna nazwa tworzenia aplikacji przez rozmowę z modelem AI, bez samodzielnego pisania kodu.)
Jeśli w ostatnim roku zbudowałeś coś z pomocą AI — zwłaszcza „na vibe”, czyli bez wglądu w kod — a projekt jest dostępny publicznie albo działa na produkcji, mój zespół przygotował narzędzie w całości darmowe: Lockpick. Podajesz adres URL aplikacji (o ile działa w sieci); można też skanować skille i repozytoria GitHuba. Dostajesz pełne zestawienie: czy danemu projektowi można zaufać, czy lepiej go najpierw obejrzeć pod lupą, zanim w ogóle ściągniesz go na komputer. Strony i aplikacje można dodatkowo przesłać do skanu „pulse” — również bez opłat — a w odpowiedzi dostaniesz listę rzeczy do załatania oraz gotowy, jednoklikowy prompt, który wystarczy wkleić wybranemu AI, żeby zajęło się resztą.
Nie twierdzę, że to narzędzie jest nie do przebicia — stale je ulepszamy. Cel jest taki: każdy, kto cokolwiek zbudował z AI, powinien móc przeskanować swoją aplikację, najlepiej za darmo, dostać pełny raport i naprawić wszystko — bez konieczności zostawania specjalistą od cyberbezpieczeństwa. Link zostawiam w opisie filmu.
Na koniec: kotek, myszka i rok 2027
Jeśli ten format Ci odpowiada, nagram więcej materiałów o cyberbezpieczeństwie — tłumaczonych prostym językiem, bo wierzę, że to jedna z najważniejszych rzeczy do ogarnięcia w nadchodzących latach. Ta dziedzina będzie nieustanną grą w kotka i myszkę: modele frontier będą coraz sprawniejsze w obronie, a niescenzurowane — w ataku. Na każdy zamek prędzej czy później trafi się odpowiedni klucz. Do zobaczenia w następnym materiale.