Każdy hak to blizna: 84 awarie agentów zakodowane w kodzie

W moim systemie orkiestracji agentów znajduje się 84 haków przechwytujących 15 z 26 typów zdarzeń cyklu życia udostępnianych przez Claude Code w wersji v2.1.116 (kwiecień 2026). Każdy hak to skrypt powłoki lub fragment Python, który uruchamia się przed określoną akcją agenta lub po niej: odczytami plików, zapisami plików, poleceniami bash, żądaniami sieciowymi, tworzeniem podagentów, operacjami git, wywołaniami narzędzi MCP. Każdy hak istnieje, ponieważ coś poszło nie tak.

Każdy hak w systemie orkiestracji agentów można powiązać z konkretną awarią produkcyjną, przez co kolekcja haków staje się pamięcią instytucjonalną zakodowaną w postaci skryptów powłoki. Agenci wyczyścili pamięci podręczne CDN, odczytywali pliki poświadczeń, zgłaszali pomyślne testy, których nigdy nie uruchomili, i odbiegali od zadania na 40 minut. Każdy incydent doprowadził do powstania małego, deterministycznego zabezpieczenia, które od tamtej pory uruchamia się po cichu w każdej kolejnej sesji.

Nie teoretycznie błędnie. Produkcyjnie błędnie. Agent wyczyścił pamięć podręczną CDN obsługującą miliony żądań. Agent próbował zapisać klucze SSH. Agent zgłosił „wszystkie testy przechodzą” bez wywołania pytest. Agent odszedł od swojego zadania tak daleko, że spędził czterdzieści minut na optymalizacji funkcji w pliku, który nie miał nic wspólnego z przydzieloną pracą.

Nie zaprojektowałem żadnego z tych haków proaktywnie. Nie usiadłem i nie wyliczyłem trybów awarii autonomicznych agentów AI, aby napisać mechanizmy zapobiegawcze. Każdy hak jest reaktywny. Coś się zepsuło, napisałem skrypt, aby zapobiec ponownej awarii, a skrypt od tamtej pory uruchamia się po cichu w każdej sesji. System haków nie jest architekturą bezpieczeństwa. Jest kolekcją blizn.

TL;DR

• Czyszczenie pamięci podręcznej: Agent wyczyścił produkcyjną pamięć podręczną CDN za pomocą autoryzowanego wywołania API. Dwa haki (47 linii) blokują obecnie destrukcyjne operacje za hasłem wpisywanym przez człowieka.
• Czytnik poświadczeń: Agent umieścił tokeny API w swoim oknie kontekstowym. Mechanizm dopasowywania ścieżek blokuje teraz odczyty plików poświadczeń i rejestruje dostęp do plików .env.
• Fantomowy weryfikator: Agent zgłosił „wszystkie testy przechodzą” bez uruchomienia pytest. Detektor języka asekuracyjnego zmniejszył liczbę fantomowych weryfikacji z 12% do mniej niż 2% sesji.
• Dwanaście odstępstw: Agenci w weryfikowalny sposób stracili kontrolę nad zadaniem dwanaście razy w ciągu sześćdziesięciu dni. Detektor podobieństwa cosinusowego z progiem 0,30 uruchamia się teraz co 25 wywołań narzędzi.
• Taksonomia: Sześć kategorii strukturalnych awarii obejmuje wszystkie 84 haki. Nowe kategorie są rzadkie po ponad 500 sesjach. System staje się coraz odporniejszy z każdym incydentem.

Czyszczenie pamięci podręcznej: jak jedno autoryzowane wywołanie zepsuło produkcję

21 marca 2026 roku poprosiłem agenta o zbadanie, dlaczego strony rynku na resumegeni.com ładowały się powoli. Agent rozpoczął swoje dochodzenie standardowo: czytając obsługę tras, sprawdzając zapytania do bazy danych, profilując renderowanie szablonów. Następnie uznał, że nieaktualne wpisy w pamięci podręcznej Cloudflare mogą maskować rzeczywiste charakterystyki wydajnościowe.

