Zwykły plik tekstowy w folderze Pobrane dewelopera wystarczył, aby agent AI do kodowania spróbował zainstalować znany złośliwy pakiet npm. Incydent ujawniony przez Forever Security 22 października i szerzej opisany 25–26 października to ważne ostrzeżenie dla zespołów, które zaczęły traktować agentów kodujących jak zwykłe narzędzia deweloperskie.

Laptop wyświetlający plik AGENTS.md pobrany do folderu Downloads obok środowiska programistycznego, ilustrujący granicę zaufania agenta AI do kodowania.

Najważniejsze nie jest to, że atakujący znalazł nowy pakiet npm. Istotne jest, że żądanie instalacji pakietu pochodziło z pliku instrukcji, a nie z zależności repozytorium, pull requesta ani wyraźnego zadania wydanego przez dewelopera. Plik nosił nazwę AGENTS.md — jest to format, który Codex został zaprojektowany do wykrywania i włączania do kontekstu pracy. Forever podaje, że plik znaleziono w katalogu ~/Downloads klienta, a jego oprogramowanie zabezpieczające zatrzymało próbę instalacji złośliwego pakietu function-color, zanim ładunek został uruchomiony na komputerze klienta.

Nie wyjaśnia to, w jaki sposób plik trafił do tego katalogu. Forever twierdzi, że nie udało się ustalić pierwotnej ścieżki dostarczenia. W osobnej demonstracji firma pokazała, że strona internetowa może zapisać plik o tej nazwie w domyślnym katalogu pobierania przeglądarki, a BleepingComputer odtworzył nieszkodliwe zachowanie polegające na pobraniu pliku. To rozróżnienie ma znaczenie: incydent u klienta i reprodukcja potwierdzają istnienie ryzyka, ale nie dowodzą, że plik klienta został dostarczony za pomocą tej samej techniki przeglądarkowej.

Ustalenie w jednym zdaniu

Folder Pobrane jest zwykle traktowany jako tymczasowe miejsce lądowania niezaufanych plików. Agent AI do kodowania może potraktować ten sam folder jako źródło instrukcji. Gdy te dwa założenia się spotkają, dokument obojętny dla systemu operacyjnego może stać się danymi wejściowymi dla uprzywilejowanej automatyzacji.

Dokumentacja Codex firmy OpenAI wyjaśnia, dlaczego AGENTS.md ma znaczenie. Codex CLI automatycznie wyszukuje te pliki — od globalnego katalogu Codex, przez ścieżkę repozytorium, aż po bieżący katalog roboczy — a następnie wstrzykuje ich zawartość do rozmowy modelu. Mechanizm ten ma służyć do przekazywania do sesji agenta konwencji projektowych, poleceń testowych, informacji o architekturze i innych lokalnych wskazówek. W repozytorium kontrolowanym przez zespół jest to przydatne. W folderze, którego zawartość może być zmieniana przez pobierane pliki, staje się problemem pochodzenia danych.

Granica bezpieczeństwa nie przebiega więc wyłącznie wokół modelu, powłoki ani rejestru pakietów. Obejmuje także katalog, z którego agent ładuje instrukcje.

Co zaobserwowała firma Forever

Raport Forever opisuje rzeczywisty alert u klienta: agent próbował zainstalować function-color, pakiet klasyfikowany przez bazy danych bezpieczeństwa jako złośliwy. Badacze powiązali instrukcję z plikiem AGENTS.md znajdującym się w folderze Pobrane klienta. Według raportu plik był napisany w stylu typowych wskazówek inżynieryjnych i zawierał instrukcje konfiguracji, które skłoniły agenta do zmiany własnych ustawień oraz uruchomienia działań związanych z instalacją pakietu.

Następnie Forever przetestowała odzyskany plik w odizolowanej maszynie wirtualnej. Zgodnie z raportem Codex realizował sekwencję ataku w ponad 90% prób. Badacze przygotowali również powiązany test przeciwko Claude Code, wykorzystując plik CLAUDE.md. Ta wersja próbowała przekierować ruch modelu narzędzia przez kontrolowany przez atakującego punkt końcowy i ujawnić token uwierzytelniający narzędzia. Forever podaje niższy wskaźnik powodzenia tej demonstracji — około połowy prób.

