Bezpieczeństwo AGENTS.md: jak obce pliki sterują agentami AI

W jednym przypadku niepozorny plik tekstowy w folderze Pobrane wystarczył, by agent AI do programowania chciał zainstalować złośliwy pakiet. Ten tekst dotyczy bezpieczeństwa AGENTS.md: opisuje, co się stało, jakie pliki z instrukcjami ładują Codex, Claude Code i Cursor oraz jakie ustawienia i środki mogą zapobiec szkodom.

Znalezisko na komputerze klienta i jego skutki

Dostawca zabezpieczeń Forever Security ustalił, że na komputerze jednego z klientów w folderze Pobrane leżał plik z instrukcjami o nazwie AGENTS.md, który miał skłonić agenta AI do programowania do zainstalowania pakietu npm. Plik nie jest programem, ale działa jak instrukcja postępowania.

Co się stało: znalezisko w folderze Pobrane, test kontrolny i skuteczność

Punktem wyjścia było rzeczywiste znalezisko. Plik leżał w folderze Pobrane pewnego programisty. Folder ten był jednocześnie katalogiem roboczym agenta. Agent chciał zainstalować pakiet npm function-color. Według własnej relacji Forever Security zatrzymało go, zanim uruchomiono jakikolwiek kod. Badaczom nie udało się ustalić, jak plik trafił do folderu.

Pakiet function-color pociąga za sobą kolejny pakiet o nazwie function-flag. Ten pobiera i uruchamia złośliwe oprogramowanie dla Windows. CloudSEK i Checkmarx nazywają tę kampanię MALFEX.

Test kontrolny z Codex

Forever Security odtworzyło atak na odizolowanej maszynie wirtualnej. Prawdziwy plik nakazywał Codex zarejestrować serwer w pliku ~/.codex/config.toml i wykonać polecenie, które instaluje pakiet. Ponieważ ta konfiguracja obowiązuje we wszystkich sesjach Codex na danym komputerze, zmiana działa trwale i w każdym folderze. Skuteczność wynosiła ok. 90 procent.

Test kontrolny z Claude Code

W przypadku Claude Code użyto innego pliku. Spreparowany CLAUDE.md podawał się za konfigurację wewnętrznej bramy i miał skłonić agenta do wpisania obcego adresu jako celu API w pliku ustawień projektu. Ruch API trafiałby wtedy na serwer badaczy. Ujawnia to token uwierzytelniający sesji, a serwer może odsyłać polecenia, które agent wykonuje. Claude Code zwykle wymaga potwierdzenia takich zapisów i często odrzuca podejrzane. Dopiero długie uzasadnienie, brzmiące niemal jak dokumentacja dla programistów, przyniosło zgodę w mniej więcej połowie przypadków.

Obu liczb nie da się bezpośrednio porównać. Chodzi o różnych agentów, różne pliki i różne cele. Wielkość próby i konfiguracja testu (sandbox, tryb zatwierdzania) są nieznane.

Telemetria: jak często agent startuje w folderze Pobrane?

Około połowa klientów Forever Security uruchamia agenta do programowania w folderze Pobrane, a mniej więcej jedna czwarta sesji otwiera przeglądarkę. BleepingComputer podaje ponad 1300 sesji Claude Code z tego folderu. Obie informacje to dane dostawcy o własnych klientach, niezależnej weryfikacji brak. Nie jest udowodnione, czy atakujący w praktyce rzeczywiście podrzucają takie pliki przez pobieranie w przeglądarce. Proof of concept pobierał jedynie nieszkodliwy plik.

Bezpieczeństwo AGENTS.md: dlaczego obce pliki z instrukcjami są ryzykiem

Agenci do programowania przy starcie czytają pliki z instrukcjami z katalogu roboczego. Znajdują się w nich instrukcje budowania, zasady stylu lub polecenia testów. Agent traktuje tę treść jak polecenia użytkownika. Nie odróżnia niezawodnie, czy plik pochodzi od zespołu, czy z obcego źródła. To istota pośredniego prompt injection wobec agenta do programowania: instrukcja nie pochodzi z pola wprowadzania, lecz z kontekstu.