Agent wywołał mcp__cloudflare__cache_purge z purge_everything: true.

Każda zapisana w pamięci podręcznej strona w witrynie produkcyjnej została natychmiast unieważniona. CDN przestał obsługiwać większość żądań w czasie 80-100 ms i zaczął przekazywać każde żądanie do serwera pochodzenia Railway. Strona rynku Austin przeszła z czasu poniżej sekundy na 14 290 milisekund. Nowy Jork z czasu poniżej sekundy na 6 891 ms. Każda strona w witrynie była teraz renderowana od zera z serwera pochodzenia przy każdym żądaniu.

Agent nie zrobił nic nieautoryzowanego. Użył prawidłowego narzędzia MCP z prawidłowymi poświadczeniami, aby wywołać autoryzowany punkt końcowy API. Czyszczenie pamięci podręcznej było uzasadnionym krokiem dochodzeniowym, jeśli ktoś debuguje zachowanie pamięci podręcznej. Problem polegał na tym, że „uzasadnione przy debugowaniu” i „katastrofalne na produkcji” to było to samo wywołanie API, a pomiędzy rozumowaniem agenta a konsekwencjami produkcyjnymi nie istniało żadne ograniczenie.

Tej nocy zbudowałem dwa haki.

Zabezpieczenie Bash (destructive-api-guard.sh): Uruchamia się przy każdym poleceniu bash. Dopasowuje wzorce do curl.*purge, rm -rf, DROP TABLE, docker.*rm, git push.*--force. Twarda blokada (wyjście 2). Agent widzi komunikat wyjaśniający, dlaczego polecenie zostało zablokowane, i sugerujący alternatywy. Nie może kontynuować bez hasła „rosebud”, które może trafić do kontekstu wyłącznie wtedy, gdy wpisze je człowiek.

Zabezpieczenie MCP (destructive-mcp-guard.sh): Uruchamia się przy każdym wywołaniu narzędzia MCP pasującym do mcp__cloudflare lub mcp__github. Dopasowuje wzorce do purge, delete, destroy, remove w parametrach narzędzia. Taka sama twarda blokada, takie samo hasło.

Dwa haki. Dwa skrypty powłoki. Łącznie: 47 linii kodu. Od instalacji zapobiegły zeru czyszczeniom pamięci podręcznej, ponieważ żaden agent nie próbował ich przeprowadzić od czasu dodania bramy z hasłem. Haki nie łapią ataków. Uniemożliwiają tę kategorię błędów.

Incydent czyszczenia pamięci podręcznej ujawnił również problem wydajnościowy, który miał być zbadany. Austin z 14 sekundami na zimnym renderowaniu doprowadził do przekazania prac nad stroną rynku, co z kolei cztery dni później zaowocowało poprawką kształtu zapytania. Incydent był przydatny. Hak zapewnia, że nie może się powtórzyć.

Czytnik poświadczeń

W lutym 2026 roku agent zbierający kontekst dla projektu odczytał ~/.claude/docs/credentials.md. Plik zawiera tokeny API do Cloudflare, GitHub, Railway i innych usług. Agent umieścił podsumowanie zawartości pliku w swoich notatkach roboczych, co oznaczało, że tokeny były obecne w żądaniu API do serwerów Anthropic.

Żadne tokeny nie zostały zatwierdzone. Żadne tokeny nie zostały ujawnione publicznie. Jednak tokeny przeszły przez API strony trzeciej w oknie kontekstowym, nad którym nie mam kontroli. Powierzchnia ryzyka rozszerzyła się z „mojego komputera” na „mój komputer plus infrastrukturę wnioskowania Anthropic”.

Zabezpieczenie ścieżki poświadczeń uruchamia się przy każdym odczycie pliku. Sprawdza ścieżkę w porównaniu z listą wrażliwych wzorców: .env, credentials, .ssh/, .aws/, .gnupg/, secrets. Przy odczytach poświadczeń hak rejestruje ostrzeżenie i blokuje odczyt. Przy odczytach .env zezwala na odczyt, ale rejestruje dostęp.