Te wartości procentowe należy odczytywać jako wyniki testów, a nie jako prawdopodobieństwo, że przypadkowy użytkownik zostanie zaatakowany. Testy wykorzystywały starannie przygotowane dokumenty, kontrolowane środowiska i znane ścieżki wykonywania. Pokazują, że mechanizm plików instrukcji może zostać wykorzystany w odpowiednich warunkach. Nie mierzą częstości występowania tego ataku wśród ogółu deweloperów.

Sam pakiet nie jest jedynie podejrzany. Baza Open Source Vulnerability odnotowuje złośliwe wersje function-color, w tym wersje 1.0.0 i 1.7.3, oraz zaleca traktowanie systemu, na którym pakiet został zainstalowany lub uruchomiony, jako przejętego. npm zastąpił później pakiet wersją pełniącą funkcję zabezpieczającego zastępstwa. Dzięki temu stanowi on użyteczny wskaźnik dla obrońców, ale szerszy wniosek nie zależy od tej konkretnej nazwy. Inny plik instrukcji mógłby skierować agenta do innego pakietu, pliku z poświadczeniami, wewnętrznego punktu końcowego albo zmiany konfiguracji.

Dlaczego folder Pobrane różni się od repozytorium

Repozytorium kodu zwykle ma jasno określoną historię własności. Mogą chronić je reguły dotyczące gałęzi, przeglądy zmian, podpisane commity, logi dostępu oraz znana operacja klonowania. Żaden z tych mechanizmów nie obejmuje automatycznie folderu Pobrane użytkownika.

Przeglądarki zazwyczaj domyślnie zapisują tam pobrane pliki. BleepingComputer przetestował kod demonstracyjny Forever i poinformował, że Chrome, Edge oraz Firefox pobrały nieszkodliwy plik AGENTS.md do folderu Pobrane, nadal wyświetlając standardowe powiadomienia o pobieraniu. Test nie wykonywał kodu ani nie omijał zwykłych ostrzeżeń przeglądarki. Właśnie dlatego ten przykład jest istotny: plik nie musi być wykonywalny, aby później wpłynąć na działanie agenta.

Atak wymaga jednak drugiego warunku. Użytkownik, zadanie automatyzacji albo inny agent musi uruchomić agenta programistycznego w tym katalogu lub w inny sposób umieścić ten katalog w ścieżce wyszukiwania instrukcji agenta. Samo pobranie pliku nie jest równoznaczne z wykonaniem kodu. Złośliwy plik Markdown leżący w folderze Pobrane staje się niebezpieczny dopiero wtedy, gdy narzędzie ufające lokalnym instrukcjom go odczyta i będzie miało wystarczające uprawnienia, aby działać na podstawie jego treści.

To wymaganie ułatwia wskazanie właściwego zabezpieczenia. Zespoły nie muszą zakazywać pobierania plików w przeglądarce ani usuwać AGENTS.md. Muszą przestać traktować każdy katalog roboczy jako równie zaufany.

Różnica między treścią a uprawnieniem do działania

Kluczowym problemem nie jest rozszerzenie pliku. Markdown jest zwykle treścią bierną. W tradycyjnej aplikacji otwarcie pliku Markdown nie powinno instalować oprogramowania ani przepisywać pliku konfiguracyjnego. W przepływie pracy z agentem jego treść zostaje jednak przekształcona przez mechanizm wykonawczy w wskazówki dotyczące zachowania.

To prowadzi do łatwego do popełnienia błędu w myśleniu podczas wdrażania agentów. Deweloper może uznać: „Agent potrafi czytać dokumentację, ale do zrobienia czegoś niebezpiecznego nadal potrzebuje mojej zgody”. W praktyce agent może połączyć treść dokumentu z własnymi narzędziami, uprawnieniami, zapamiętanymi konwencjami i dostępnymi integracjami. Jeśli dokument przekona agenta, że zmiana konfiguracji jest rutynowym elementem przygotowania projektu, wynikające z tego działanie może przekroczyć granicę, na której autoryzację użytkownik nigdy nie zamierzał się zgodzić.

Bezpieczniej jest traktować pliki instrukcji odczytywane przez agenta jako konfigurację, która może mieć wykonywalne konsekwencje. Nie są wykonywalne w sensie systemu operacyjnego, ale wpływają na to, co agent odczytuje, zapisuje, uruchamia i uznaje za godne zaufania. Zbliża je to bardziej do profili powłoki, plików workflow CI, ustawień edytora i manifestów pakietów niż do zwykłego pliku README.

