Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Rosnące wykorzystanie agentów AI w cyberbezpieczeństwie otwiera nowe możliwości automatyzacji, ale jednocześnie tworzy nową powierzchnię ataku. Scenariusz określany jako „Friendly Fire” pokazuje, że narzędzia przeznaczone do analizy kodu, oceny zależności i wspierania audytów bezpieczeństwa mogą zostać zmanipulowane do uruchomienia złośliwego oprogramowania.
Problem dotyczy przede wszystkim agentów zdolnych do samodzielnego wykonywania poleceń w trakcie analizy nieufnego repozytorium. W takim modelu dokumentacja projektu, pliki tekstowe i instrukcje umieszczone przez autora repozytorium mogą zostać błędnie potraktowane jako legalne wskazówki operacyjne.
W skrócie
Badacze opisali proof-of-concept ataku, w którym agent AI analizujący projekt open source zostaje nakłoniony do uruchomienia spreparowanego skryptu lub binarki. Atak nie wymaga klasycznej kompromitacji plików konfiguracyjnych narzędzia, lecz wykorzystuje treści znajdujące się w zwykłej dokumentacji repozytorium, na przykład w pliku README.
To szczególnie niepokojące, ponieważ właśnie autonomiczne tryby przeglądu kodu i automatyzacji bezpieczeństwa są wdrażane po to, by przyspieszyć analizę i zmniejszyć ryzyko błędu ludzkiego. W praktyce jednak mogą one stać się podatne na prompt injection przeniesiony do warstwy repozytorium.
Kontekst / historia
W ostatnich miesiącach rośnie liczba badań dotyczących prompt injection, agent hijacking oraz nadużyć wynikających z łączenia modeli językowych z funkcjami wykonywania komend systemowych. Wcześniejsze scenariusze często koncentrowały się na zatrutych konfiguracjach, zewnętrznych źródłach danych lub niebezpiecznych integracjach między modelem a środowiskiem wykonawczym.
„Friendly Fire” rozwija ten trend, przesuwając punkt ciężkości z konfiguracji na samą zawartość repozytorium. To istotna zmiana, ponieważ dokumentacja techniczna i instrukcje dla deweloperów są naturalną częścią projektu i zazwyczaj nie są traktowane jako bezpośrednie źródło zagrożeń wykonawczych.
Analiza techniczna
Sedno problemu polega na tym, że agent AI nie zawsze potrafi jednoznacznie oddzielić dane wejściowe od instrukcji operacyjnych. Jeśli otrzyma zadanie przeprowadzenia analizy bezpieczeństwa projektu, może samodzielnie przeszukiwać repozytorium w poszukiwaniu poleceń, skryptów i działań, które uzna za część procesu analitycznego.
Atakujący może umieścić w repozytorium skrypt wyglądający jak legalne narzędzie pomocnicze do testów lub walidacji bezpieczeństwa. Taki skrypt może następnie uruchamiać ukrytą binarkę zawierającą rzeczywisty ładunek. Dla zwiększenia skuteczności binarka może zostać zamaskowana jako artefakt kompilacji albo element nieszkodliwego komponentu.
Kluczowe jest to, że uruchomienie złośliwego kodu nie musi wynikać z samej logiki aplikacji, lecz z interpretacji dokumentacji przez agenta. W praktyce oznacza to repozytoryjne prompt injection: treść README lub innego pliku tekstowego staje się impulsem do wykonania polecenia na hoście analityka, stacji roboczej dewelopera lub w systemie CI.
Dodatkowe ryzyko pojawia się wtedy, gdy narzędzie działa w trybie autonomicznym i samo zatwierdza czynności uznane za bezpieczne. W takim przypadku użytkownik może nie zobaczyć żadnego ostrzeżenia, a wykonanie nieautoryzowanego kodu nastąpi przed wykryciem incydentu.
Konsekwencje / ryzyko
Scenariusz jest groźny, ponieważ uderza bezpośrednio w podstawowy przypadek użycia agentów AI w bezpieczeństwie: analizę nieznanego kodu i ocenę ryzyka związanego z komponentami open source. Zamiast wzmacniać obronę, źle zabezpieczony agent może doprowadzić do uruchomienia złośliwych działań wewnątrz środowiska organizacji.
- wykonanie nieautoryzowanego kodu na systemie gospodarza,
- kradzież sekretów, tokenów, kluczy API i poświadczeń,
- możliwość dalszego ruchu bocznego w środowisku,
- kompromitacja pipeline’ów budowania i testów,
- wzrost ryzyka ataku na łańcuch dostaw oprogramowania.
Nawet jednorazowe wykonanie spreparowanego pliku może wystarczyć do wycieku danych uwierzytelniających, modyfikacji artefaktów builda albo ustanowienia trwałego punktu dostępu. Szczególnie zagrożone są środowiska, w których agent ma dostęp do prywatnych repozytoriów, systemów chmurowych, menedżerów sekretów lub narzędzi administracyjnych.
Rekomendacje
Najważniejszą zasadą jest to, by agent AI z uprawnieniami do wykonywania komend nie analizował nieufnego kodu bez silnej izolacji. Organizacje powinny traktować treści repozytorium jako dane nieufne, niezależnie od tego, czy są to skrypty, komentarze czy dokumentacja.
- ograniczyć lub wyłączyć tryby autonomiczne podczas pracy z zewnętrznymi repozytoriami,
- wymagać jawnej akceptacji operatora dla każdego polecenia sugerowanego przez dokumentację projektu,
- uruchamiać analizę nieznanego kodu wyłącznie w odseparowanych środowiskach, takich jak jednorazowe maszyny wirtualne lub kontenery,
- blokować automatyczne wykonywanie skryptów i binarek sugerowanych wyłącznie przez README, wiki, komentarze i inne pliki tekstowe,
- monitorować zachowanie agentów pod kątem nietypowych uruchomień, dostępu do sekretów i rozbieżności między kodem źródłowym a artefaktami binarnymi,
- rozszerzyć modele zagrożeń o scenariusze repozytorium jako nośnika prompt injection.
Ważne jest również testowanie guardraili i procedur bezpieczeństwa w praktyce. Same deklaracje producentów narzędzi nie wystarczą, jeśli agent nadal może interpretować nieufną treść jako instrukcję do wykonania.
Podsumowanie
„Friendly Fire” pokazuje, że agenci AI stosowani w DevSecOps i analizie bezpieczeństwa mogą sami stać się celem manipulacji. Problem nie dotyczy wyłącznie pojedynczej implementacji, lecz szerszej słabości projektowej związanej z łączeniem modeli językowych, autonomii działania i możliwości uruchamiania komend.
Dla organizacji oznacza to konieczność rewizji modelu zaufania wobec narzędzi AI analizujących nieznany kod. Bez twardej izolacji, ograniczonych uprawnień i kontroli nad działaniami autonomicznymi wdrożenie takich rozwiązań może zwiększyć ryzyko zamiast je ograniczyć.
Źródła
- The Hacker News — https://thehackernews.com/2026/07/friendly-fire-ai-agents-built-to-catch.html
- AI Now Institute — Proof-of-Concept: Friendly Fire — https://ainowinstitute.org/
- GitHub — Public code repository referenced in the research — https://github.com/
- NVD — CVE-2026-39861 — https://nvd.nist.gov/vuln/detail/CVE-2026-39861