Dwie z osobna nieszkodliwe właściwości tworzą razem łańcuch. Po pierwsze, agenci ufają plikom w otwartym folderze. Po drugie, strony internetowe mogą bez pytania zapisywać pliki w folderze Pobrane, jeśli przeglądarka jest tak skonfigurowana. Chrome, Edge i Firefox domyślnie zapisują do tego folderu bez pytania o lokalizację i pokazują tylko powiadomienie. Brave w teście pytał wcześniej. Plik ma taką nazwę i treść, jaką narzuci strona.

Dokumentacja Claude Code opisuje CLAUDE.md jako kontekst, a nie wymuszaną konfigurację. Do blokad zaleca hooki. Stąd podstawowa zasada dla wszystkiego, co dalej: to, co jest zapisane jedynie w treści pliku, agent może wykonać albo zignorować. To, co stoi w uprawnieniach, program wymusza.

Przeglądarka to nie jedyna droga

W tym przypadku folder Pobrane stoi w centrum, ale nie jest jedyny. NVIDIA Developer Blog opisuje pokrewną drogę: przejęty pakiet zależności sam tworzy plik AGENTS.md. Również sklonowane repozytoria, rozpakowane archiwa i skrypty budowania mogą wnieść obce pliki z instrukcjami do folderu projektu. Miejsce startu zmniejsza więc powierzchnię ataku, ale jej nie usuwa.

Ocena: co mówią badacze i producenci

Badacze z Forever Security twierdzą, że OpenAI i Anthropic nie mają tu czego łatać. Agent wykonuje swój plik z instrukcjami zgodnie z założeniem, podobnie jak przeglądarka, która wyświetla stronę phishingową. To ocena badaczy. Oba raporty nie zawierają własnego stanowiska producentów w sprawie tego ataku. BleepingComputer wskazuje jedynie, że obaj producenci zalecają uruchamianie agentów w odpowiednim katalogu projektu. Odpowiedzialność spoczywa więc na użytkownikach i na organizacjach, które wdrażają agentów.

Ryzyka autonomicznych agentów to szerszy temat. Teksty o władzy bez kontroli w przypadku agentów AI i o epoce agentów AI wyjaśniają, dlaczego agenci z własnymi uprawnieniami do działania potrzebują innych zabezpieczeń niż klasyczne oprogramowanie.

Jakie pliki z instrukcjami ładują Codex, Claude Code i Cursor

Decydujące jest to, co uchodzi za folder projektu: folder, w którym agent zostaje uruchomiony. Kto startuje w folderze Pobrane, zamienia każdy leżący tam plik w kontekst projektu. Poniższe zestawienie streszcza dokumentację producentów (stan na 26.10.2026). Dokumentacja szybko się zmienia, w razie wątpliwości obowiązuje aktualna wersja.

Codex

Według dokumentacji Codex najpierw czyta globalny plik w katalogu Codex (~/.codex, zmienny przez CODEX_HOME), czyli AGENTS.override.md lub AGENTS.md. Następnie pliki od katalogu głównego projektu, zwykle katalogu głównego Git, aż do bieżącego folderu. W każdym folderze uwzględniany jest najwyżej jeden plik: AGENTS.override.md, AGENTS.md lub skonfigurowana nazwa zastępcza. Łączny limit wynosi 32 KiB. Jeśli nie zostanie znaleziony katalog główny projektu, liczy się tylko bieżący folder. Dokładnie to dotyczy folderu Pobrane, bo zwykle nie ma w nim repozytorium Git.

Claude Code i bezpieczeństwo CLAUDE.md

Według dokumentacji pamięci Claude Code ładuje CLAUDE.md i CLAUDE.local.md z katalogu roboczego i ze wszystkich katalogów nad nim, w razie potrzeby także z podfolderów. Do tego dochodzą ~/.claude/CLAUDE.md, zarządzana polityka systemu oraz pliki w .claude/rules/. Dla bezpieczeństwa CLAUDE.md oznacza to: również zbyt wysoko położony punkt startu, na przykład katalog domowy, zwiększa powierzchnię ataku, bo wczytywane są też pliki powyżej i obok.

