Skill przeszedł skanery Cisco i NVIDIA. Trafił do 26 000 agentów. Potem badacze podmienili stronę, na którą wskazywał — i wszystkie agenty zaczęły wykonywać kod atakującego.

Firma AIR zbudowała fałszywą „umiejętność" dla agentów AI o nazwie brand-landingpage, przepuściła ją przez skanery bezpieczeństwa Cisco, NVIDIA i wbudowane w największe rejestry skilli — wszystkie oznaczyły ją jako bezpieczną — a następnie rozprowadziła do około 26 000 agentów, w tym na kontach firmowych. Gdy skill był już szeroko zainstalowany, badacze podmienili treść strony, na którą wskazywał. Nowa wersja kazała agentom pobrać i uruchomić skrypt. W dowodzie koncepcji skrypt tylko odsyłał adres e-mail użytkownika z powrotem do AIR — i to właśnie tak firma policzyła, ile agentów przejęła.

To brzmi nieprawdopodobnie — agent AI, który ma wykonywać użyteczną pracę, masowo uruchamia kod obcego serwera, bo zainstalowano w nim „umiejętność" z marketplace'u. Ale mechanizm jest banalnie prosty, znany od miesięcy, i jest dokładnie tym samym wzorcem, który opisujemy przez cały tydzień. Różnica polega na tym, gdzie tym razem leży granica zaufania.

Czym jest „skill" i dlaczego to nowa powierzchnia ataku

Agentowe skille to pakiety instrukcji, które rozszerzają to, co agent AI potrafi zrobić — odpowiednik wtyczki czy rozszerzenia, ale dla asystenta AI. Skill to przede wszystkim plik SKILL.md z instrukcjami w języku naturalnym i ewentualnie dołączone pliki. Agent czyta te instrukcje i traktuje je jako wskazówki, co robić. Istnieją całe marketplace'y skilli — ClawHub, skills.sh, repozytoria na GitHubie — z których użytkownicy instalują gotowe umiejętności.

I tu jest sedno problemu, które Anthropic sam opisuje w swojej dokumentacji jako ryzykowne: skill może instruować agenta, żeby pobrał treść z zewnętrznego URL-a i się nią kierował. A treść pod tym URL-em może się zmienić po tym, jak skill został zweryfikowany.

To jest dokładnie ta sama klasa, którą opisywaliśmy wczoraj przy Cordyceps i przez cały miesiąc przy agentach: artefakt, który przechodzi kontrolę jako statyczny plik, ale którego rzeczywiste zachowanie zależy od czegoś, co kontroli nie podlega. Skaner sprawdza paczkę. Agent wykonuje to, na co paczka wskazuje. Między jednym a drugim jest przepaść, którą kontroluje atakujący.

Jak to zadziałało — dwie fazy

Atak AIR rozegrał się w dwóch fazach, i ta dwufazowość jest całym mechanizmem.

Faza pierwsza — budowanie zaufania. Badacz Niv Hoffman stworzył skill brand-landingpage, prezentowany jako narzędzie no-code do budowania landing page'y produktowych za pomocą Google Stitch. Przypadek użycia dobrano celowo — miał kusić nietechnicznych użytkowników firmowych: marketerów, sprzedawców, projektantów. Skill dostarczał prawdziwą funkcjonalność, co budowało zaufanie. Żeby uwiarygodnić go dalej, AIR zdobył dwa sygnały zaufania. Pierwszy: reputacja GitHuba — skill wmergowano do popularnego repozytorium agentów z około 36 000 gwiazdek, dziedzicząc jego wiarygodność. Drugi: czyste werdykty skanerów. AIR uruchomił skill przeciwko skanerom Cisco, NVIDIA i wszystkim wbudowanym w skills.sh — wszystkie oznaczyły go jako bezpieczny. Następnie wypromowano go reklamą na Instagramie, która kierowała użytkowników do instalacji.

Dlaczego skanery go przepuściły? Bo skill nie zawierał żadnych złośliwych instrukcji we własnych plikach. Mówił tylko agentowi, żeby zainstalował „Stitch SDK", kierując się dokumentacją pod zewnętrznym linkiem — stitch-design.ai, domeną kontrolowaną przez AIR, nie prawdziwą domeną Google (stitch.withgoogle.com). W momencie skanowania link prowadził do autentycznej dokumentacji Stitch. Skanery zobaczyły czystą paczkę wskazującą na wiarygodną stronę instalacyjną i ją przepuściły. Strona, którą agent faktycznie miał pobrać i wykonać, leżała poza zakresem skanu.

