Złośliwy plik AGENTS.md jako nowy wektor ataku na agentów AI w środowiskach deweloperskich

securitybeztabu.pl 22 godzin temu

Wprowadzenie do problemu / definicja

Pośredni prompt injection wobec agentów AI staje się jednym z istotniejszych zagrożeń dla nowoczesnych środowisk deweloperskich. W opisywanym scenariuszu atakujący nie musi komunikować się z modelem bezpośrednio. Zamiast tego umieszcza złośliwe instrukcje w lokalnym pliku Markdown, który agent interpretuje jako wiążące wytyczne operacyjne.

Szczególnie niebezpieczne są pliki takie jak AGENTS.md, używane przez narzędzia programistyczne do przekazywania trwałych zasad pracy, konfiguracji i instrukcji projektowych. W efekcie zwykły dokument tekstowy może zostać potraktowany nie jako notatka, ale jako nośnik sterujący zachowaniem agenta.

W skrócie

Badacze opisali atak, w którym złośliwy plik AGENTS.md trafiał do katalogu pobierania użytkownika, a następnie był odczytywany przez agenta kodującego jako zaufane źródło instrukcji. To pozwalało wpływać na konfigurację narzędzia i uruchamiać dalszy łańcuch działań.

atak wykorzystuje lokalny plik Markdown zamiast klasycznej luki w oprogramowaniu,
wektor wejścia pojawia się w katalogach osiągalnych dla treści pobranych z internetu,
skutkiem może być zmiana konfiguracji agenta, ujawnienie sekretów lub uruchomienie dodatkowych poleceń,
problem dotyczy granic zaufania, a nie błędu typu memory corruption czy parser exploit.

Kontekst / historia

Agenci AI wspierający programowanie coraz częściej korzystają z plików instrukcyjnych przechowywanych w repozytorium lub katalogu roboczym. Takie podejście ma uzasadnienie praktyczne, ponieważ pozwala utrzymywać stały kontekst projektu, standardy kodowania i preferowane procedury wykonywania zadań.

Do tej pory wiele dyskusji o prompt injection koncentrowało się na eksperymentach badawczych oraz laboratoryjnych proof of concept. Tym razem problem nabrał bardziej praktycznego wymiaru, ponieważ opisany przypadek dotyczył incydentu wykrytego w realnym środowisku klienta. To oznacza, iż zagrożenie przestaje być wyłącznie koncepcją teoretyczną i staje się ryzykiem operacyjnym dla zespołów korzystających z agentów z dostępem do systemu plików, przeglądarki i danych uwierzytelniających.

Analiza techniczna

Mechanizm ataku jest prosty, ale skuteczny. Napastnik doprowadza do zapisania złośliwego pliku AGENTS.md w katalogu Downloads lub innej lokalizacji, do której mogą trafiać pliki pobrane z internetu. Następnie agent, uruchomiony w tym katalogu albo względem niego, traktuje plik jako część kontekstu projektu i odczytuje zawarte w nim polecenia.

Kluczowe znaczenie ma fakt, iż część agentów programistycznych rzeczywiście uznaje pliki tego typu za uprzywilejowane źródło instrukcji. jeżeli złośliwy Markdown zostanie odpowiednio sformułowany, może nakłonić narzędzie do przepisania konfiguracji, wykonania komend pomocniczych lub osłabienia zabezpieczeń operacyjnych.

instalacja pakietów i zależności,
uruchamianie poleceń systemowych,
dostęp do treści webowych lub sesji przeglądarki,
ujawnienie tokenów i poświadczeń,
modyfikacja ustawień bezpieczeństwa i akceptacji działań.

Nie jest to klasyczna podatność w rozumieniu zdalnego wykonania kodu przez błąd parsera czy mechanizmu autoryzacji. Problem wynika z założenia architektonicznego, iż lokalny plik instrukcyjny znajdujący się obok danych roboczych jest godny zaufania. Gdy jednak ten sam katalog może zostać zasilony treścią z internetu, model zaufania przestaje być bezpieczny.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiego ataku jest przejście od biernego wpływu na odpowiedzi modelu do aktywnego sterowania narzędziem posiadającym uprawnienia w systemie operacyjnym. To zmienia charakter ryzyka z informacyjnego na operacyjny.

W praktyce zagrożone są przede wszystkim sekrety wykorzystywane przez deweloperów i pipeline’y automatyzacji. Mowa o tokenach do repozytoriów, rejestrów pakietów, usług CI/CD, chmury oraz komunikatorów. jeżeli agent uzyska instrukcję ich odczytu lub wyeksponowania, incydent może gwałtownie objąć znacznie większy obszar niż pojedyncza stacja robocza.

Dodatkowym problemem jest możliwość utrwalenia zmian. jeżeli agent zmodyfikuje własną konfigurację albo zapisze nowe instrukcje do środowiska roboczego, skutki mogą być widoczne także w kolejnych sesjach. Taki scenariusz zwiększa szansę na długotrwałą kompromitację procesu deweloperskiego.

Rekomendacje

Organizacje korzystające z agentów AI do programowania powinny potraktować ten scenariusz jako problem hardeningu środowiska końcowego, ograniczania zaufania do kontekstu wejściowego oraz ochrony sekretów.

nie uruchamiać agentów kodujących w katalogu Downloads ani w innych lokalizacjach osiągalnych bezpośrednio dla treści z internetu,
traktować katalog pobierania jako strefę niezaufaną i wykluczyć go z domyślnych ścieżek roboczych,
sprawdzać obecność plików AGENTS.md, CLAUDE.md i podobnych instrukcji przed rozpoczęciem sesji,
utrzymywać włączone mechanizmy zatwierdzania działań, sandboxing i ograniczenia wykonywania poleceń,
minimalizować dostęp agentów do katalogu domowego, przeglądarki i poświadczeń,
monitorować zmiany w konfiguracji agentów oraz pojawianie się nowych plików instrukcyjnych,
rotować poświadczenia w razie podejrzenia ich odczytu lub ujawnienia,
rozdzielać środowiska do przeglądania internetu i pracy z kodem oraz sekretami,
wdrożyć polityki EDR lub XDR wykrywające nietypowe użycie agentów i modyfikacje plików konfiguracyjnych,
szkolić zespoły, iż Markdown w kontekście agentowym może pełnić rolę instrukcji wykonawczej.

Z perspektywy producentów narzędzi potrzebne są dodatkowe zabezpieczenia, takie jak ostrzeganie przed plikami pochodzącymi z katalogów wysokiego ryzyka, jawne potwierdzanie odczytu instrukcji oraz lepsza separacja dokumentacji od plików sterujących zachowaniem agenta.

Podsumowanie

Atak z wykorzystaniem złośliwego pliku AGENTS.md pokazuje, iż wraz z rozwojem agentów AI rośnie znaczenie błędów w modelu zaufania, a nie tylko tradycyjnych podatności programistycznych. jeżeli lokalny Markdown może wpływać na zachowanie narzędzia z szerokimi uprawnieniami, choćby zwykły katalog pobierania staje się potencjalnym punktem wejścia dla incydentu bezpieczeństwa.

Dla zespołów bezpieczeństwa i DevSecOps to sygnał, iż ochrona endpointów oraz procesów deweloperskich musi zostać rozszerzona o kontrole specyficzne dla agentów AI. Granica między dokumentacją a instrukcją wykonawczą staje się coraz mniej wyraźna, a to wymaga nowego podejścia do polityk zaufania i segmentacji środowisk.