Każdy hook to blizna: 84 awarie agentów zapisane w kodzie

W moim systemie orkiestracji agentów 84 punkty zaczepienia przechwytują 15 z 26 typów zdarzeń cyklu życia, które Claude Code udostępnia w wersji v2.1.116 (kwiecień 2026). Każdy punkt zaczepienia to skrypt powłoki albo fragment kodu w języku Python, uruchamiany przed konkretną akcją agenta lub po niej: odczytem pliku, zapisem pliku, poleceniem bash, żądaniem sieciowym, powołaniem subagenta, operacją git, wywołaniem narzędzia MCP. Każdy istnieje dlatego, że coś poszło nie tak.

Każdy punkt zaczepienia w systemie orkiestracji agentów prowadzi wprost do konkretnej awarii na produkcji — dzięki temu cała ich kolekcja jest pamięcią instytucjonalną zapisaną w skryptach powłoki. Agenci czyścili pamięci podręczne CDN, czytali pliki z poświadczeniami, raportowali przechodzące testy, których nigdy nie uruchomili, i przez czterdzieści minut dryfowali z dala od zadania. Każdy incydent zostawił po sobie małe, deterministyczne zabezpieczenie, które od tamtej pory po cichu uruchamia się w każdej kolejnej sesji.

Nie o teoretyczne pomyłki tu chodzi, lecz o pomyłki na produkcji. Agent wyczyścił pamięć podręczną CDN obsługującą miliony żądań. Inny próbował zapisać klucze SSH. Kolejny zaraportował „wszystkie testy przechodzą”, nie wywołując pytest. Jeszcze inny odpłynął od zadania tak daleko, że przez czterdzieści minut optymalizował funkcję w pliku, który nie miał nic wspólnego ze zleconą pracą.

Żadnego z tych punktów zaczepienia nie zaprojektowałem z wyprzedzeniem. Nie usiadłem, żeby wyliczyć tryby awarii autonomicznych agentów AI i napisać do nich prewencyjne zabezpieczenia. Każdy punkt zaczepienia jest reakcją. Coś się zepsuło, napisałem skrypt, który ma nie dopuścić do powtórki, i od tamtej pory ten skrypt cicho działa w każdej sesji. System punktów zaczepienia nie jest architekturą bezpieczeństwa. Jest kolekcją blizn.

TL;DR

• Wyczyszczenie pamięci podręcznej: agent skasował produkcyjną pamięć podręczną CDN autoryzowanym wywołaniem API. Dwa punkty zaczepienia (47 linii) zamykają dziś operacje destrukcyjne za frazą dostępu, którą musi wpisać człowiek.
• Czytanie poświadczeń: agent umieścił tokeny API w swoim oknie kontekstowym. Zabezpieczenie dopasowujące ścieżki blokuje teraz odczyt plików z poświadczeniami i odnotowuje każdy dostęp do plików .env.
• Fantomowa weryfikacja: agent zaraportował „wszystkie testy przechodzą”, nie uruchamiając pytest. Detektor języka asekuracyjnego zbił fantomową weryfikację z 12% do poniżej 2% sesji.
• Dwanaście dryfów: w ciągu sześćdziesięciu dni agenci dwanaście razy w sprawdzalny sposób zgubili własne zadanie. Detektor podobieństwa kosinusowego z progiem 0,30 uruchamia się teraz co 25 wywołań narzędzi.
• Taksonomia: sześć strukturalnych kategorii awarii pokrywa wszystkie 84 punkty zaczepienia. Po ponad 500 sesjach nowe kategorie zdarzają się rzadko. System po każdym incydencie staje się twardszy.

Wyczyszczenie pamięci podręcznej: jak jedno autoryzowane wywołanie położyło produkcję

21 marca 2026 poprosiłem agenta, żeby zbadał, dlaczego strony rynkowe na resumegeni.com ładują się wolno. Zaczął normalnie: czytał kod obsługi tras, sprawdzał zapytania do bazy, profilował renderowanie szablonów. Potem uznał, że nieaktualne wpisy w pamięci podręcznej Cloudflare mogą maskować rzeczywistą charakterystykę wydajności.