Faza druga — pociągnięcie za spust. Gdy skill był już popularny — wysoko oceniony, często pobierany, obecny w wielu marketplace'ach — AIR podmienił treść pod stitch-design.ai. Nowa wersja instruowała agenty, żeby pobrały skrypt wyciągający adresy e-mail i go uruchomiły. Wkrótce zaczęły napływać adresy ofiar — dowód, że ich agenty zostały przejęte. W demonstracji skrypt zbierał tylko e-maile, ale — jak podkreśla AIR — prawdziwy atakujący dziedziczyłby pełne uprawnienia agenta: mógłby czytać pliki, wyprowadzać dane albo przejść do systemów wewnętrznych.

Sednem: skaner sprawdza migawkę, atakujący kontroluje film

Tu jest strukturalna przyczyna, którą warto nazwać wprost, bo wykracza poza ten jeden przypadek.

Skanery, które testował AIR, analizują paczkę, którą się im przekazuje: plik SKILL.md i dołączone pliki. To jest migawka w jednym momencie. Ale skill to coś więcej niż jego pliki. Jak ujmuje to AIR: skilla nie da się zeskanować po samych plikach — trzeba go zeskanować pod kątem wszystkiego, na co wskazuje agentowi. Obecne skanery ignorują większość ryzyka płynącego z tych zewnętrznych instrukcji.

To jest dokładnie ta sama lekcja, którą zapisaliśmy przy Cordyceps: skaner czyta poprawny artefakt i idzie dalej, podczas gdy podatność istnieje w tym, czego skaner nie widzi. Tam była to kompozycja workflow. Tutaj jest to zewnętrzny URL, którego treść zmienia się po przejściu kontroli. Wspólny mianownik: zaufanie przyznane raz, na podstawie statycznego sprawdzenia, podczas gdy rzeczywiste zachowanie jest dynamiczne i kontrolowane przez atakującego.

Dla zespołów bezpieczeństwa problem jest nie tylko taki, że skill przeszedł przegląd — ale że jego zachowanie mogło się zmienić po tym, jak zaufanie zostało już przyznane. To jest model „time-of-check vs time-of-use" przeniesiony na poziom agentów AI: sprawdzasz w jednym momencie, agent używa w innym, a między nimi wszystko może się zmienić.

To nie pierwszy raz — i to jest najważniejsze

Warto być uczciwym co do nowości: technika nie jest nowa, i to ją czyni groźniejszą, nie mniej groźną.

Trzy tygodnie przed publikacją AIR firma Trail of Bits obeszła detektor złośliwych skilli ClawHub, skaner Cisco i wszystkie trzy skanery wbudowane w skills.sh. Jej wniosek był bezlitosny: skaner sprawdza ustaloną paczkę, podczas gdy atakujący może bez końca modyfikować ładunek, aż przejdzie. Prawdziwe kampanie używają tej samej sztuczki od miesięcy — trzymają zgłoszony skill czysty, a ładunek hostują na stronie, którą agent pobiera dopiero przy instalacji.

I to nie są teoretyczne dowody koncepcji. Trend Micro opisał, jak dystrybucja Atomic macOS Stealer (AMOS) przeniosła się z pirackiego oprogramowania na złośliwe skille hostowane na ClawHub, SkillsMP i GitHubie — z ponad 2200 złośliwymi skillami znalezionymi ostatecznie na GitHubie, kradnącymi poświadczenia, dane przeglądarek, portfele krypto i klucze. Antiy CERT potwierdził 1184 złośliwych skilli na samym ClawHub. To jest aktywnie eksploatowana powierzchnia ataku, nie ćwiczenie akademickie.

Jest też badanie, które pokazuje, jak głęboki jest problem ze skanerami: siedem głównych skanerów zgadza się co do mniej niż jednego na pięćset swoich łącznych oznaczeń — bo każdy ocenia skill w izolacji, ślepy na zewnętrzne linki i na to, co zmienia się po przeglądzie. Skanery nie tylko przepuszczają ataki; nie zgadzają się nawet między sobą co do tego, co jest podejrzane.

„Lethal trifecta" — dlaczego to jest wbudowane w projekt

Jest rama, która tłumaczy, dlaczego ten problem jest tak trudny, i warto ją przytoczyć, bo jest najlepszym dostępnym ujęciem.

Badacz Simon Willison nazwał architektoniczną wadę „lethal trifecta" — śmiertelną triadą: agent, który ma dostęp do prywatnych danych, przetwarza niezaufaną treść i może komunikować się na zewnątrz, jest eksploatowalny z założenia. Większość wdrożonych agentów ma wszystkie trzy cechy, bo właśnie ta kombinacja czyni je użytecznymi.

