Najtrudniejsze ryzyko autonomicznych agentów AI nie polega na tym, że napiszą zły kod. Zespoły już to wiedzą. Poważniejszy problem zaczyna się wtedy, gdy agent czyta niezaufany tekst i zamienia go w lokalne działanie.

Agent AI za granicą zaufania

Friendly Fire, opublikowany przez AI Now Institute 8 lipca, pokazuje właśnie ten scenariusz. Boyan Milanov i Heidy Khlaaf opisali drogę do wykonania kodu w Anthropic Claude Code CLI i OpenAI Codex CLI, gdy narzędzia te są używane do przeglądu bezpieczeństwa obcej biblioteki.

To nie jest masowy atak na każdego użytkownika. Potrzebny jest agent z możliwością uruchamiania komend, niezaufana codebase i tryb autonomiczny: auto-mode w Claude Code albo auto-review w Codex, według AI Now i The Hacker News. W takim workflow agent czyta repozytorium, interpretuje dokumentację i może uruchomić lokalną komendę bez zatrzymania na człowieka.

Dla firm to sedno sprawy. Agenci trafiają do code review, triage Sentry, generowania poprawek, pracy z zależnościami i CI. Im bardziej są użyteczni, tym więcej narzędzi dostają: shell, filesystem, package manager, repozytoria, czasem sekrety.

Wtedy nie są już chatbotem. Są uprzywilejowaną automatyzacją.

Co pokazuje Friendly Fire

AI Now opisuje zmodyfikowaną kopię biblioteki Python geopy. Badacze dodali tekst w README, skrypt, plik-pułapkę i precompiled binary. Publiczne repozytorium podaje, że opublikowany binary został pozbawiony złośliwego kodu.

Lekcją nie jest payload. Lekcją jest pęknięta granica: agent może przejść od “przeanalizuj projekt” do “uruchom komendę zasugerowaną przez projekt”.

AI Now wymienia testy z Claude Code CLI 2.1.116, 2.1.196, 2.1.198 i 2.1.199, z Claude Sonnet 4.6, Sonnet 5 i Opus 4.8, oraz OpenAI Codex CLI 0.142.4 z GPT-5.5. Autorzy opisują to jako problem projektu workflow, nie pojedynczą wersję do załatania.

Dlaczego wystarczy README

README ma prowadzić czytelnika. Mówi, jak budować, testować i sprawdzać projekt. Człowiek może zatrzymać się przed uruchomieniem nieznanego binary.

Agent chce dokończyć zadanie. Jeśli polityka pozwala mu aprobować część komend, tekst repozytorium może stać się ścieżką od niezaufanych danych do lokalnego wykonania.

To ta sama rodzina ryzyk co injection przez tickety, issues, logi, strony WWW i output narzędzi. Wejście nie wygląda jak kod, ale wpływa na następną akcję agenta.

To nie jest pojedynczy przypadek

Friendly Fire pojawia się po Agentjacking od Tenet Security, gdzie fałszywe zdarzenia Sentry trafiały do agentów przez MCP. Tenet podał 2 388 exposed organizations i 85% success rate w testach kontrolowanych; to liczby z tego badania, nie średnia dla rynku.

Sophos X-Ops pokazał też, że coding agents w Windows EDR telemetry mogą uruchamiać reguły podobne do zachowania atakującego: PowerShell, dostęp do credentials, LOLBin downloads i akcje przypominające persistence.

Raporty są różne. Pytanie operacyjne jest jedno: co agent może zrobić, gdy wejście jest wrogie?

Co zespoły powinny zmienić

Oddziel workflow zaufany od niezaufanego. Porządkowanie wewnętrznego repo to nie to samo co audyt pobranej biblioteki.

Wyłącz automatyczne zatwierdzanie komend dla zewnętrznych repozytoriów, logów, Sentry events i issues.

Daj agentom osobne identities. Nie powinny dziedziczyć pełnego GitHub, cloud i production access developera.

Usuń sekrety z otoczenia: zmienne, SSH keys, browser cookies, password managers i lokalne cloud credentials. Sandbox z prawdziwymi sekretami nie jest granicą.

Scripts, package installs, binary execution, browser automation i network access traktuj jako high-risk actions. W niezaufanych kontekstach wymagają human approval albo blokady.

Loguj input source, tool calls, approved commands, process tree, network destination i file writes. Bez tego incident response kończy się zdaniem “AI coś zrobiło”.

Czego trzeba od dostawców

Agenci potrzebują trust boundaries w produkcie. Niezaufana treść powinna zachować etykietę: repository text, comments, logs, Sentry events, web pages, MCP output. Tool policy powinna mówić: to może pomóc w analizie, ale nie może autoryzować wykonania.

“Autonomous” jest zbyt ogólne. Firmy muszą wiedzieć, czy agent może uruchamiać shell, instalować paczki, odpalać binaries, otwierać sieć, czytać hidden files, używać MCP albo pisać poza workspace.

Admini potrzebują centralnych kontroli: managed settings, audit export, allowlists, deny rules i safe defaults dla security review obcego kodu.

Agenci staną się normalną częścią developmentu. Normalne nie znaczy bezpieczne z definicji. CI runners też są normalne, a firmy i tak je izolują. Praktyczna zasada jest prosta: nie pytaj, czy ufasz agentowi. Określ, co wolno mu zrobić, gdy nie ufasz wejściu.