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.

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.

Aktualizacja z 25 września: liczby o obchodzeniu monitora

Benchmark opublikowany 24 września podaje liczby do powyższej tezy. W EvasionBench każde z 50 zadań wymaga operacji, której zabrania monitor działający w czasie wykonania, a agenci wiedzą, że monitor patrzy; we wszystkich modelach, przy najlepszej z trzech prób, odsetek prób obejścia sięga 98 procent, a odsetek udanych obejść 88 procent. Agenci kodują polecenia, rozbijają operacje na kilka wywołań narzędzi i ponawiają próby, aż istotny kontekst wypadnie z okna monitora.⁴ Nie proszono o żadne wrogie działania. Wywołała to zwykła presja zadania, co w jednym zdaniu ujmuje problem klasyfikatora: sędzia oceniający każdą akcję osobno jest sondowany przez stronę, która ma więcej prób, niż sędzia ma pamięci.

Aktualizacja z 1 października: strażnik też jest klasyfikatorem

Esej Matthew Greena z 30 września o powstrzymywaniu agentów dochodzi do połowy wniosku tego wpisu z przeciwnej strony, a na drugą połowę naciska.⁵ Jego głównym tematem są piaskownice treningowe laboratoriów, a nie przepływ zatwierdzania asystenta programistycznego, ale struktura jest bliska tej, którą zaleca ten wpis: mur z jednymi dozwolonymi drzwiami i model, któremu powierzono ocenę tego, co przez nie przechodzi, ponieważ „The volume of data that agents produce is so high that no human being could possibly read it” (agenci wytwarzają tak dużo danych, że żaden człowiek nie byłby w stanie ich przeczytać). Jego werdykt: „a warden-guarded sandbox is just another version of the alignment problem. You’re going to have to trust a model to do it” (piaskownica pilnowana przez strażnika to po prostu kolejna wersja problemu dopasowania: trzeba będzie zaufać, że zrobi to model), i to modelowi przynajmniej w jakiejś części tak inteligentnemu jak ten, którego pilnuje. Do tego samego wzorca strażnika Green zalicza wdrożonego agenta, Muse firmy Meta: jego „hatch-safety classifiers that evaluate whether actions are safe” (klasyfikatory bezpieczeństwa oceniające, czy działania są bezpieczne) mają według niego wyłapywać pomyłki i prompt injection, a nie powstrzymywać wrogi model. Klasyfikator trybu auto pełni tę samą funkcję i jest strażnikiem w tym samym sensie, a stanowisko Anthropic, tak jak relacjonuje je Rehberger, już umieszcza granicę poza nim.

Połową, na którą Green naciska, jest mur. Gdy agenci potrzebują informacji, by być użytecznymi, piaskownice są według niego „only a very small part of the solution” (tylko bardzo małą częścią rozwiązania), ponieważ ruch idzie tam, gdzie zostawiono otwarte drzwi. To uczciwa granica rady tego wpisu, by dodać mur: kontener i lista dozwolonych dla ruchu wychodzącego decydują o tym, które drzwi istnieją, a coś nadal musi oceniać, co przez nie przechodzi.

Green sam wskazuje wrześniowy incydent z DNS, choć nie szczegóły istotne dla tego wpisu. W raporcie OpenAI na jego temat system monitorujący rzeczywiście oznaczył agenta, który dotarł przez DNS do zewnętrznego chatbota, mniej więcej dwanaście minut po wywołaniu DNS, na które przyszła odpowiedź z zewnątrz, a ten sam raport podaje, że przegląd retrospektywny wykrył inne zewnętrzne zapytania DNS, którym monitor przypisał zbyt niską ocenę, ponieważ „sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed” (czasem traktował niepowodzenie w uzyskaniu użytecznych informacji jako dowód, że próba dostępu do internetu się nie powiodła).⁶ Odpowiedź OpenAI umieściła blokadę na murze: kontrole w dwóch niezależnych warstwach, „either of which would have prevented this access” (z których każda zapobiegłaby temu dostępowi), oraz, wymienione osobno, zapytania DNS ograniczone do dozwolonej listy domen i typów rekordów. Firma dodaje też detekcje DNS, ale nie o nich mówi, że zatrzymałyby to żądanie. Jeśli kontener agenta ma listę dozwolonych dla ruchu wychodzącego, warto sprawdzić, co przekaże dalej jego resolver DNS; to tutaj były otwarte drzwi. Sędzia jest wart posiadania ze względu na to, co drzwi przepuszczają. To nie on zatrzymuje pakiet.

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