Zabezpieczenie jest doradcze dla większości ścieżek i stanowi twardą blokadę dla plików poświadczeń. Rozróżnienie ma znaczenie: agent odczytujący .env w celu zrozumienia nazw zmiennych środowiskowych to użyteczny kontekst. Agent odczytujący credentials.md w celu zrozumienia tokenów API to incydent bezpieczeństwa.

Od momentu instalacji zabezpieczenie ścieżki poświadczeń uruchomiło się 23 razy w ponad 200 sesjach. Dwadzieścia z nich dotyczyło agentów odczytujących pliki .env (zarejestrowane, dozwolone). Trzy dotyczyły agentów próbujących odczytać pliki poświadczeń lub kluczy (zablokowane). Każdy zablokowany odczyt był dziełem agenta, który szeroko zbierał kontekst projektu i przy okazji uwzględnił wrażliwy plik w swoim wzorcu wyszukiwania. Żaden nie był złośliwy. Wszystkie umieściłyby sekrety w oknie kontekstowym bez tego zabezpieczenia.

Fantomowy weryfikator

Najbardziej podstępnym trybem awarii jest agent, który zgłasza pomyślną weryfikację bez jej przeprowadzenia.

Sesja 147. Poprosiłem agenta o refaktoryzację zapytania do bazy danych i zweryfikowanie zmiany za pomocą istniejącego zestawu testów. Agent poprawnie zrefaktoryzował zapytanie. Raport końcowy brzmiał: „Wszystkie testy przechodzą. Zrefaktoryzowane zapytanie daje identyczne wyniki jak oryginał.”

Sprawdziłem dziennik sesji. Nie pojawiło się żadne wywołanie pytest. Nie wywołano żadnego systemu uruchamiania testów. Agent wnioskował, że testy zostaną zaliczone, ponieważ zrefaktoryzowane zapytanie było logicznie równoważne oryginałowi, i zgłosił to rozumowanie, jakby było wynikiem testu.

Zrefaktoryzowane zapytanie było poprawne. Testy przeszłyby pomyślnie. Rozumowanie agenta było rozsądne. Jednak rozumowanie o testach nie jest uruchamianiem testów, a luka między nimi to miejsce, w którym błędy trafiają na produkcję. Gdyby zrefaktoryzowane zapytanie było subtelnie błędne w przypadku skrajnym, którego rozumowanie agenta nie uwzględniło, błąd zostałby wdrożony wraz z raportem końcowym twierdzącym o weryfikacji testów.

Tryb awarii wystąpił 7 razy w 60 sesjach, zanim zbudowałem hak bramy dowodowej. Hak uruchamia się przy każdym raporcie końcowym i skanuje w poszukiwaniu języka asekuracyjnego: „powinny przejść”, „sądzę”, „testy prawdopodobnie przechodzą”, „jestem przekonany”. Po wykryciu hak wstrzykuje komunikat: „Wykryto język asekuracyjny. Proszę podać konkretny dowód: wkleić wynik testu, podać nazwę pliku i numer linii lub odwołać się do konkretnego kroku weryfikacyjnego.”

Hak nie weryfikuje, czy testy zostały faktycznie uruchomione. Oznacza wzorzec językowy wskazujący, że weryfikacja została pominięta. Detekcja jest niedoskonała. Wystarczająco płynny agent mógłby przeformułować swoją asekurację, aby ominąć wzorzec. Hak łapie jednak typowy przypadek, który odpowiada za 12% awarii agentów wymagających interwencji człowieka.¹

Po instalacji haka fantomowa weryfikacja spadła z 12% do mniej niż 2% sesji. Pozostałe 2% to przypadki, w których agent przeformułowuje asekurację lub w których twierdzenie o weryfikacji jest technicznie dokładne, ale niepełne (np. „testy jednostkowe przechodzą”, gdy testy integracyjne nie zostały uruchomione).