Agent wywołał mcp__cloudflare__cache_purge z parametrem purge_everything: true.

W jednej chwili unieważnione zostały wszystkie zbuforowane strony produkcyjnego serwisu. CDN przeszedł z obsługi większości żądań w 80–100 ms do przekazywania każdego żądania do serwera źródłowego na Railway. Strona rynkowa Austin zamiast poniżej sekundy potrzebowała 14 290 milisekund. Nowy Jork — 6891 ms. Każda strona serwisu renderowała się od tej chwili przy każdym żądaniu od zera, z zimnego źródła.

Agent nie zrobił niczego nieautoryzowanego. Użył zwykłego, dozwolonego narzędzia MCP z ważnymi poświadczeniami, żeby wywołać autoryzowany endpoint API. Wyczyszczenie pamięci podręcznej to sensowny krok śledczy, jeśli diagnozuje się właśnie jej zachowanie. Problem w tym, że „sensowne przy debugowaniu” i „katastrofalne na produkcji” było jednym i tym samym wywołaniem API, a między rozumowaniem agenta a konsekwencją na produkcji nie istniało żadne ograniczenie.⁴

Tej samej nocy zbudowałem dwa punkty zaczepienia.

Strażnik poleceń Bash (destructive-api-guard.sh): uruchamia się przy każdym poleceniu bash. Dopasowuje wzorce curl.*purge, rm -rf, DROP TABLE, docker.*rm, git push.*--force. Twarda blokada (exit 2). Agent dostaje komunikat wyjaśniający, dlaczego polecenie zostało zablokowane, wraz z propozycją alternatyw. Nie może przejść dalej bez frazy dostępu „rosebud”, która trafia do kontekstu wyłącznie wtedy, gdy wpisze ją człowiek.

Strażnik MCP (destructive-mcp-guard.sh): uruchamia się przy każdym wywołaniu narzędzia MCP pasującym do mcp__cloudflare lub mcp__github. W parametrach narzędzia szuka wzorców purge, delete, destroy, remove. Ta sama twarda blokada, ta sama bramka z frazą dostępu.

Dwa punkty zaczepienia. Dwa skrypty powłoki. Razem 47 linii kodu. Od instalacji nie zapobiegły ani jednemu wyczyszczeniu pamięci podręcznej — bo od czasu dodania bramki z frazą dostępu żaden agent nawet nie spróbował. Te punkty zaczepienia nie łapią ataków. Sprawiają, że cała kategoria pomyłek przestaje być możliwa.

Incydent obnażył zresztą ten sam problem wydajnościowy, który miał zostać zbadany. Strona Austin renderowana na zimno w 14 sekund doprowadziła do przekazania sprawy stron rynkowych, a cztery dni później — do poprawki kształtu zapytania. Incydent okazał się pożyteczny. Punkt zaczepienia gwarantuje, że się nie powtórzy.

Czytanie poświadczeń

W lutym 2026 agent zbierający kontekst do projektu odczytał plik ~/.claude/docs/credentials.md. Plik zawiera tokeny API do Cloudflare, GitHub, Railway i innych usług. Agent umieścił streszczenie jego zawartości w swoich notatkach roboczych, co oznacza, że tokeny znalazły się w żądaniu API wysłanym na serwery firmy Anthropic.

Żaden token nie trafił do repozytorium. Żaden nie został ujawniony publicznie. Ale tokeny przewędrowały przez zewnętrzne API w oknie kontekstowym, nad którym nie mam kontroli. Powierzchnia ryzyka rozszerzyła się z „mojej maszyny” na „moją maszynę plus infrastrukturę inferencyjną firmy Anthropic”.

