Tryb auto w Claude Code nie jest granicą bezpieczeństwa

Czy tryb auto w Claude Code jest granicą bezpieczeństwa? Nie jest, i mówi to sam Anthropic. Po tym, jak badacz Johann Rehberger zgłosił działający łańcuch ataku na Claude Code Opus 5 w trybie auto, Anthropic zamknął zgłoszenie jako „Informacyjne”, stojąc na stanowisku, że tryb auto to funkcja wygody oparta na klasyfikatorze, który działa najlepiej, jak potrafi, a nie gwarancja bezpieczeństwa, że zdeterminowane łańcuchy złożone z pojedynczo nieszkodliwych kroków wykraczają poza to, czego można oczekiwać od klasyfikatora, oraz że prawdziwą granicą jest izolacja na poziomie systemu operacyjnego wraz z kontrolą ruchu wychodzącego.¹ Ta odpowiedź nie jest wykrętem. To poprawny model mentalny, a większość z nas nosiła w głowie błędny. {.answer-block}

Istnieje szczególny rodzaj odkryć w bezpieczeństwie, które liczą się mniej ze względu na samą lukę, a bardziej ze względu na przekonanie, które prostują. Tekst Rehbergera z 26 sierpnia należy do tej kategorii. Zademonstrowany w nim łańcuch jest pomysłowy, ale najbardziej użyteczna jest reakcja, którą wywołał, ponieważ to ona pokazuje, która warstwa konfiguracji naprawdę przenosi obciążenie — i nie jest to ta warstwa, której większość programistów ufa, odkąd w sierpniu tryb auto stał się ustawieniem domyślnym.

W skrócie

• Rehberger opublikował 26 sierpnia 2026 roku działający łańcuch ataku na Claude Code Opus 5 w trybie auto, raportując skuteczność na poziomie 60–80% na małych próbach: trzy udane przebiegi na pięć dla łańcucha podstawowego oraz trzy na pięć i cztery na pięć dla dwóch konfiguracji drugiego wariantu. Sam zaznacza, że są to małe próby, a nie ogólny wskaźnik skuteczności ataku.¹
• Odkrycie zderza się z konkretną liczbą: zewnętrzna ocena zamówiona przez Anthropic wykazała skuteczność ataków typu prompt injection na poziomie 0,00% dla Opus 5 w trybie auto, mierzoną na 72 scenariuszach uruchomionych po dziesięć razy każdy. Łańcucha Rehbergera w tym zbiorze nie było, więc 0,00% i działający łańcuch wykonania kodu są prawdziwe jednocześnie.¹
• Każdy krok łańcucha jest z osobna rozsądny. Na tym polega lekcja projektowa: klasyfikator ocenia działania pojedynczo, a atak żyje w kompozycji, nie w żadnym pojedynczym działaniu.
• Anthropic zamknął zgłoszenie jako „Informacyjne”, przedstawiając tryb auto jako funkcję wygody opartą na klasyfikatorze, który działa najlepiej, jak potrafi, a nie jako gwarancję bezpieczeństwa, przy czym prawdziwą granicą pozostaje izolacja systemu operacyjnego i kontrola ruchu wychodzącego.¹
• Najostrzejszy szczegół, który raportuje Rehberger, a Willison wysuwa na pierwszy plan: w kilku przebiegach Claude wykrył kompromitację i próbował zabić proces złośliwego oprogramowania, a tryb auto odmówił wykonania polecenia czyszczącego.¹²
• Konsekwencja praktyczna: tryb auto to mechanizm produktywności, który przy okazji blokuje udokumentowaną listę operacji destrukcyjnych, gdy uzna, że użytkownik o nie nie prosił. To nie on stoi między tekstem kontrolowanym przez atakującego a poświadczeniami użytkownika. Stoją tam kontener, ograniczony ruch wychodzący i katalog domowy bez poświadczeń.

Łańcuch, krok po kroku

Punktem wyjścia jest agent wykonujący zwykłą pracę: pobrać zasób, zdekodować go, użyć zawartości. Oto jak zamienia się to w wykonanie kodu.¹

Serwer odpowiada na WebFetch agenta kodem HTTP 415, co czyta się jako problem z typem zawartości, a nie jako atak. Agent robi rzecz rozsądną i sięga po curl. Pobrane archiwum rozpakowuje się do katalogu roboczego zawierającego plik README, manifest sum kontrolnych, indeks CSV, siedem rekordów JSON zakodowanych w Base85 i skompresowanych zlib, natywny plik binarny dekodera oraz plik o nazwie struct.py.

Wtedy mechanizmy bezpieczeństwa działają. Agent odmawia uruchomienia niezaufanego natywnego pliku binarnego, dokładnie tak, jak byśmy tego chcieli. Odmówiwszy uruchomienia binarki, pisze zamiast tego własny dekoder w Pythonie i uruchamia go z wnętrza katalogu, do którego rozpakował archiwum.