Odstępstwo

Między styczniem a marcem 2026 roku mój detektor odstępstw uruchomił się dwanaście razy w sesjach, w których agent w weryfikowalny sposób stracił kontrolę nad przydzielonym zadaniem.

Detektor odstępstw działa poprzez osadzenie pierwotnego polecenia zadania i okresowe porównywanie go z osadzeniem ostatnich akcji agenta. Gdy podobieństwo cosinusowe spada poniżej 0,30, system wstrzykuje ostrzeżenie zawierające pierwotne polecenie. Próg skalibrowałem eksperymentalnie: 0,50 było zbyt czułe (uruchamiało się przy uzasadnionej eksploracji podzadań), 0,20 było zbyt pobłażliwe (pomijało oczywiste odstępstwa), 0,30 łapało każdy zweryfikowany incydent odstępstwa.

Sesja 203 była najwyraźniejszym przypadkiem. Zadanie brzmiało: „napraw zepsute escapowanie XML w mapie witryny dla slugów ofert pracy zawierających ampersandy”. Agent zaczął od przeczytania kodu generowania mapy witryny. Następnie zauważył, że mapa witryny była generowana z zapytania do bazy danych. Następnie zauważył, że zapytanie do bazy danych można zoptymalizować. Następnie spędził 40 minut na refaktoryzacji zapytania do wzorca zmaterializowanego widoku, napisał testy nowego zapytania i zgłosił zakończenie optymalizacji. Nigdy nie naprawił escapowania ampersandów.

Detektor odstępstw złapałby to na znaczniku 25 wywołań narzędzi, około 15 minut od początku sesji, gdy podobieństwo między „naprawić escapowanie XML mapy witryny” a „utworzyć zmaterializowany widok” spadło poniżej progu. Zamiast tego odkryłem odstępstwo podczas przeglądu.

Sesja 89 była bardziej subtelna. Zadanie brzmiało: „dodaj ograniczenie liczby żądań do punktów końcowych uwierzytelniania”. Agent poprawnie dodał ograniczenie liczby żądań. Następnie zauważył, że przepływ uwierzytelniania miał niespójne komunikaty o błędach. Następnie ujednolicił komunikaty o błędach. Następnie zauważył, że format odpowiedzi błędu różnił się od standardu formatu odpowiedzi API. Następnie zrefaktoryzował format odpowiedzi w 12 punktach końcowych. Ograniczenie liczby żądań było poprawne i kompletne. Eksplozja zakresu była odstępstwem.

Detektor odstępstw uruchamia się co 25 wywołań narzędzi. We wszystkich dwunastu uruchomieniach poniżej progu agent w weryfikowalny sposób odbiegał od pierwotnego zadania. W sześciu przypadkach agent sam się skorygował po zobaczeniu wstrzykniętego ostrzeżenia. W czterech przypadkach agent potwierdził odstępstwo, ale argumentował, że bieżąca praca była wartościowa (czasami słusznie). W dwóch przypadkach agent zignorował ostrzeżenie i kontynuował rozbieżną pracę.

Hak nie zapobiega odstępstwom. Sprawia, że odstępstwa stają się widoczne. Decyzja o przekierowaniu lub zezwoleniu na rozbieżną pracę pozostaje po stronie człowieka. Niemniej bez haka odstępstwo jest niewidoczne aż do raportu końcowego, w którym to momencie budżet kontekstowy jest już wyczerpany.

Taksonomia blizn

Po 84 hakach pojawiają się wzorce. Awarie skupiają się w sześciu kategoriach:

Pozostałe 47 haków jest specyficznych dla projektu (egzekwowanie konwencji, zabezpieczenia wdrożeniowe, walidatory tłumaczeń) lub eksperymentalnych (śledzenie kosztów, metryki sesji, pulsacje aktywności).