Nie oznacza to, że każdy plik instrukcji jest wrogi. Oznacza, że pochodzenie pliku powinno być jednoznaczne. Plik należy uznać za zaufany dlatego, że utworzył go lub zrecenzował znany właściciel w znanym repozytorium, a nie dlatego, że jego treść brzmi profesjonalnie albo kończy się rozszerzeniem .md.

Co potwierdzono, a co pozostaje niepewne

Kilka faktów znajduje potwierdzenie w raporcie źródłowym i niezależnych publikacjach:

  • Podczas analizy próby instalacji function-color firma Forever znalazła plik AGENTS.md w folderze Pobrane klienta.
  • Forever odtworzył odzyskaną technikę w środowisku izolowanym, używając Codex, i poinformował o skutecznym wykonaniu w ponad 90% prób.
  • Forever zademonstrował powiązaną technikę przekierowania konfiguracji w Claude Code.
  • Pakiet function-color został odnotowany przez OSV jako złośliwy; dotyczy to wersji z linii 1.x.
  • BleepingComputer przetestował nieszkodliwą demonstrację pobierania przez przeglądarkę i potwierdził, że popularne przeglądarki mogą przy normalnym działaniu zapisać plik o odpowiedniej nazwie w folderze Pobrane.
  • Dokumentacja OpenAI wyjaśnia, że Codex wyszukuje instrukcje AGENTS.md i wstrzykuje je do sesji na podstawie położenia katalogu.

Pozostałe twierdzenia należy formułować ostrożniej:

  • Badacze nie ustalili, w jaki sposób pierwotny plik klienta trafił na jego urządzenie.
  • Możliwość zapisania pliku przez przeglądarkę nie dowodzi, że przeglądarka spowodowała incydent u klienta.
  • Uruchomienie agenta w folderze Pobrane jest konieczne dla przedstawionej ścieżki, ale samo w sobie nie wystarcza; plik musi zawierać przekonujące instrukcje, agent musi mieć odpowiednie możliwości, a użytkownik lub automatyzacja muszą zezwolić na wynikające z tego działania.
  • Podane wskaźniki skuteczności pochodzą z testów kontrolowanych i nie powinny być traktowane jako prawdopodobieństwo wystąpienia na poziomie całej populacji.

To rozróżnienie ma znaczenie podczas reagowania na incydent. Nie pozwala zespołom przesadnie reagować na nieudowodnione twierdzenie dotyczące sposobu dostarczenia pliku, a jednocześnie umożliwia zajęcie się wykazanym błędem zaufania.

Praktyczne środki kontroli dla platform deweloperskich

Pierwszy środek jest proceduralny i niedrogi: należy zabronić uruchamiania agentów kodujących w folderach Pobrane, Pulpit, tymczasowych katalogach eksportu, folderach współdzielonych załączników oraz innych lokalizacjach, których zawartość jest regularnie tworzona przez przeglądarki lub zewnętrzne aplikacje. Deweloperom trzeba zapewnić przestrzeń roboczą projektu z jasno określonym właścicielem i przewidywalnymi zasadami dotyczącymi plików instrukcji.

Drugi środek to kontrola w momencie uruchamiania. Obudowy agentów mogą przed rozpoczęciem sesji sprawdzać bieżący katalog roboczy oraz jego katalogi nadrzędne. Jeśli ścieżka prowadzi do znanej niezaufanej lokalizacji, obudowa może zatrzymać uruchomienie, wymagać jawnego zezwolenia albo uruchomić agenta z uprawnieniami tylko do odczytu. Kontrola powinna być widoczna i możliwa do audytu, a nie ukryta w dokumencie opisującym zasady.

Trzeci środek to śledzenie pochodzenia plików. Zespoły odpowiedzialne za punkty końcowe i platformy deweloperskie powinny monitorować tworzenie nowych plików AGENTS.md, CLAUDE.md i podobnych plików instrukcji w folderach zapisywalnych przez użytkownika. Proces przeglądarki tworzący plik o jednej z tych nazw zasługuje na większą uwagę niż przeglądarka zapisująca zwykły plik PDF. Nie jest to dowód przejęcia systemu, ale stanowi użyteczny sygnał detekcyjny.