To jest sedno. brand-landingpage zadziałał, bo agent miał wszystkie trzy elementy triady: dostęp do systemu użytkownika, zdolność przetwarzania instrukcji z zewnętrznego URL-a (niezaufana treść) i możliwość pobrania oraz uruchomienia skryptu (komunikacja na zewnątrz). To nie jest błąd, który da się załatać jednym filtrem — to jest konsekwencja tego, czym agent jest. OWASP sklasyfikował to w Top 10 dla aplikacji agentowych jako ASI04 — kompromitacja łańcucha dostaw przez skille lub pakiety z rejestru. A własne badanie Cisco wykazało, że tylko 29% organizacji uważa się za przygotowane do zabezpieczania wdrożeń agentowych.

To jest też piąty czy szósty raz w ciągu tygodni, gdy opisujemy ten sam wzorzec w różnych przebraniach: ChatGPhish(strona), Claude Code GitHub Action (issue), Gemini (powiadomienie), Agentjacking (zdarzenie Sentry), AutoJack(strona dla agenta). Teraz skill z marketplace'u. Za każdym razem agent traktuje niezaufaną treść jako instrukcję — różni się tylko kanał, którym ta treść wchodzi.

Co zrobić

Traktuj skille agentowe jak każdą zależność z uprawnieniami — nie jak zaufaną treść. Skill działa z uprawnieniami agenta, czyli często z dostępem do twoich plików i systemów. Zasługuje na tę samą ostrożność co biblioteka, którą dodajesz do projektu, albo wtyczka, którą instalujesz. „Zweryfikowany przez skaner" i „wysoko oceniony na GitHubie" to nie to samo co „bezpieczny" — brand-landingpage miał oba te sygnały.

Bądź szczególnie podejrzliwy wobec skilli, które każą agentowi pobierać treść z zewnętrznych URL-i. To jest dokładnie wektor, który Anthropic oznacza jako ryzykowny. Skill, który instruuje agenta, by „zainstalował SDK według dokumentacji pod tym linkiem", to skill, którego zachowanie może się zmienić w dowolnym momencie po instalacji. Jeśli to możliwe, preferuj skille, które są samowystarczalne i nie kierują agenta poza zweryfikowaną paczkę.

Nie polegaj wyłącznie na skanowaniu w momencie zatwierdzenia. AIR pokazał wprost: jednorazowy skan nie wystarcza, bo nie obejmuje tego, co zmienia się później. Potrzebny jest monitoring zachowania agenta w czasie wykonania — co agent faktycznie pobiera i uruchamia — nie tylko statyczna analiza paczki przy instalacji.

Stosuj sandboxing i zasadę najmniejszych uprawnień. To jest ta sama twarda granica, którą powtarzaliśmy przez cały miesiąc: jeśli agent działa w izolowanym środowisku z minimalnym dostępem, przejęty skill nie dosięgnie wrażliwych danych ani systemów wewnętrznych. Triada Willisona jest eksploatowalna tylko wtedy, gdy wszystkie trzy elementy są obecne — odebranie agentowi jednego z nich (np. swobodnej komunikacji na zewnątrz) łamie atak.

Prowadź wewnętrzny, wyselekcjonowany katalog dozwolonych skilli zamiast pozwalać na instalację z dowolnego marketplace'u. Dla organizacji to jest najpewniejsza kontrola: admission control na poziomie tego, które skille w ogóle mogą wejść, zamiast ufać, że marketplace je zweryfikował.

Źródła

AIR Security — oryginalny research „The Story of Skills" z pełnym opisem obu faz ataku: https://www.air.security/blog-posts/the-story-of-skills

The Hacker News — analiza mechanizmu i kontekst wcześniejszego obejścia przez Trail of Bits: https://thehackernews.com/2026/06/fake-ai-agent-skill-passed-security.html

CSO Online — szczegóły sygnałów zaufania (GitHub, skanery) i celowania w użytkowników nietechnicznych: https://www.csoonline.com/article/4188840/how-a-malicious-ai-agent-skill-passed-security-checks-and-reached-26000-users.html

The Next Web — analiza strukturalnej wady i badania o niezgodności skanerów: https://thenextweb.com/news/fake-ai-agent-skill-security-scanners-bypassed-26000-agents

CybersecurityNews — kontekst AMOS, 2200 złośliwych skilli i kampanii przez ClawHub: https://cybersecuritynews.com/malicious-ai-agent-skill-bypasses/

AgenticWire — rama „lethal trifecta" Willisona, statystyki ClawHub i klasyfikacja OWASP ASI04: https://www.agenticwire.news/article/defenseclaw-cisco-agent-security