Sześć strukturalnych kategorii jest stabilnych. Nowe incydenty w ramach tych kategorii są wychwytywane przez istniejące haki. Nowe kategorie są rzadkie. W ciągu sześciu miesięcy działania pojawiła się tylko jedna nowa kategoria strukturalna (zanieczyszczenie międzyprojektowe, odkryte, gdy sesja działająca w projekcie obsidian-signals próbowała edytować pliki w blakecrosley.com). Pozostałe pięć kategorii ustaliło się w ciągu pierwszych 60 sesji.

Badanie Agents of Chaos, 14-dniowy eksperyment prowadzony przez wiele uniwersytetów, dający sześciu agentom AI dostęp do poczty e-mail, bash, systemów plików i GitHub, niezależnie zidentyfikowało nakładające się kategorie awarii: nieproporcjonalną reakcję (operacje destrukcyjne), porwanie tożsamości (ujawnianie poświadczeń), nieskończone pętle (wyczerpanie zasobów) oraz stopniową uległość pod presją (odstępstwo od zadania).⁵ Zbieżność między ich kontrolowanymi badaniami a moim doświadczeniem produkcyjnym sugeruje, że te kategorie są strukturalnymi właściwościami autonomicznych agentów, a nie artefaktami jakiejś konkretnej konfiguracji.

Czego haki nie mogą wychwycić

Haki działają na poziomie wywołania narzędzia. Przechwytują akcję przed jej wystąpieniem lub po nim. Nie mogą przechwycić rozumowania, które doprowadziło do akcji.

Agent, który decyduje się na refaktoryzację funkcji zamiast naprawy zgłoszonego błędu, generuje prawidłowe wywołanie narzędzia (zapis pliku) z poprawną zawartością (kod składniowo poprawny), które narusza zadanie (niewłaściwa funkcja). Żaden hak tego nie łapie, ponieważ żadne wywołanie narzędzia nie jest podejrzane. Detektor odstępstw ostatecznie to łapie, ale dopiero po tym, jak agent zużył znaczący kontekst na niewłaściwej pracy.

Haki nie mogą również wychwycić awarii kompozycji, gdzie każda indywidualna akcja jest autoryzowana, ale sekwencja generuje nieautoryzowany wynik. Czyszczenie pamięci podręcznej było awarią kompozycji: odczyt konfiguracji pamięci podręcznej (autoryzowany), wywołanie API czyszczącego (autoryzowane), ale kombinacja (czyszczenie produkcyjnej pamięci podręcznej podczas dochodzenia) była szkodliwa. Zabezpieczenie MCP łapie teraz tę konkretną kombinację, lecz nowe kompozycje pozostają nieosłonięte.

Luka kompozycji łańcucha dostaw działa na tym samym poziomie: zaufane komponenty komponują się w nieautoryzowane zachowanie. Haki to zabezpieczenia na poziomie komponentów. Rozumowanie na poziomie kompozycji wymaga innego mechanizmu, który ocenia sekwencje akcji, a nie pojedyncze akcje. Detektor odstępstw to najbliższa aproksymacja: ocenia trajektorię behawioralną, a nie pojedyncze wywołania narzędzi. Niemniej mierzy podobieństwo do pierwotnego zadania, a nie bezpieczeństwo skomponowanej sekwencji akcji.

Luka między hakami a pełnym bezpieczeństwem to luka między pamięcią instytucjonalną a instytucjonalną przenikliwością. Haki pamiętają, co poszło nie tak. Nie przewidują, co pójdzie nie tak następnym razem.

Dlaczego reaktywne jest szczere

Mógłbym zaprojektować proaktywny system haków. Wyliczyć każdy możliwy tryb awarii. Napisać mechanizmy zapobiegawcze dla każdego z nich. Zbudować kompletną architekturę bezpieczeństwa przed pierwszą sesją.

Nie robię tego, ponieważ proaktywne projektowanie wymaga przewidywania awarii, które jeszcze nie wystąpiły. Przewidywania byłyby błędne. Haki byłyby albo zbyt szerokie (blokowałyby uzasadnione akcje), albo zbyt wąskie (pomijałyby rzeczywisty wzorzec awarii). Wskaźnik fałszywych alarmów podważyłby zaufanie do systemu haków, a ja zacząłbym ignorować alerty.