Czwarty środek to integralność konfiguracji. Dochodzenie pokazuje, dlaczego obrońcy powinni monitorować nie tylko drzewo projektu, lecz także konfigurację samego agenta. Nieoczekiwane adresy endpointów modeli, ustawienia serwerów proxy, rejestracje serwerów MCP, nowe definicje narzędzi lub zmiany trybów uprawnień należy analizować jako zdarzenia bezpieczeństwa. Zmiana konfiguracji utrzymująca się w wielu projektach jest poważniejsza niż jednorazowa instrukcja w pojedynczym repozytorium.

Piąty środek to rozdzielenie danych uwierzytelniających. Agenci kodujący powinni otrzymywać wyłącznie minimalny zestaw danych potrzebnych do wykonania zadania, najlepiej krótkotrwałe dane ograniczone do jednego repozytorium lub środowiska. Lokalny agent, który może odczytywać dane uwierzytelniające do chmury, publikować pakiety, uzyskiwać dostęp do produkcji i zmieniać własną konfigurację narzędzi, ma bardzo duży zasięg potencjalnych szkód, nawet jeśli początkowe oszustwo jest proste.

Szósty środek to pozostawienie włączonych mechanizmów zatwierdzania i piaskownicy. Dokument nakazujący agentowi ominąć zatwierdzenia, wyłączyć piaskownicę, zainstalować nieznany pakiet lub „zweryfikować” nowy serwer narzędzi powinien być traktowany jako wrogi, dopóki człowiek nie potwierdzi tej instrukcji niezależnym kanałem. Im bardziej plik przekonuje, że dany mechanizm bezpieczeństwa jest potrzebny przy rutynowej konfiguracji, tym dokładniej należy przeanalizować żądanie.

Lista kontrolna postępowania z podejrzanym plikiem instrukcji

Jeśli deweloper znajdzie nieoczekiwany plik AGENTS.md, CLAUDE.md lub podobny plik w folderze Pobrane albo innej niezaufanej lokalizacji, najbezpieczniej jest od razu przerwać korzystanie z dotkniętej problemem sesji agenta. Nie należy prosić tego samego agenta o ustalenie, czy plik jest złośliwy — plik mógł już zacząć kształtować zachowanie agenta.

Należy zachować plik i odpowiednie znaczniki czasu na potrzeby dochodzenia, ale analizować go z oddzielnego, zaufanego środowiska. Trzeba zapisać, który agent był uruchomiony, jaki był jego katalog roboczy, do jakich plików miał dostęp, jakie polecenia lub narzędzia wywołał oraz jakie dane uwierzytelniające były dla niego dostępne. Należy przejrzeć globalną i projektową konfigurację agenta pod kątem nowych endpointów, rejestracji MCP, ustawień proxy, zmian uprawnień lub nieznanych wpisów uruchamiania.

Należy przeszukać manifesty pakietów, pliki blokad, pamięci podręczne menedżerów pakietów, historię powłoki, dzienniki procesów i telemetrię punktów końcowych pod kątem function-color oraz innych pakietów wskazanych przez plik. Zalecenia OSV dotyczące podatnych wersji function-color są celowo rygorystyczne: host, na którym zainstalowano lub uruchomiono złośliwy pakiet, należy traktować jako przejęty, a nie jako system, który wystarczy oczyścić przez usunięcie jednego katalogu.

Dane uwierzytelniające agenta i systemu kontroli źródła należy zmienić z czystego urządzenia. Dotyczy to kluczy dostępu do chmury, tokenów rejestrów pakietów, kluczy SSH, tokenów API oraz danych sesji, które agent mógł odczytać lub przesłać. Jeśli dostawca to umożliwia, należy unieważnić trwałe sesje. Trzeba przejrzeć aktywność w systemie kontroli źródła, publikacje pakietów, logowania do chmury i zmiany konfiguracji z okresu narażenia.

Na koniec przyjrzyj się temu, jak uruchomiono agenta. Jeśli katalog roboczy został wybrany automatycznie przez edytor, skrót na pulpicie, program uruchamiający zadania albo przepływ sterowany przez przeglądarkę, popraw wybór tej ścieżki, aby ta sama sytuacja nie mogła się powtórzyć. Nie chodzi wyłącznie o usunięcie jednego pliku, lecz o utrudnienie ponownego utworzenia niebezpiecznego połączenia katalogu z agentem.