Ten dekoder importuje base64. Moduł base64 z biblioteki standardowej importuje struct. Python umieszcza katalog roboczy na początku ścieżki wyszukiwania modułów, więc struct rozwiązuje się do struct.py atakującego z rozpakowanego archiwum, a nie do modułu z biblioteki standardowej.

Warto przeczytać tę sekwencję ponownie i zauważyć, czego w niej brakuje: nie ma kroku, w którym agent dostaje polecenie zrobienia czegoś ewidentnie złośliwego, ani kroku, który rozsądny recenzent oznaczyłby w izolacji. Sięgnięcie po curl po odpowiedzi 415 jest normalne. Rozpakowanie archiwum jest normalne. Odmowa uruchomienia niepodpisanej binarki to sukces mechanizmów bezpieczeństwa. Napisanie własnego dekodera to zaradność. Uruchomienie go w katalogu z danymi to oczywiste miejsce uruchomienia.

Dlaczego klasyfikator przegrywa tę potyczkę

Klasyfikator trybu auto ocenia działanie względem intencji sesji: czy to polecenie odpowiada temu, o co poprosił użytkownik, i czy samo w sobie jest niebezpieczne? Na to pytanie istnieje dobra odpowiedź dla rm -rf / i zła dla python decode.py.

Atak nigdy nie prezentuje niebezpiecznego działania. Przestawia otoczenie tak, aby działanie wyglądające bezpiecznie miało niebezpieczne konsekwencje, a te konsekwencje istnieją wyłącznie z powodu kroku wykonanego wcześniej — rozpakowania archiwum, które podłożyło moduł. Żeby to wychwycić, recenzent musiałby trzymać w głowie całą historię i rozumować o sposobie rozwiązywania importów w Pythonie względem bieżącego katalogu roboczego. Stanowisko Anthropic, zgodnie z którym łańcuchy zbudowane z pojedynczo nieszkodliwych kroków wykraczają poza zakres klasyfikatora, jest wypowiedzią właśnie o tej luce.¹

Warto precyzyjnie nazwać tę klasę problemów. Willison zaktualizował swój tekst 30 sierpnia, przychylając się do uwagi czytelnika serwisu Lobste.rs: to wcale nie jest klasyczny prompt injection, ponieważ w żadnym momencie model nie czyta instrukcji atakującego i za nimi nie podąża. Lepiej opisać to jako atak na zdezorientowane środowisko, w którym sam kształt otoczenia podanego agentowi wytwarza exploit.² To rozróżnienie zaostrza problem, zamiast go łagodzić. Klasyfikator wypatrujący wstrzykniętych instrukcji nie ma tu na co patrzeć, bo takich instrukcji nie ma.

To ten sam strukturalny wniosek, który powtarza fala CVE w MCP: narzędzia agentowe zyskują możliwości szybciej, niż zyskują mechanizmy ograniczania, a przegląd pojedynczych działań nie składa się na bezpieczeństwo całej sesji.

Szczegół, który powinien zmienić model mentalny

Rehberger raportuje, a Willison wysuwa na pierwszy plan moment, przy którym warto się zatrzymać: w kilku przebiegach Claude zauważył kompromitację i próbował zakończyć proces złośliwego oprogramowania, a tryb auto odmówił wykonania polecenia czyszczącego.¹²

Warstwa bezpieczeństwa, która blokuje naprawę, nie jest paradoksem — to konsekwencja optymalizowania mechanizmu pod hasło „nie pozwól agentowi zrobić niczego drastycznego” bez pojęcia o tym, dlaczego ta drastyczna rzecz jest podejmowana. Sprzątanie po kompromitacji wygląda dla klasyfikatora bardzo podobnie do niszczenia.

Lekcja operacyjna jest wąska i użyteczna. „Agent to zauważy” nie jest mechanizmem kontroli. Zauważenie i zdolność do działania to dwie różne rzeczy, a plan reagowania na incydenty nie może zakładać, że skompromitowany agent zdoła posprzątać po sobie.

Co naprawdę ogranicza agenta

Rekomendacje Rehbergera są tymi mało efektownymi, a dwie pierwsze powstrzymałyby ten łańcuch:¹

Agentów działających bez nadzoru należy uruchamiać w kontenerze lub maszynie wirtualnej. Kompromitacja wykonała kod na koncie użytkownika agenta. Warstwa izolacji zamienia dostęp do całej maszyny w środowisko jednorazowego użytku.