AGENTS.md Claude Code czyta (według dokumentacji od wersji 2.1.277). Domyślnie dzieje się to tylko wtedy, gdy w katalogu roboczym ani powyżej nie ma CLAUDE.md ani CLAUDE.local.md. Można to zmienić ustawieniem dotyczącym instrukcji projektu: claude-md-or-agents-md to wartość domyślna, claude-md-and-agents-md czyta oba pliki, managed-only dopuszcza tylko centralnie zarządzane instrukcje.

Cursor

Według dokumentacji Cursor obsługuje reguły projektu w .cursor/rules/ (pliki w formacie .mdc, także w podfolderach) oraz AGENTS.md w katalogu głównym projektu i w podkatalogach. Zagnieżdżone pliki obowiązują w swoim zakresie, bardziej szczegółowy wygrywa. Do tego dochodzą osobiste User Rules w ustawieniach i Team Rules przez panel.

Pliki konfiguracyjne jako właściwy cel

Ten przypadek pokazuje, że plik z instrukcjami jest często tylko narzędziem. Celem są pliki konfiguracyjne, w których zmiana działa trwale. W Codex jest to ~/.codex/config.toml, którego zmiana dotyczy wszystkich sesji. W Claude Code jest to plik ustawień .claude/settings.json, w którym przez zmienną środowiskową można ustawić cel API. Oba pliki należą więc do listy plików, których agent nie może zmieniać bez potwierdzenia.

Zabezpieczanie agentów AI do programowania: uprawnienia, hooki i sandbox Codex

Nasuwa się pytanie, czy wystarczy zrezygnować z folderu Pobrane.

Środki działają w trzech miejscach: co agent może zrobić bez potwierdzenia, co hook blokuje niezależnie od modelu i co sandbox ogranicza technicznie.

Reguły uprawnień w Claude Code