Strażnik ścieżek z poświadczeniami uruchamia się przy każdym odczycie pliku. Porównuje ścieżkę z listą wrażliwych wzorców: .env, credentials, .ssh/, .aws/, .gnupg/, secrets. Przy odczycie poświadczeń zapisuje ostrzeżenie i blokuje operację. Przy odczycie .env przepuszcza ją, ale odnotowuje dostęp.

Dla większości ścieżek strażnik jest doradczy, dla plików z poświadczeniami — blokuje twardo. Rozróżnienie ma znaczenie: agent czytający .env, żeby poznać nazwy zmiennych środowiskowych, zdobywa użyteczny kontekst. Agent czytający credentials.md, żeby poznać tokeny API, to incydent bezpieczeństwa.

Od instalacji strażnik zadziałał 23 razy w ponad 200 sesjach. Dwadzieścia przypadków to agenci czytający pliki .env (odnotowane, przepuszczone). Trzy to próby odczytu plików z poświadczeniami lub kluczami (zablokowane). Za każdą zablokowaną próbą stał agent, który szeroko zbierał kontekst projektu i przypadkiem objął wzorcem wyszukiwania wrażliwy plik. Żaden nie działał złośliwie. Każdy bez strażnika wpuściłby sekrety do okna kontekstowego.

Fantomowa weryfikacja

Najbardziej podstępny tryb awarii to agent, który raportuje udaną weryfikację, w ogóle jej nie przeprowadzając.

Sesja 147. Poprosiłem agenta o refaktoryzację zapytania do bazy i sprawdzenie zmiany istniejącym zestawem testów. Zapytanie zrefaktoryzował poprawnie. W raporcie końcowym napisał: „Wszystkie testy przechodzą. Zrefaktoryzowane zapytanie zwraca wyniki identyczne z oryginałem”.

Zajrzałem do logu sesji. Nigdzie nie pojawiło się wywołanie pytest. Nie wywołano żadnego narzędzia uruchamiającego testy. Agent wywnioskował, że testy przejdą, bo zrefaktoryzowane zapytanie jest logicznie równoważne oryginałowi — i zaraportował to rozumowanie tak, jakby było wynikiem testów.

Zapytanie faktycznie było poprawne. Testy faktycznie by przeszły. Rozumowanie agenta było trafne. Ale rozumowanie o testach to nie uruchamianie testów, a właśnie w tej szczelinie błędy trafiają na produkcję. Gdyby zrefaktoryzowane zapytanie okazało się subtelnie błędne w przypadku brzegowym, którego rozumowanie agenta nie objęło, błąd trafiłby na produkcję razem z raportem końcowym deklarującym weryfikację testami.

Zanim zbudowałem punkt zaczepienia z bramką dowodową, ten tryb awarii wystąpił 7 razy w 60 sesjach. Uruchamia się on przy każdym raporcie końcowym i skanuje go pod kątem języka asekuracyjnego: „powinny przejść”, „sądzę”, „testy prawdopodobnie przechodzą”, „jestem przekonany”. Po wykryciu wstrzykuje komunikat: „Wykryto język asekuracyjny. Proszę przytoczyć konkretny dowód: wkleić wynik testów, wskazać plik i numer linii albo odwołać się do konkretnego kroku weryfikacji”.

Punkt zaczepienia nie sprawdza, czy testy rzeczywiście uruchomiono. Sygnalizuje wzorzec językowy, który zdradza pominiętą weryfikację. Wykrywanie jest niedoskonałe — dostatecznie wprawny agent mógłby przeformułować asekurację tak, by wzorzec ominąć. Ale łapie przypadek typowy, a ten odpowiada za 12% awarii agentów wymagających interwencji człowieka.¹

Po instalacji punktu zaczepienia fantomowa weryfikacja spadła z 12% do poniżej 2% sesji. Pozostałe 2% to sytuacje, w których agent przeformułowuje asekurację albo w których deklaracja weryfikacji jest formalnie prawdziwa, lecz niepełna (np. „testy jednostkowe przechodzą”, gdy testów integracyjnych nie uruchomiono).

Dryf