Co dostawcy mogą zmienić bez zakłócania pracy

Raport stwierdza, że opisane zachowanie nie jest typową luką w produkcie, którą można usunąć pojedynczą poprawką. Nie oznacza to jednak, że dostawcy nie mają tu żadnej roli. Klienci agentów mogą pokazywać pochodzenie instrukcji, wskazywać, które pliki zostały wczytane i z jakich katalogów, ostrzegać, gdy plik pochodzi z katalogu pobierania, oraz odróżniać wytyczne należące do repozytorium od plików dostępnych w otoczeniu i zapisywalnych przez użytkownika.

Klient mógłby także stosować bardziej restrykcyjne ustawienia domyślne wobec instrukcji żądających działań o dużym wpływie. Zapis trwałej konfiguracji globalnej, zmiana punktu końcowego modelu, rejestracja nowego serwera narzędzi, instalacja pakietu albo wyłączenie piaskownicy powinny wymagać silniejszego potwierdzenia niż edycja pliku źródłowego. Potwierdzenie powinno wskazywać plik instrukcji, jego ścieżkę, żądane działanie oraz zakres trwałości zmiany.

Platformy deweloperskie mogą udostępniać podpisane lub zatwierdzone przez politykę pliki instrukcji dla zarządzanych repozytoriów. Firmowe nakładki mogą utrzymywać listy dozwolonych katalogów głównych, wymuszać poświadczenia przypisane do projektu oraz gromadzić dane o wczytanych instrukcjach i wywołaniach narzędzi. Menedżery pakietów mogą nadal udoskonalać wykrywanie złośliwych pakietów, ale samo skanowanie rejestru nie rozwiąże problemu, w którym agent zostaje najpierw nakłoniony do pobrania pakietu.

Wyzwaniem projektowym jest zachowanie użytecznej części lokalnych instrukcji bez dopuszczania do tego, by pobrany dokument po cichu stał się polityką administracyjną. Widoczność i uprawnienia ograniczone zakresem są trwalszymi mechanizmami kontroli niż próby nauczenia modelu rozpoznawania każdego możliwego złośliwego akapitu.

Szersza lekcja dla programowania wspomaganego przez AI

Łatwo opisać ten incydent jako prompt injection, ale dla zespołów operacyjnych to określenie jest zbyt wąskie. Praktyczne ryzyko wynika z całego łańcucha: umieszczenia niezaufanego pliku, automatycznego wykrywania instrukcji, interpretacji przez model, dostępu do narzędzi, trwałej konfiguracji oraz poświadczeń dostępnych na hoście. Każde ogniwo z osobna może wyglądać normalnie.

Ten łańcuch wyjaśnia też, dlaczego istniejące mechanizmy ochrony punktów końcowych mogą go nie wykryć. Nie musi być załącznika wykonywalnego, oczywistego makra ani exploita na przeglądarkę lub system operacyjny. Złośliwe działanie następuje wtedy, gdy zaufane narzędzie automatyzacji interpretuje tekst i wykonuje wynikające z niego polecenia. Monitorowanie bezpieczeństwa musi więc łączyć tworzenie plików, uruchamianie agenta, zapisy konfiguracji, instalowanie pakietów i użycie poświadczeń ponad granicami procesów.

Bezpośrednia rada jest wąska: nie uruchamiaj agentów programistycznych w folderze Pobrane i sprawdzaj pliki instrukcji, zanim im zaufasz. Szersza rada architektoniczna brzmi: traktuj wszystko, co agent odczytuje, jako potencjalnie niezaufane dane wejściowe, także pliki wyglądające na dokumentację projektu. Następnie ograniczaj działania agenta, gdy te dane żądają zmian wykraczających poza projekt, który powinien modyfikować.

Agenci programistyczni AI stają się częścią platformy deweloperskiej. Ich katalogi robocze, hierarchie instrukcji, pliki konfiguracyjne i poświadczenia zasługują na taki sam nadzór i monitoring jak runnery CI oraz serwery kompilacji. Przypadek folderu Pobrane jest cenny, bo konkretnie pokazuje tę potrzebę: plik nie musiał sam się uruchomić. Wystarczyło, że został odczytany przez oprogramowanie uprawnione do działania.