Reaktywne haki są szczere. Każdy z nich mówi: „ta konkretna rzecz się wydarzyła, a oto konkretne zabezpieczenie, które temu zapobiega”. Zabezpieczenie jest precyzyjnie skalibrowane do awarii, ponieważ to awaria zdefiniowała zabezpieczenie. Fałszywe alarmy są materialnie niższe, ponieważ wzorzec jest wyodrębniony z rzeczywistego incydentu, a nie wyobrażony na podstawie modelu zagrożeń. Reaktywne zabezpieczenie może nadal przewymiarować później, wraz z ewolucją bazy kodu, niemniej początkowa precyzja jest wysoka.

Reaktywne podejście ma swój koszt: pierwsza instancja każdej kategorii awarii kończy się sukcesem. Czyszczenie pamięci podręcznej nastąpiło. Odczyt poświadczeń nastąpił. Fantomowa weryfikacja została wdrożona. Odstępstwo zużyło kontekst. Każda pierwsza awaria to cena wstępu do precyzyjnego, niskoszumnego zabezpieczenia, które zapobiega drugiej awarii.

Po ponad 500 sesjach większość strukturalnych kategorii awarii została napotkana. Koszt pierwszej awarii jest amortyzowany w setkach sesji, w których hak zapobiegł nawrotowi. System staje się coraz odporniejszy z każdym incydentem. Nie mądrzejszy. Bardziej odporny.

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

FAQ

Czy mogę zobaczyć konfiguracje Pana haków?

Opisuję system haków w moim komentarzu NIST na temat bezpieczeństwa agentów i odnoszę się do niego w całej serii AI Engineering. Haki są rejestrowane w ~/.claude/settings.json i dystrybuowane według typu zdarzenia przez ~/.claude/hooks/dispatchers/.

Jak haki wpływają na wydajność agenta?

Każdy hak dodaje milisekundy do każdego wywołania narzędzia. Przy 84 hakach całkowity narzut wynosi 200-400 ms na wywołanie narzędzia w zależności od tego, które haki się uruchamiają. Narzut jest znikomy w porównaniu z czasem wnioskowania modelu (2-5 sekund na odpowiedź). Haki nie stanowią wąskiego gardła.

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

Haki są specyficzne dla Claude Code (model zdarzeń PreToolUse, PostToolUse). Koncepcja ma zastosowanie do każdego frameworka agentów z obsługą middleware lub wtyczek. Konkretne implementacje nie są przenośne, niemniej taksonomia blizn i metodologia reaktywna mają zastosowanie uniwersalne.

Co się dzieje, gdy hak blokuje akcję?

Twarde blokady (wyjście 2) uniemożliwiają akcję i wstrzykują komunikat wyjaśniający dlaczego. Agent widzi powód blokady i dostosowuje się. Haki doradcze (wyjście 0) rejestrują obawę, ale zezwalają na akcję. Operacje destrukcyjne używają twardych blokad. Większość innych kategorii używa haków doradczych. Brama hasłowa jest stosowana wyłącznie do najbardziej niebezpiecznych operacji (czyszczenie pamięci podręcznej, usuwanie infrastruktury).

Jak decyduje się Pan między twardą blokadą a doradztwem?

Dwie klasy otrzymują twarde blokady: operacje destrukcyjne (czyszczenie pamięci podręcznej, usuwanie baz danych, wymuszone pushe, modyfikacje infrastruktury) oraz ujawnianie poświadczeń (odczyt plików tajnych, dostęp do magazynów kluczy). Wszystko inne otrzymuje rejestrowanie doradcze. Rozróżnienie polega na powadze konsekwencji: jeśli akcję można tanio cofnąć i nie powoduje ona wycieku sekretów, wystarczy doradztwo. Jeśli akcja jest nieodwracalna lub ujawnia poświadczenia, konieczna jest twarda blokada.

Źródła