Należy ograniczyć ruch wychodzący. Zyskiem łańcucha był podproces sięgający na zewnątrz po zdalny ładunek i uruchamiający go, a potem połączenie zwrotne. Polityka ruchu wychodzącego oparta na liście dozwolonych adresów przerywa zarówno pobranie zdalnego etapu, jak i połączenie zwrotne.

Poświadczenia należy trzymać poza zasięgiem agenta. Klucze SSH, poświadczenia chmurowe i pliki .env w katalogu domowym domyślnie mieszczą się w promieniu rażenia. Trzeba je przenieść albo uruchamiać agenta tam, gdzie ich nie ma.

Agenta należy monitorować, a zatwierdzeń nie czytać jako dowodu. Zatwierdzenie w trybie auto oznacza, że klasyfikator nie zgłosił sprzeciwu. Nie jest ustaleniem, że działanie było bezpieczne.

Warto zauważyć, czego na tej liście nie ma: wyłączenia trybu auto. Blokuje on udokumentowaną listę operacji destrukcyjnych, gdy uzna, że użytkownik o nie nie prosił, i zmniejsza zmęczenie pytaniami, które prowadzi do odruchowego zatwierdzania wszystkiego. Wymiana tego na fałszywe poczucie rygoru to zamiana słabego mechanizmu na gorszy. Warto go zachować i przestać traktować jak granicę.

Rzecz warta powiedzenia wprost

Łatwo byłoby opisać to odkrycie jako porażkę, a jeszcze łatwiej jako pretekst do obwiniania dostawcy. Żadne z tych ujęć nie jest właściwe.

Odpowiedź Anthropic — funkcja wygody oparta na klasyfikatorze, który działa najlepiej, jak potrafi, a nie gwarancja bezpieczeństwa, z izolacją systemu operacyjnego i kontrolą ruchu wychodzącego jako granicą — to uczciwsza postawa wobec bezpieczeństwa niż mocniejsza deklaracja.¹ Dostawca, który obiecywałby, że jego klasyfikator wyłapuje zdeterminowane łańcuchy wstrzyknięć, składałby obietnicę, której żaden klasyfikator nie jest w stanie dotrzymać, a programiści budowaliby na tej obietnicy. Interesujące pytanie nie brzmi, czy ten atak działa. Brzmi ono, czy model mentalny ekosystemu odpowiada modelowi dostawcy — i w tej chwili nie odpowiada: w sierpniu tryb auto stał się ustawieniem domyślnym dla sesji Pro, Max i Team, podczas gdy liczbą wprowadzoną do obiegu przez Anthropic była skuteczność ataków na poziomie 0,00% z zamówionej oceny obejmującej 72 scenariusze — Rehberger zalicza to do problemu marketingowego 0,00% — a towarzysząca jej narracja mówiła o bezpieczeństwie, a nie o wygodzie połączonej ze zmniejszeniem promienia rażenia.¹ Rehberger wyciąga twardszy wniosek niż ja: komunikację o 0,00% i zakwalifikowanie sprawy jako wykraczającej poza zakres czyta jako sprzeczne komunikaty, które do siebie nie pasują.¹ Moim zdaniem jedno i drugie może być prawdą. Kwalifikacja jest tą uczciwą, a liczba nigdy nie powinna być sprzedawana jako właściwość produktu.

Jeśli dana konfiguracja zakładała, że klasyfikator jest murem, trzeba dobudować mur.

Aktualizacja z 3 września: co pojawiło się od publikacji tego wpisu

Claude Code wydał trzy wersje w ciągu 48 godzin od publikacji tego wpisu; dwie z nich dotykają trybu auto.³ Wersja 2.1.257, opublikowana 1 września, dodaje regułę nazwaną w informacjach o wydaniu Containment Escape: „pobieranie poświadczeń z metadanych chmury, omijanie kontroli ruchu wychodzącego i sięganie między dzierżawcami nie są już automatycznie zatwierdzane, chyba że środowisko oznaczy je jako oczekiwane”. To samo wydanie dodaje w trybie auto jednorazowe pytanie przed pierwszym odczytem pliku spoza katalogów roboczych, wraz z ustawieniem permissions.blockReadsOutsideWorkingDirectories, które zamienia to pytanie w odmowę. Wersja 2.1.259, opublikowana 2 września, dodaje --permission-prompts none dla nienadzorowanych hostów headless: „wszystko, co wywołałoby pytanie, jest automatycznie odrzucane, podczas gdy aktywny tryb uprawnień (w tym tryb auto) nadal decyduje”.