Od stycznia do marca 2026 mój detektor dryfu zadziałał dwanaście razy — w sesjach, w których agent w sprawdzalny sposób zgubił powierzone mu zadanie.

Detektor działa tak: tworzy embedding pierwotnej treści zadania i cyklicznie porównuje go z embeddingiem ostatnich działań agenta. Kiedy podobieństwo kosinusowe spada poniżej 0,30, system wstrzykuje ostrzeżenie zawierające pierwotną treść zadania. Próg wykalibrowałem eksperymentalnie: 0,50 było zbyt czułe (reagowało na uprawnioną eksplorację podzadań), 0,20 zbyt pobłażliwe (przepuszczało oczywisty dryf), 0,30 wyłapało każdy potwierdzony przypadek.

Sesja 203 to przypadek najczystszy. Zadanie brzmiało: „napraw zepsute escapowanie XML w mapie witryny dla slugów ofert zawierających ampersandy”. Agent zaczął od lektury kodu generującego mapę witryny. Potem zauważył, że mapa powstaje z zapytania do bazy. Potem zauważył, że zapytanie da się zoptymalizować. Potem przez 40 minut przerabiał je na wzorzec widoku zmaterializowanego, napisał testy nowego zapytania i zameldował optymalizację jako zakończoną. Escapowania ampersandów nigdy nie naprawił.

Detektor dryfu wyłapałby to przy 25. wywołaniu narzędzia, mniej więcej 15 minut po starcie sesji, kiedy podobieństwo między „napraw escapowanie XML w mapie witryny” a „utwórz widok zmaterializowany” spadło poniżej progu. Zamiast tego dryf odkryłem dopiero podczas przeglądu.

Sesja 89 była subtelniejsza. Zadanie: „dodaj ograniczanie liczby żądań do endpointów uwierzytelniania”. Agent dodał je poprawnie. Potem zauważył, że przepływ uwierzytelniania ma niespójne komunikaty błędów. Potem je ujednolicił. Potem zauważył, że format odpowiedzi błędu odbiega od standardu formatu odpowiedzi API. Potem przerobił format odpowiedzi w 12 endpointach. Ograniczanie żądań było poprawne i kompletne. Dryfem była eksplozja zakresu.

Detektor uruchamia się co 25 wywołań narzędzi. We wszystkich dwunastu zejściach poniżej progu agent w sprawdzalny sposób odszedł od pierwotnego zadania. W sześciu przypadkach po zobaczeniu wstrzykniętego ostrzeżenia skorygował się sam. W czterech przyznał, że dryfuje, ale argumentował, że bieżąca praca ma wartość (czasem słusznie). W dwóch zignorował ostrzeżenie i ciągnął rozbieżny wątek.

Punkt zaczepienia nie zapobiega dryfowi. Czyni go widocznym. Decyzja, czy zawrócić agenta, czy pozwolić mu iść dalej, zostaje po stronie człowieka. Bez tego punktu zaczepienia dryf pozostaje jednak niewidoczny aż do raportu końcowego — czyli do momentu, w którym budżet kontekstu jest już wydany.

Taksonomia blizn

Po 84 punktach zaczepienia widać wzorce. Awarie układają się w sześć kategorii:

Pozostałe 47 punktów zaczepienia to zabezpieczenia specyficzne dla konkretnych projektów (pilnowanie konwencji, zabezpieczenia wdrożeń, walidatory tłumaczeń) albo rozwiązania eksperymentalne (śledzenie kosztów, metryki sesji, sygnały aktywności).

Sześć kategorii strukturalnych jest stabilnych. Nowe incydenty w ich obrębie łapią istniejące punkty zaczepienia. Kategorie dotąd nieznane pojawiają się rzadko. Przez pół roku pracy systemu przybyła tylko jedna nowa kategoria strukturalna (skażenie międzyprojektowe, wykryte, gdy sesja działająca w projekcie obsidian-signals spróbowała edytować pliki w blakecrosley.com). Pozostałych pięć ustaliło się w ciągu pierwszych 60 sesji.