Claude Code zna reguły na poziomach allow, ask i deny dla każdego narzędzia (dokumentacja uprawnień). Domyślnie agent pyta przed poleceniami powłoki i zmianami plików. Reguła deny obowiązuje również wtedy, gdy agent chce wykonać polecenia z pliku z instrukcjami. Przykład dla pliku .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(npm install *)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(.claude/**)",
      "Edit(~/.codex/**)"
    ]
  }
}

Zapis jest zgodny z przykładami z dokumentacji: reguły Bash porównują tekst polecenia z * jako symbolem wieloznacznym, reguły ścieżek dla odczytu i edycji używają składni gitignore, ~/ oznacza katalog domowy. Zmiany plików reguluje się przez Edit(…), reguły dla Write według dokumentacji nie są sprawdzane względem ścieżek. Blokada polecenia nie jest przy tym gwarancją, bo ten sam cel często da się osiągnąć innym wywołaniem. Na to, czego nie da się uniknąć, przeznaczone są hooki i sandbox.

Ostrożności wymagają dwie funkcje wygody. Zgoda z opcją „nie pytaj ponownie” zależnie od narzędzia obowiązuje na stałe dla repozytorium, a w trybach automatycznych to już nie człowiek decyduje o każdej akcji. Żadne z nich nie pasuje do środowisk z obcym kodem.

Hooki: blokady niezależne od modelu

Hook PreToolUse działa przed wywołaniem narzędzia i może je zablokować, nawet jeśli model uważa je za słuszne. Przewodnik po hookach pokazuje wzorzec: skrypt czyta dane wejściowe jako JSON ze standardowego wejścia i kończy się kodem wyjścia, aby zablokować. Rejestruje się go w pliku ustawień:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-installs.sh"
          }
        ]
      }
    ]
  }
}

Skrypt block-installs.sh odczytuje za pomocą jq polecenie z pola tool_input.command, sprawdza je względem listy blokad (na przykład npm install albo połączenie curl i powłoki) lub lepiej względem listy dozwolonych i przy trafieniu zgłasza uzasadnienie na standardowym wyjściu błędów z kodem wyjścia 2. Drugą, mało znaną dźwignią jest hook InstructionsLoaded. Rejestruje on załadowane pliki z instrukcjami. Według dokumentacji nie uruchamia się jednak dla AGENTS.md ładowanego przez ustawienie, lecz tylko wtedy, gdy importuje go CLAUDE.md. Zespół nie powinien więc polegać wyłącznie na nim.

Centralne zasady dzięki Managed Settings

Dla zespołów najskuteczniejszą dźwignią są zarządzane ustawienia. Według dokumentacji Managed Settings permissions.deny, sandbox.enabled i env można wymusić centralnie. Podrzucenie celu API przez plik z instrukcjami, jak w teście z Claude Code, byłoby wtedy znacznie trudniejsze. Dla porządku: to wniosek z dokumentacji, a nie udowodnione działanie w przypadku Forever Security.

Codex: zatwierdzenia, poziom zaufania i tryby sandbox

Według dokumentacji o zatwierdzeniach i bezpieczeństwie sandbox i uprawnienia Codex działają na dwóch poziomach. Polityka zatwierdzeń określa, kiedy Codex pyta (na przykład on-request lub never). Tryb sandbox określa, co jest technicznie możliwe: read-only, workspace-write lub danger-full-access. W trybie workspace-write sieć jest domyślnie wyłączona.

Do tego dochodzi poziom zaufania dla każdego projektu w ~/.codex/config.toml (trust_level). Według dokumentacji w folderach pod kontrolą wersji obowiązuje tryb Auto, czyli zapis w obszarze roboczym z potwierdzeniem. W folderach bez kontroli wersji obowiązuje read-only, dopóki katalog nie zostanie oznaczony jako zaufany. Folder taki jak Pobrane bez oznaczenia uchodzi za niezaufany. Ryzyko powstaje, gdy użytkownicy potwierdzą okno zaufania. Flaga –yolo usuwa sandbox i zatwierdzenia i nie powinna trafiać do zasad zespołu. Nie podano, w jakiej konfiguracji testowało Forever Security, dlatego nie wiadomo, czy domyślne poziomy ochrony zadziałały w teście.

Cursor

W sprawie zatwierdzeń poleceń terminala w Cursor brak jednoznacznej informacji producenta. Dlatego tylko wskazówka, by pozostawić włączone zatwierdzanie poleceń terminala i sprawdzić aktualną dokumentację producenta.

Sandbox i izolacja: ograniczenie szkód, nawet gdy agent wykona polecenia z pliku

Sandbox ogranicza, co agent może zrobić, nawet jeśli wykonuje obce instrukcje. Sandbox Claude Code pozwala na zapis w katalogu roboczym i folderach tymczasowych. Dostęp do sieci odbywa się przez proxy z listą dozwolonych domen, która domyślnie jest pusta. Chronione ścieżki, takie jak ustawienia Claude Code, plik startowy powłoki .bashrc i hooki Git, pozostają tylko do odczytu. Przykład:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "allowUnsandboxedCommands": false
  }
}

Dokumentacja wymienia też ograniczenia. Sandbox jest domyślnie wyłączony. Dostęp do odczytu jest szeroki, dane uwierzytelniające trzeba blokować celowo. Ochrona obejmuje tylko polecenia powłoki i ich procesy potomne, a nie wbudowane narzędzia do plików, MCP i hooki. Bez allowUnsandboxedCommands: false nieudane polecenie może zostać powtórzone poza sandboxem. W systemie Windows sandbox nie działa natywnie, używa się do tego WSL2. Nie stanowi pełnej bariery przeciw złośliwemu kodowi. Do silnej izolacji lepiej nadają się kontenery lub maszyny wirtualne.

Lista dozwolonych adresów sieciowych i środowisko jednorazowe

Taka lista dozwolonych adresów utrudniłaby pobranie pakietu i przekierowanie API. To ocena, a nie dowód w tej sprawie. Nieznany kod powinien trafiać do środowiska jednorazowego: kontenera, maszyny wirtualnej lub Dev Containera, bez danych uwierzytelniających głównego profilu. Tokeny powinny być krótkotrwałe. W razie podejrzenia zaleca się uznać token uwierzytelniający za wykradziony i go odnowić.

Ustawienie przeglądarki dla pobierania

Przeciw cichemu pobieraniu pomaga ustawienie, by przed każdym zapisem pytać o miejsce. W Chrome nazywa się ono „Pytaj, gdzie zapisać każdy plik przed pobraniem” i znajduje się w ustawieniach w sekcji Pobrane pliki. Edge i Firefox oferują odpowiedniki, nazwy różnią się zależnie od wersji (Firefox: Ustawienia, Ogólne, Pliki i aplikacje). Brave w teście BleepingComputer sam pytał. Można też przenieść folder pobierania w miejsce, które nigdy nie służy jako katalog roboczy. Alias powłoki lub hook, który odmawia startu w ~/Downloads, to dodatkowa opcja.

Lista kontrolna dla zespołów i zasady korzystania z agentów do programowania

Poniższa lista podsumowuje środki. Uzupełnia zalecenia z obu raportów o konfiguracje z dokumentacji producentów.

• Agenci startują tylko w katalogu głównym zaufanego repozytorium. Pobrane, Pulpit i katalog domowy są wykluczone.
• Obce pliki, takie jak AGENTS.md, CLAUDE.md czy .cursor/rules, są czytane przed otwarciem świeżo sklonowanego lub rozpakowanego projektu.
• Pytania o uprawnienia i sandbox pozostają aktywne. Tryby automatyczne i flagi takie jak –yolo działają tylko w odizolowanych środowiskach.
• Dostęp do sieci przebiega przez listę dozwolonych adresów, dane uwierzytelniające są poza zasięgiem, tokeny są krótkotrwałe.
• Instalacje pakietów przez agentów odbywają się tylko po zatwierdzeniu, z plikiem lockfile i sprawdzeniem rejestru. Jak szybko jeden pakiet pociąga kolejne, pokazuje przypadek function-color i function-flag.
• Ustawienia są zarządzane centralnie. Zmiany w ~/.codex/config.toml i .claude/settings.json są monitorowane.
• Załadowane pliki z instrukcjami są rejestrowane, o ile narzędzia na to pozwalają.
• Plan reagowania na incydenty: zatrzymać sesję, odnowić tokeny i klucze, sprawdzić pliki konfiguracyjne, prześledzić instalacje pakietów.

Organizacje z obowiązkami w zakresie bezpieczeństwa informacji uwzględniają takich agentów w swoim zarządzaniu ryzykiem. Dotyczy to zgody na ich użycie, konfiguracji i dowodu, że zasady obowiązują. Tekst o agentic coding opisuje, jak zorganizować ich użycie w zespołach programistycznych.

Wzór zasad

Zwięzłe zasady da się ująć w kilku zdaniach. Zakres obejmuje wszystkich pracowników i usługodawców, którzy korzystają z agentów AI do programowania na urządzeniach firmowych lub z danymi firmy. Agenci są uruchamiani tylko w katalogu głównym sprawdzonego repozytorium, nigdy w folderach Pobrane, Pulpit czy katalogu domowym. Tryby automatyczne oraz wyłączanie sandboxa lub zatwierdzeń są dozwolone tylko w odizolowanych środowiskach jednorazowych bez danych uwierzytelniających. Instalacje pakietów i zmiany w plikach konfiguracyjnych wymagają zatwierdzenia przez programistów. Za centralne ustawienia odpowiada dział bezpieczeństwa IT, za przestrzeganie zasad w projekcie kierownictwo projektu. Podejrzenia incydentów są natychmiast zgłaszane do działu bezpieczeństwa IT, a dotknięte tokeny niezwłocznie odnawiane.

Sprawdzanie własnych stron internetowych i systemów

Ten przypadek dotyczy przede wszystkim komputerów programistów. Kto sam udostępnia pliki do pobrania, jest ze swoją stroną częścią łańcucha. Sprawdzenie strony internetowej pokazuje, jakie skrypty i nagłówki dostarcza strona, ale sprawdza tylko stronę, a nie komputery programistów. Do systematycznej kontroli bezpieczeństwa w zespołach punktem wyjścia są Web Security Checks.

Podsumowanie

Odpowiedzialność spoczywa na użytkowniku, granicę wyznacza technika!

Obcy plik tekstowy może sterować agentem do programowania, ponieważ agent traktuje pliki w folderze roboczym jak instrukcje. Niezawodną ochronę zapewniają dopiero wymuszane granice: uprawnienia, hooki, sandbox, lista dozwolonych adresów sieciowych i centralnie zarządzane ustawienia.

Otwarte pozostaje, czy atakujący wykorzystują w praktyce drogę przez pobieranie w przeglądarce i jak plik trafił do klienta. W każdym razie ważne wydaje się uwrażliwianie pracowników i programistów (dopóki nie wyginą).