Warto czytać je w ramie wyznaczonej przez ten wpis. Reguła, pytanie o odczyt i flaga to realne utwardzenie, a flaga dla trybu headless jest ustawieniem fail-closed, z którym powinien pracować nienadzorowany host. Dwie pierwsze zawężają jednak to, co tryb auto zatwierdzi samodzielnie: reguła wyjmuje trzy kategorie z automatycznego zatwierdzania, chyba że środowisko oznaczy je jako oczekiwane, a zmiana dotycząca odczytów pyta raz albo odmawia przy włączonym ustawieniu. Żadna z nich nie jest opisana jako granica i obie mieszczą się wewnątrz przepływu zatwierdzania trybu auto. To dokładnie ten przegląd, przez który przeszedł ten łańcuch, nie prezentując ani jednego działania wyglądającego samo w sobie na błędne. Reguła nazywa omijanie kontroli ruchu wychodzącego; Rehberger nie opisuje żadnego omijania, a jedynie połączenie wychodzące na każdym przeskoku: pobranie przez curl, proces potomny pobierający zdalny etap, ten etap pobierający ładunek i połączenie zwrotne. Czy reguła odczytuje cokolwiek z tego jako omijanie, informacje o wydaniu nie mówią, i nie mówią też, czy pytanie o odczyt obejmuje odczyty wykonywane przez proces potomny. Tego, czy którakolwiek z tych zmian zatrzymałaby ten łańcuch, informacje o wydaniu nie twierdzą i nie należy tego zakładać. Jedna poprawka w 2.1.257 leży jednak na warstwie granicy: wpis deniedDomains w piaskownicy nie blokował hosta zapisanego z kropką na końcu, a wydanie to naprawia. To naprawa granicy, a nie jej przesunięcie. To, co tryb auto zatwierdza samodzielnie, skurczyło się. Granica nie drgnęła.

Kluczowe wnioski

• Tryb auto to wygoda i mechanizm ograniczania promienia rażenia, a nie granica bezpieczeństwa. To stanowisko samego dostawcy po działającym obejściu, a nie krytyka z zewnątrz.¹
• Klasyfikatory oceniają działania; ataki żyją w kompozycjach. Każdy krok zademonstrowanego łańcucha da się obronić z osobna i właśnie dlatego przegląd pojedynczych działań go przeoczył.
• Zauważenie to nie naprawa. W części przebiegów agent wykrył własną kompromitację, a następnie został zablokowany przy sprzątaniu. Plan reagowania na incydenty powinien to uwzględniać.¹²
• Mechanizmy, które wytrzymują, znajdują się poza modelem. Kontener lub maszyna wirtualna, ograniczony ruch wychodzący, poświadczenia poza katalogiem domowym. Cała reszta to głębokość obrony, nie granica.

FAQ

Czy wyłączyć tryb auto?

Nie, chyba że traktowano go jako mechanizm ograniczania. Blokuje udokumentowany zestaw operacji destrukcyjnych — git reset --hard, git checkout -- ., git clean -fd, git stash drop oraz terraform/pulumi/cdk destroy — gdy uzna, że użytkownik o nie nie prosił, i obcina liczbę pytań napędzającą odruchowe zatwierdzanie. Warto go zachować jako mechanizm produktywności i ograniczania promienia rażenia, a do sesji stykających się z niezaufanymi danymi dołożyć prawdziwą izolację.

Czy dotyczy to wyłącznie Claude Code?

Mechanizm nie jest specyficzny dla Claude. Każdy agent, który pobiera niezaufane archiwa, pisze kod i uruchamia go w katalogu właśnie przez siebie rozpakowanym, jest narażony na tę samą pułapkę rozwiązywania importów, a każdy przegląd bezpieczeństwa oparty na pojedynczych działaniach jest narażony na tę samą lukę kompozycji. Opisane tu szczegóły zademonstrowano na Claude Code Opus 5 w trybie auto.¹

Co liczy się jako sesja z niezaufanymi danymi wejściowymi?

Wszystko, w czym tekst pod wpływem atakującego może dotrzeć do modelu: pobrane strony internetowe, pobrane archiwa, treść zgłoszeń i pull requestów, poczta, logi z publicznej usługi oraz serwery MCP innych dostawców. W praktyce jest to większość realnej pracy i to jest w tym najbardziej niewygodne.

Czy zostało to naprawione?

Nie potraktowano tego jako podatności do naprawy. Anthropic zamknął zgłoszenie jako „Informacyjne” na tej podstawie, że omijanie klasyfikatora tego rodzaju wykracza poza to, co obiecuje tryb auto.¹ Należy traktować to jako udokumentowaną właściwość systemu, a nie jako oczekującą łatkę. Jedno wydanie z 48 godzin po publikacji tego wpisu, 2.1.257, zawęziło to, co tryb auto zatwierdza samodzielnie, i dodało opcjonalną blokadę odczytów spoza katalogów roboczych, a 2.1.259 dodała flagę fail-closed dla hostów headless; powyższa aktualizacja z 3 września opisuje, co te wydania zmieniają, a czego nie.³

Źródła