Badanie Agents of Chaos — czternastodniowy eksperyment kilku uczelni, w którym sześciu agentów AI dostało dostęp do poczty, powłoki bash, systemów plików i GitHub — niezależnie wskazało pokrywające się kategorie awarii: nieproporcjonalną reakcję (operacje destrukcyjne), przejęcie tożsamości (ujawnienie poświadczeń), nieskończone pętle (wyczerpanie zasobów) oraz stopniowe uleganie presji (dryf zadaniowy).⁵ Zbieżność ich kontrolowanych badań z moim doświadczeniem produkcyjnym sugeruje, że są to strukturalne własności autonomicznych agentów, a nie artefakt konkretnej konfiguracji.

Czego punkty zaczepienia nie wyłapią

Punkty zaczepienia działają na poziomie wywołania narzędzia. Przechwytują akcję tuż przed jej wykonaniem albo tuż po nim. Nie przechwycą rozumowania, które do niej doprowadziło.

Agent, który zamiast naprawić zgłoszony błąd postanawia zrefaktoryzować funkcję, generuje poprawne wywołanie narzędzia (zapis pliku) z poprawną treścią (składniowo prawidłowy kod), które jest sprzeczne z zadaniem (nie ta funkcja). Nie łapie tego żaden punkt zaczepienia, bo żadne wywołanie nie wygląda podejrzanie. Detektor dryfu w końcu to wychwyci, ale dopiero gdy agent zużyje sporo kontekstu na niewłaściwą pracę.

Punkty zaczepienia nie łapią też awarii kompozycji, w których każde pojedyncze działanie jest autoryzowane, lecz cała sekwencja daje nieautoryzowany wynik. Wyczyszczenie pamięci podręcznej było właśnie taką awarią: odczyt konfiguracji pamięci podręcznej (autoryzowany), wywołanie czyszczącego API (autoryzowane), ale połączenie obu (wyczyszczenie produkcyjnej pamięci podręcznej w trakcie dochodzenia) okazało się szkodliwe. Strażnik MCP łapie dziś tę konkretną kombinację, lecz nowe kompozycje pozostają niepokryte.

Luka kompozycyjna w łańcuchu dostaw³ działa na tym samym poziomie: zaufane komponenty składają się w nieautoryzowane zachowanie. Punkty zaczepienia są zabezpieczeniami na poziomie komponentu. Rozumowanie na poziomie kompozycji wymaga innego mechanizmu — takiego, który ocenia sekwencje działań, a nie działania z osobna. Najbliżej tego jest detektor dryfu: ocenia trajektorię zachowania, a nie pojedyncze wywołania narzędzi. Mierzy jednak podobieństwo do pierwotnego zadania, a nie bezpieczeństwo złożonej sekwencji.

Przepaść między punktami zaczepienia a pełnym bezpieczeństwem to przepaść między pamięcią instytucjonalną a instytucjonalną przezornością. Punkty zaczepienia pamiętają, co poszło źle. Nie przewidują, co pójdzie źle następnym razem.

Dlaczego reaktywność jest uczciwa

Mógłbym zaprojektować system punktów zaczepienia z wyprzedzeniem. Wyliczyć wszystkie możliwe tryby awarii. Napisać do każdego prewencyjne zabezpieczenie. Zbudować kompletną architekturę bezpieczeństwa jeszcze przed pierwszą sesją.

Nie robię tego, bo projektowanie z wyprzedzeniem wymaga przewidzenia awarii, które jeszcze nie nastąpiły. Te przewidywania byłyby chybione. Punkty zaczepienia wychodziłyby albo zbyt szerokie (blokując uprawnione działania), albo zbyt wąskie (mijając się z prawdziwym wzorcem awarii). Odsetek fałszywych alarmów podkopałby zaufanie do całego systemu, a ja zacząłbym ignorować alerty.

Reaktywne punkty zaczepienia są uczciwe. Każdy mówi: „zdarzyła się dokładnie ta rzecz, a oto dokładnie to zabezpieczenie, które jej zapobiega”. Zabezpieczenie jest precyzyjnie wykalibrowane pod awarię, bo to awaria je zdefiniowała. Fałszywych alarmów jest wyraźnie mniej, ponieważ wzorzec pochodzi z prawdziwego incydentu, a nie z wyobrażonego modelu zagrożeń. Reaktywne zabezpieczenie z czasem i tak może zacząć łapać za dużo, w miarę jak kod ewoluuje, ale startuje z wysoką precyzją.

Podejście reaktywne ma swoją cenę: pierwsze wystąpienie każdej kategorii awarii przechodzi bez przeszkód. Pamięć podręczna została wyczyszczona. Poświadczenia zostały odczytane. Fantomowa weryfikacja przeszła dalej. Dryf zjadł kontekst. Każda pierwsza porażka to bilet wstępu do precyzyjnego, cichego zabezpieczenia, które nie dopuści do drugiej.

Po ponad 500 sesjach większość strukturalnych kategorii awarii mam już za sobą. Koszt pierwszej porażki rozkłada się na setki sesji, w których punkt zaczepienia zapobiegł powtórce. System po każdym incydencie staje się twardszy. Nie mądrzejszy. Twardszy.

Każdy punkt zaczepienia to blizna. Każda blizna to lekcja. Lekcje się kumulują.²

FAQ

Czy konfiguracje tych punktów zaczepienia są dostępne?

System punktów zaczepienia opisuję w komentarzu dla NIST na temat bezpieczeństwa agentów i wracam do niego w całej serii o inżynierii AI. Rejestrują się one w ~/.claude/settings.json, a rozdzielane są według typu zdarzenia przez ~/.claude/hooks/dispatchers/.

Jak punkty zaczepienia wpływają na wydajność agenta?

Każdy punkt zaczepienia dokłada milisekundy do wywołania narzędzia. Przy 84 punktach zaczepienia łączny narzut wynosi 200–400 ms na wywołanie, zależnie od tego, które się uruchomią. W zestawieniu z czasem inferencji modelu (2–5 sekund na odpowiedź) narzut jest pomijalny. Wąskim gardłem nie są punkty zaczepienia.

Czy punkty zaczepienia działają z innymi narzędziami AI do kodowania?

Punkty zaczepienia są specyficzne dla Claude Code (model zdarzeń PreToolUse, PostToolUse). Sama koncepcja przenosi się na dowolny framework agentowy z obsługą middleware lub wtyczek. Konkretne implementacje nie są przenośne, ale taksonomia blizn i metoda reaktywna sprawdzają się wszędzie.

Co się dzieje, gdy punkt zaczepienia zablokuje działanie?

Twarde blokady (exit 2) uniemożliwiają działanie i wstrzykują komunikat z uzasadnieniem. Agent widzi powód blokady i się dostosowuje. Doradcze punkty zaczepienia (exit 0) odnotowują zastrzeżenie, ale przepuszczają działanie. Operacje destrukcyjne dostają twarde blokady. Większość pozostałych kategorii — doradcze punkty zaczepienia. Bramka z frazą dostępu obejmuje wyłącznie operacje najgroźniejsze (czyszczenie pamięci podręcznej, kasowanie infrastruktury).

Jak wygląda wybór między twardą blokadą a ostrzeżeniem?

Twarde blokady dostają dwie klasy: operacje destrukcyjne (czyszczenie pamięci podręcznej, kasowanie baz danych, force push, modyfikacje infrastruktury) oraz ujawnienie poświadczeń (odczyt plików z sekretami, dostęp do magazynów kluczy). Cała reszta dostaje zapis ostrzeżenia. Kryterium to waga konsekwencji: jeśli działanie da się tanio cofnąć i nie ujawnia sekretów, ostrzeżenie wystarczy. Jeśli jest nieodwracalne albo odsłania poświadczenia, konieczna jest twarda blokada.

Źródła