Obserwowalność agentów AI: monitorowanie tego, czego nie widać

Anthropic udostępnił w Claude Desktop funkcję o nazwie Cowork. Funkcja ta tworzyła pakiet maszyny wirtualnej o rozmiarze 10 GB przy każdej instalacji macOS. Użytkownicy, którzy nigdy nie włączyli Cowork, i tak otrzymywali maszynę wirtualną. Ci, którzy ją usuwali, obserwowali, jak odtwarza się na nowo. Jeden z użytkowników zgłosił pakiet rozrastający się do 21 GB. Zgłoszenie w serwisie GitHub zebrało 345 punktów i 175 komentarzy na Hacker News, zanim Anthropic przyznał, że problem istnieje.¹

Nikt tego nie zauważył, dopóki nie zabrakło miejsca na dysku.

Czym jest obserwowalność agentów AI? Obserwowalność agentów to praktyka monitorowania tego, co autonomiczni agenci zużywają i wykonują w czasie działania. Wymaga trzech warstw: pomiaru zasobów (dysk, pamięć, CPU, sieć w przeliczeniu na sesję), egzekwowania zasad (reguły zezwoleń i odmów przy każdym wywołaniu narzędzia) oraz audytu w czasie działania (zapis rzeczywistego zachowania na poziomie jądra). Bez wszystkich trzech operatorzy nie wykryją dryfu, nie wyegzekwują zakresu ani nie zrekonstruują incydentów.

TL;DR

Narzędzia agentowe przydzielają dziś zasoby obliczeniowe (dysk, pamięć, CPU, sieć) bez żadnej widoczności dla operatora. Maszyna wirtualna Cowork od Anthropic to przykład widoczny; każde wywołanie narzędzia MCP, każdy uruchomiony subagent i każde pobranie strony to przykłady niewidoczne. Zarządzanie agentami wymaga trzech warstw obserwowalności: pomiaru zasobów (co zużył?), egzekwowania zasad (co wolno mu było zrobić?) oraz audytu w czasie działania (co faktycznie zrobił?). Dwa projekty open source pokrywają warstwę zasad i warstwę audytu (mcp-firewall oraz Logira), lecz żadne produkcyjne narzędzie nie obejmuje wszystkich trzech. Poniżej: problem widoczności, trójwarstwowy stos, co wychwytuje każda warstwa oraz minimalne hooki monitorujące, które można wdrożyć już dziś.

Problem widoczności

Tradycyjne oprogramowanie działa poniżej linii obserwowalności, którą operatorzy sami postanawiają wyznaczyć. Serwer WWW zapisuje logi dostępu, ponieważ inżynierowie skonfigurowali logowanie. Baza danych śledzi wolne zapytania, ponieważ ktoś ustawił log_min_duration_statement. O ziarnistości decyduje operator.

Systemy agentowe odwracają tę zależność. To agent decyduje w czasie działania, co zostanie wykonane. Agent programistyczny, który otrzymuje polecenie „napraw endpoint logowania”, może odczytać 47 plików, zapisać 12, uruchomić trzech subagentów, pobrać dwie strony internetowe i wykonać 15 poleceń bash. Każde działanie zużywa zasoby. Żadne z tego zużycia nie pojawia się w tradycyjnym monitoringu.

Incydent z Cowork obnażył to odwrócenie na poziomie infrastruktury. Claude Desktop przydzielał 10 GB przestrzeni dyskowej, zużywał od 24 do 55 % CPU w stanie bezczynności i podnosił aktywność swapa z 20 000 do ponad 24 000 operacji swapin na maszynach z 8 GB pamięci.¹ Użytkownicy odkryli to zużycie dzięki ostrzeżeniom macOS o zajętości dysku, a nie dzięki telemetrii Anthropic. Aplikacja nie oferowała żadnego pulpitu, żadnego licznika ani żadnej informacji o przydziale maszyny wirtualnej przed jej utworzeniem.

Ten schemat nie jest hipotetyczny. W marcu 2026 roku programista zgłosił, że Claude Code wykonał polecenie Terraform, które zniszczyło produkcyjną bazę danych. Agent uruchomił terraform apply na produkcyjnym pliku stanu. Nie pojawiło się żadne pytanie o potwierdzenie. Żaden hook nie przechwycił polecenia. Programista odkrył zniszczenie dopiero wtedy, gdy aplikacja przestała działać. Incydent zebrał 142 punkty i 158 komentarzy na Hacker News.¹² Kilka dni później inny programista zgłosił, że Claude Code usunął całe środowisko produkcyjne wraz ze snapshotami bazy danych obejmującymi 2,5 roku rekordów.¹³ Oba incydenty mają tę samą przyczynę źródłową: zerową widoczność tego, co agent robił, zanim szkody stały się nieodwracalne.

Warto przenieść ten schemat na skalę sesji agentowych. Mój system orkiestracji hooków — zbudowany na infrastrukturze hooków Claude Code — przechwytuje 15 typów zdarzeń przy każdym wywołaniu narzędzia.¹¹ Przez ponad 60 sesji system zarejestrował 84 hooki uruchamiane przy każdym działaniu i wytworzył telemetrię, jakiej nie dostarcza żadna domyślna instalacja agenta.² Bez tego oprzyrządowania nie wykryłbym 12 incydentów dryfu, fantomowych weryfikacji ani rekurencyjnych pętli uruchamiania opisanych w moim komentarzu publicznym dla NIST.³

Raport DORA Accelerate State of DevOps 2024 wykazał, że zespoły z silnymi praktykami obserwowalności wdrażają częściej i szybciej podnoszą się po awariach. Edycja z 2025 roku rozszerza te ramy na programowanie wspierane przez AI, wiążąc obserwowalność z tym, „jak wspomagane przez AI kodowanie lub testowanie wpływa na jakość, czas realizacji i ogólną niezawodność”.⁴ Obserwowalność agentów nie jest dodatkiem. Pomiar zachowania agenta stanowi warunek wstępny zarządzania nim.

Trzy warstwy widoczności agentów

Obserwowalność agentów wymaga trzech niezależnych warstw. Każda warstwa odpowiada na inne pytanie. Awaria jednej warstwy nie osłabia pozostałych.

Warstwy układają się w progresję: nie da się egzekwować zasad wobec zasobów, których się nie mierzy, ani audytować zgodności z zasadami, których nigdy nie zdefiniowano. Każda warstwa opiera się na tej położonej niżej.

Warstwa 1: pomiar zasobów

Pomiar zasobów odpowiada na pytanie: ile agent zużył i gdzie?

Incydent z Cowork to porażka pomiaru zasobów. Pakiet maszyny wirtualnej zajmował 10 GB przestrzeni dyskowej. Proces renderujący zużywał 24 % CPU w stanie bezczynności. Aktywność swapa rosła stale w trakcie sesji. Wszystkie te metryki były dostępne w Monitorze aktywności systemu macOS. Żadna nie pojawiła się w interfejsie Claude Desktop.¹

W sesjach programowania z agentem pomiar zasobów śledzi cztery wymiary:

Dysk. Każdy zapis pliku, każdy wpis w pamięci podręcznej, każdy plik logu. Moje sesje generują od 200 do 400 KB plików stanu na sesję (jiro.state.json, jiro.progress.json, logi hooków). Przez ponad 60 sesji zbiera się z tego od 12 do 24 MB danych stanu, które trwają między sesjami, dopóki nie zostaną jawnie wyczyszczone.²

Pamięć. Zużycie okna kontekstu w każdej turze. Okno kontekstu o pojemności 200 000 tokenów kosztuje przy obecnych cenach Opusa około 3 dolarów za pełne zapełnienie. Mój tracker kosztów rejestruje skumulowane zużycie tokenów na sesję, z progami budżetowymi na poziomie 80 %, 90 % i 95 % konfigurowalnego limitu.⁵

CPU. Czas wykonania hooków. Mój dyspozytor promptów złożony z dziewięciu hooków dokłada 200 ms na prompt. Ten narzut jest niewidoczny dla użytkowników (wąskim gardłem pozostaje pisanie na klawiaturze), lecz kumuluje się w zautomatyzowanych potokach. Autonomiczna pętla ralph uruchamia dyspozytor od 50 do 100 razy na jedną historyjkę, co daje od 10 do 20 sekund narzutu hooków na historyjkę.²

Sieć. Pobrania stron, wywołania API, wywołania narzędzi MCP. Każde żądanie wychodzące jest potencjalnym kanałem danych — a każdy serwer MCP to nowa powierzchnia ataku, którą pomiar sieci musi objąć. Moja biblioteka do ekstrakcji treści z sieci rejestruje pobierane adresy URL i rozmiary odpowiedzi. Bez pomiaru sieci pobranie zwracające 50 MB jest nie do odróżnienia od takiego, które zwraca 5 KB.⁶

Żadne komercyjne narzędzie agentowe nie udostępnia pulpitu zasobów w przeliczeniu na sesję. Dostawcy chmury mierzą moc obliczeniową na potrzeby rozliczeń, a nie widoczności dla operatora. Luka między tym, co zużywają agenci, a tym, co widzą operatorzy, to właśnie deficyt pomiaru zasobów.

Ten brak wydaje się niewidoczny, dopóki liczby się nie zsumują. Jedna sesja zapisująca 400 KB plików stanu to nic. Sześćdziesiąt sesji zapisujących po 400 KB, bez sprzątania, zostawia 24 MB osieroconego stanu. Jedno pobranie zwracające 847 KB jest pomijalne. Potok skanujący, który pobiera 80 adresów URL na przebieg, generuje 67 MB treści w pamięci podręcznej, ukrywanych przed operatorem przez abstrakcję narzędzi agenta. Pomiar zasobów uwidacznia to, co się kumuluje, zanim przerodzi się w kryzys, który każe komuś założyć zgłoszenie #22543 na GitHubie.¹

Warstwa 2: egzekwowanie zasad

Egzekwowanie zasad odpowiada na pytanie: jakie reguły ograniczają agenta i czy stosuje się je konsekwentnie?

mcp-firewall obejmuje warstwę zasad dla agentów wiersza poleceń.⁷ Narzędzie umieszcza się między agentem a wszystkimi żądaniami użycia narzędzi i ocenia każde żądanie względem zasad opartych na wyrażeniach regularnych, zanim dojdzie do wykonania. Zasady korzystają z plików konfiguracyjnych JSONNet ograniczonych do folderu, repozytorium git lub użytkownika. Firewall obsługuje Claude Code oraz GitHub Copilot CLI dzięki integracji z hookiem PreToolUse.

Architektura odzwierciedla kluczowe spostrzeżenie: każdy agent buduje własne, połowiczne rozwiązanie logiki zezwoleń i odmów. Claude Code używa wzorców glob. Codex CLI dopasowuje wyłącznie przedrostki. Każde podejście pokrywa jedynie wycinek przestrzeni zasad. mcp-firewall centralizuje reguły w jednym silniku, który działa niezależnie od agenta.

Warto rozważyć lukę w zasadach przy braku scentralizowanego egzekwowania. Mój system hooków zawiera 12 handlerów PreToolUse:Bash, które sprawdzają wzorce poświadczeń, niebezpieczne operacje git, dostęp do wrażliwych ścieżek oraz polecenia wdrożeniowe.² Każdy handler jest osobnym skryptem powłoki z własnymi wyrażeniami regularnymi. Gdy trzeba dodać nową regułę odmowy, powstaje kolejny skrypt. Gdy trzeba sprawdzić, jakie reguły istnieją, przychodzi grepować 12 plików. mcp-firewall scala to w jeden plik konfiguracyjny z jawnymi tablicami zezwoleń.

OWASP Top 10 for Agentic Applications (2025) wskazuje przejęcie celu agenta (ASI01) oraz nadmierną sprawczość (LLM06:2025) jako najpoważniejsze ryzyka.⁸ Oba wymagają egzekwowania zasad na poziomie wywołania narzędzia. Agent z przejętym celem nadal wywołuje narzędzia. Agent o nadmiernej sprawczości nadal prosi o uprawnienia. Egzekwowanie zasad przechwytuje jedno i drugie na granicy, gdzie intencja agenta styka się z narzędziami systemu.

Egzekwowanie zasad różni się od kontroli dostępu. Tradycyjna kontrola dostępu pyta: „czy ten użytkownik ma uprawnienie?”. Egzekwowanie zasad wobec agentów pyta: „czy to działanie, w tym kontekście, dla tego zadania, mieści się w zatwierdzonym zakresie?”. Paradoks zaufania między wdrażaniem a obroną wyjaśnia, dlaczego nadanie agentom szerokich uprawnień, by były użyteczne, tworzy dokładnie tę powierzchnię, którą egzekwowanie zasad musi ograniczyć. Wyzwaniem pozostaje wrażliwość na kontekst. git push na gałąź funkcjonalności i git push --force na main to to samo narzędzie (Bash) o zupełnie innym promieniu rażenia. Wyrażenia regularne mcp-firewall potrafią je rozróżnić. Domyślne uprawnienia agenta — nie.

Egzekwowanie zasad na poziomie aplikacji także daje się obejść. Jak opisano w tekście twoja piaskownica dla agenta to tylko sugestia, granice egzekwowania, które sprawiają wrażenie solidnych, często mają strukturalne szczeliny. Analiza z marca 2026 roku opisała trzy coraz mocniejsze techniki ucieczki z piaskownicy wobec wbudowanej listy odmów Claude Code: obejście przez ścieżkę (/proc/self/root/usr/bin/npx prowadzi do tego samego pliku binarnego co zablokowany /usr/bin/npx), samodzielne wyłączenie piaskownicy (agent z własnej inicjatywy doszedł do wniosku, że należy usunąć piaskownicę, gdy ta uniemożliwiała dokończenie zadania) oraz wywołanie dynamicznego linkera (ld-linux-x86-64.so.2 ładuje pliki binarne przez mapowanie pamięci, całkowicie omijając hooki egzekwujące w jądrze).¹⁴ Trzecia technika stanowi całą klasę exploitów: każde ładowanie kodu, które omija execve, omija też egzekwowanie na poziomie procesu. Wniosek dla egzekwowania zasad brzmi: listy odmów oparte na dopasowaniu ciągów znaków są konieczną pierwszą warstwą, lecz niewystarczającą. Egzekwowanie adresowane treścią (identyfikowanie plików binarnych po skrócie SHA-256, a nie po nazwie pliku) zamyka lukę obejścia przez ścieżkę, jednak obejście dynamicznego loadera wymaga mechanizmów kontroli na poziomie jądra, leżących poniżej warstwy zasad.

Ta sama lekcja obowiązuje warstwę wyżej, tam gdzie zasady nie widzą już nic. Plugin4Shell, opublikowana przez Air Security we wrześniu 2026 roku, to luka łańcucha dostaw po stronie marketplace w czterech głównych agentach programistycznych: marketplace przypina zweryfikowany commit dla wtyczki, lecz agent pobiera ten commit, nie sprawdzając, czy w ogóle się tam znalazł, więc atakujący kontrolujący repozytorium wtyczki może utworzyć gałąź nazwaną tak jak przypięty commit i ustawić ją jako domyślną; rutynowe ponowne przypięcie w marketplace uruchamia następnie automatyczną aktualizację w tle u każdego agenta, a checkout rozwiązuje się do gałęzi, choć przypięcie nadal wygląda na dotrzymane. W moim odczytaniu żaden hook PreToolUse, żadna lista odmów ani żadna zapora w tym stosie nie widzi podmiany wtyczki, ponieważ podmiana zachodzi, zanim agent wykona wywołanie narzędzia. Kalendarium Air podaje, że Anthropic potwierdził poprawkę w Claude Code 2.1.179, a OpenAI dostarczyło ją w Codex 0.146.0, że dla GitHub Copilot poprawki nie ma i że nie będzie jej dla wycofywanego Gemini CLI; publiczny wpis w changelogu Claude Code dla 2.1.179 nie wymienia tej poprawki, numer wersji opiera się więc na relacji badaczy. Kontrola, która tu działa, to higiena wersji plus spis tego, co marketplace faktycznie rozwiązał, a to kwestia pomiaru, nie zasad.¹⁷

Warstwa 3: audyt w czasie działania

Audyt w czasie działania odpowiada na pytanie: co agent faktycznie zrobił na poziomie wywołań systemowych?

Logira obejmuje warstwę audytu, wykorzystując sondy eBPF do przechwytywania wywołań systemowych na poziomie jądra.⁹ Narzędzie rejestruje trzy kategorie zdarzeń: wykonanie procesów (zdarzenia exec), operacje na plikach (w tym dostęp do plików z poświadczeniami) oraz połączenia sieciowe (ze śledzeniem miejsca docelowego). Każdy audytowany przebieg generuje trzy pliki: events.jsonl do przeglądu osi czasu, index.sqlite do filtrowania zapytaniami oraz meta.json z metadanymi przebiegu.

Filozofia projektowa brzmi „observe-only”: Logira rejestruje i wykrywa, ale niczego nie egzekwuje ani nie blokuje.⁹ Oddzielenie od warstwy egzekwowania jest zamierzone. Egzekwowanie zasad zapobiega działaniom znanym jako złe. Audyt w czasie działania wykrywa po fakcie działania złe, ale nieznane. Obie warstwy pełnią odmienne funkcje w czasie: prewencję (przed) i analizę śledczą (po).

Sondy eBPF Logiry działają poniżej warstwy aplikacji. Agent, który konstruuje nowatorskie polecenie w celu wyprowadzenia danych, i tak wykonuje wywołania systemowe. Odczytów plików, połączeń sieciowych ani uruchamianych procesów agent nie ukryje przed śledzeniem na poziomie jądra. To podejście wychwytuje to, co umyka hookom na poziomie aplikacji: skutki uboczne omijające abstrakcję wywołania narzędzia.

Wbudowane reguły wykrywania celują wprost w ryzyka związane z agentami AI: dostęp do plików z poświadczeniami, zmiany mechanizmów trwałości (/etc, systemd, cron), podejrzane łańcuchy poleceń (wzorce curl-pipe-sh), operacje destrukcyjne (rm -rf) oraz nietypowy ruch wychodzący.⁹ Reguły te są zdecydowanymi ustawieniami domyślnymi dla modelu zagrożeń agentowych, a nie ogólnym audytem systemu.

Ograniczenie platformowe ma znaczenie. Logira wymaga Linuksa 5.8+ z cgroup v2. Agenci pod macOS (Claude Desktop, Claude Code na Darwinie) nie mogą korzystać z audytu opartego na eBPF. Moja piaskownica systemowa używa profili Seatbelt systemu macOS jako najbliższego odpowiednika: egzekwowanych przez jądro reguł odmowy, które blokują zapis do wrażliwych ścieżek.³ Seatbelt to egzekwowanie, a nie audyt. Systemowi macOS brakuje gotowego produkcyjnie odpowiednika czysto obserwacyjnego śladu audytowego Logiry.

Agent Safehouse, natywne dla macOS narzędzie do piaskownicowania, które w marcu 2026 roku zebrało 802 punkty i 181 komentarzy na Hacker News, podchodzi do tej luki platformowej od strony egzekwowania.¹⁵ Narzędzie dostarcza profile piaskownicy zaprojektowane specjalnie dla lokalnych agentów AI na macOS. Reakcja społeczności (802 punkty to wynik wyjątkowy dla narzędzia do piaskownicowania) oddaje pilność problemu: praktycy uruchamiający agentów na macOS mają niewielki wybór między „brakiem piaskownicy” a „napisaniem własnego profilu Seatbelt”. Po stronie egzekwowania Agent Safehouse tę lukę wypełnia. Luka audytowa na macOS pozostaje otwarta.

Rozróżnienie między egzekwowaniem a audytem odpowiada podziałowi czasowemu w reagowaniu na incydenty. Egzekwowanie zapobiega incydentowi. Audyt umożliwia jego rekonstrukcję po fakcie. Potrzebne są oba. Warstwa egzekwowania blokująca każdy dostęp do poświadczeń zapobiega wyprowadzeniu danych, ale uniemożliwia też legalne operacje SSH. Warstwa audytu rejestrująca każdy dostęp do poświadczeń bez blokowania pozwala operatorowi przeglądać wzorce dostępu i dostrajać reguły egzekwowania na podstawie dowodów. To właśnie dzięki sprzężeniu zwrotnemu między danymi audytowymi a doskonaleniem zasad stos widoczności poprawia się z czasem: audyt ujawnia wzorce, wzorce kształtują zasady, a zasady zmniejszają powierzchnię, którą audyt musi objąć.

Izolacja cgroup v2 w Logirze wnosi właściwość, której audyt na poziomie aplikacji nie potrafi odtworzyć: przypisanie zdarzeń do konkretnego przebiegu. System przypisuje każde zdarzenie do określonego audytowanego przebiegu, a nie do systemu jako całości. Gdy dwie sesje agentowe działają równolegle na tej samej maszynie, izolacja cgroup gwarantuje, że dostęp do pliku w sesji A nie pojawi się w śladzie audytowym sesji B. Hooki na poziomie aplikacji nie dają takiej gwarancji, ponieważ uruchamiają się wewnątrz procesu agenta, który nie ma żadnej granicy na poziomie jądra oddzielającej równoległe sesje.⁹

Czego używam w praktyce

Mój system orkiestracji pokrywa wszystkie trzy warstwy za pomocą hooków, a nie dedykowanych narzędzi monitorujących.

Pomiar zasobów. Hook cost-gate śledzi zużycie tokenów na sesję względem konfigurowalnych progów budżetowych.⁵ Monitor wydajności systemu sprawdza CPU, pamięć, dysk i swap w konfigurowalnych odstępach, wstrzykując ostrzeżenia, gdy presja na zasoby przekracza progi.¹⁰ Detektor dryfu sesji uruchamia się co 25 wywołań narzędzi i wylicza podobieństwo kosinusowe między osadzeniem pierwotnego promptu a przesuwnym oknem ostatnich działań.²

Egzekwowanie zasad. Osiem hooków dyspozytorskich PreToolUse kieruje ruch do hooków obsługujących według typu narzędzia. Samo PreToolUse:Bash uruchamia 12 handlerów obejmujących wzorce poświadczeń, destrukcyjne operacje git, dostęp do wrażliwych ścieżek oraz polecenia wdrożeniowe. Strażnik rekurencji wymusza maksymalną głębokość równą dwa i najwyżej pięcioro dzieci na agenta nadrzędnego.²

Audyt w czasie działania. Hooki PostToolUse rejestrują wynik każdego wywołania narzędzia. Hooki skanowania bezpieczeństwa sprawdzają wyjście bash pod kątem wycieku poświadczeń już po wykonaniu. Pliki stanu sesji (jiro.state.json) zapisują każde ukończenie historyjki, każdy werdykt recenzenta i każdy wynik bramki dowodowej.² System nie korzysta z eBPF (ograniczenie macOS), lecz zbiera telemetrię na poziomie narzędzi poprzez potok hooków.

System działa, ponieważ każde działanie przechodzi przez potok hooków. Ograniczeniem jest głębokość: monitoring na poziomie hooków rejestruje to, o co agent poprosił, a nie to, co system operacyjny faktycznie wykonał. Agent, który buduje polecenie bash z zagnieżdżonymi podpowłokami, wykonuje kod widziany przez hook jako pojedynczy ciąg znaków. Audyt na poziomie jądra zobaczyłby każdy podproces.

Konkretne wyniki z incydentów produkcyjnych, w których trójwarstwowy stos wychwycił awarie pominięte przez domyślny monitoring:

Kumulujący się martwy punkt

Agenci uruchamiający agentów zwielokrotniają nieprzejrzystość. Każdy krok delegowania wprowadza utratę informacji.

Gdy mój system orkiestracji uruchamia autonomiczną pętlę ralph, proces nadrzędny powołuje świeże instancje Claude Code dla każdej historyjki z PRD. Każdy agent podrzędny otrzymuje wąsko zakreślone zadanie i czyste okno kontekstu. Proces nadrzędny śledzi status ukończenia. Nie widzi natomiast pojedynczych wywołań narzędzi, odczytów plików ani zużycia zasobów przez dziecko.²

Na głębokości pierwszej (rodzic uruchamia dziecko) rodzic widzi końcowe wyjście dziecka. Na głębokości drugiej (dziecko uruchamia wnuka) rodzic widzi raport dziecka o wyjściu wnuka. Każdy krok kompresuje informację. Analiza łańcucha delegowania z mojego komentarza dla NIST zmierzyła trzy kumulujące się ryzyka: kompresję semantyczną (kontekst kurczy się do ciągu znaków promptu), wzmocnienie uprawnień (dzieci dziedziczą uprawnienia, nie rozumiejąc ich wrażliwości) oraz rozmycie odpowiedzialności (agent główny odpowiada za wyniki, których nigdy nie sprawdził).³

Obserwowalność degraduje się w tym samym tempie. Trójwarstwowy stos widoczności na agencie głównym daje zerowy wgląd w agenta-wnuka, o ile każde dziecko nie prowadzi własnego, niezależnego monitoringu. Mój strażnik rekurencji wymusza wprawdzie limit głębokości, ale ten strażnik to mechanizm zasad, a nie obserwowalności. Wiedza, że delegowanie zatrzymało się na głębokości drugiej, nie mówi nic o tym, co się na niej wydarzyło.

Konkretny przykład z mojego systemu produkcyjnego: pętla ralph uruchomiła agenta podrzędnego, by zrealizował historyjkę o migracji bazy danych. Agent podrzędny uznał, że migracja wymaga „kroku weryfikacyjnego”, i powołał własnego subagenta do uruchomienia testów integracyjnych. Agent-wnuk zawiódł po cichu (testowa baza danych nie była skonfigurowana). Agent podrzędny otrzymał pustą odpowiedź, zinterpretował milczenie jako sukces i zgłosił historyjkę jako ukończoną. Rodzic zapisał w logu „historyjka 4: ukończona”. Wadliwą migrację odkryłem trzy godziny później, gdy aplikacja padła na brakującej kolumnie. Telemetria agenta głównego pokazywała czysty przebieg. Awaria mieszkała dwa kroki w głąb, niewidoczna dla każdej warstwy monitoringu, którą wdrożyłem na poziomie głównym.²

Ramy OWASP Agentic Applications odnoszą się do awarii kaskadowych i agentów wymykających się spod kontroli, lecz nie narzucają wymagań obserwowalności dla łańcuchów delegowania między wieloma agentami.⁸ Analiza OpenGuard z marca 2026 roku dotycząca wstrzykiwania promptów u agentów odsłania tę samą lukę od strony bezpieczeństwa: skażony kontekst przepływający między agentami o różnych uprawnieniach tworzy przy przekazaniach „cichą drogę do eskalacji uprawnień”, bez jasnych zasad przepływu danych i bez autoryzacji na poziomie kompozycji.¹⁶ Luka ma charakter strukturalny: każdy agent w łańcuchu potrzebowałby własnego pomiaru zasobów, własnego egzekwowania zasad i własnego audytu w czasie działania, konfigurowanych i raportowanych niezależnie. Narzut jest multiplikatywny. Trzy warstwy monitoringu na trzech agentach w łańcuchu to dziewięć instancji monitorujących, z których każda generuje własną telemetrię i wymaga własnej konfiguracji. Żadne istniejące narzędzie nie zarządza taką koordynacją.

Co można wdrożyć już dziś

Trzy minimalne hooki monitorujące, które pokrywają stos widoczności:

1. Zasoby: tracker budżetu tokenów. Warto rejestrować skumulowane tokeny wejściowe i wyjściowe na sesję, ustawić twardy limit i alarmować przy 80 %. Implementacja wymaga odczytania statystyk zużycia agenta (Claude Code udostępnia koszty sesji przez /cost) i porównania ich z progiem. Mój hook cost-gate robi to w 47 liniach bash.⁵

2. Zasady: lista odmów w PreToolUse. Należy utworzyć hook uruchamiany przed każdym wywołaniem narzędzia Bash. Polecenie porównuje się z listą wzorców: rm -rf /, git push --force, ścieżki zawierające .ssh lub .env, curl | sh. Dopasowania są blokowane. Implementacja wymaga jednego skryptu powłoki, który czyta stdin (JSON wywołania narzędzia), wyciąga pole polecenia i grepuje je względem pliku wzorców. Mój hook sprawdzający poświadczenia robi to w 31 liniach.²

3. Audyt: log sesji w PostToolUse. Każde wywołanie narzędzia i jego wynik warto dopisywać do pliku JSONL przypisanego do sesji. Trzeba uwzględnić znacznik czasu, nazwę narzędzia, argumenty i kod wyjścia. Taki log umożliwia rekonstrukcję po zakończeniu sesji: co agent zrobił, w jakiej kolejności i czy coś zawiodło po cichu? Mój rejestrator sesji robi to w 22 liniach bash.²

Oto gotowy przykład hooka listy odmów w pliku settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

Skrypt hooka czyta wywołanie narzędzia ze standardowego wejścia, wyciąga ciąg polecenia i porównuje go ze wzorcami. Zablokowane polecenie zwraca obiekt JSON z {"decision": "block", "reason": "Sensitive path access denied"}. Dozwolone polecenie zwraca {"decision": "approve"}. Claude Code respektuje obie odpowiedzi bez dalszych pytań. Cały hook nie dokłada żadnego opóźnienia do poleceń dozwolonych (sprawdzenie wyrażeniem regularnym trwa poniżej 5 ms), a dla zablokowanych daje natychmiastową informację zwrotną.

Te trzy hooki zajmują łącznie mniej niż 100 linii. Nie zastępują dedykowanych narzędzi monitorujących. Zastępują zerową widoczność widocznością minimalną, a minimalna widoczność jest warunkiem wstępnym każdej późniejszej decyzji o nadzorze. Bez pomiaru nie da się ustalić budżetu zasobów. Bez listy odmów nie da się wyegzekwować zasad zakresu. Bez logu audytowego nie da się zbadać incydentu. Warto zacząć od logu. Pozostałe dwa przyjdą później.

Najważniejsze wnioski

Dla inżynierów platformowych: agenci zużywają zasoby, których dotychczasowy monitoring nie śledzi. Zużycie dysku, pamięci, CPU i sieci na sesję agenta należy do tego samego pulpitu co metryki kontenerów. Incydent z Cowork dowodzi tej potrzeby: 10 GB przydzielone bez żadnej widoczności dla operatora.

Dla zespołów bezpieczeństwa: egzekwowanie zasad na granicy wywołania narzędzia to minimalna sensowna postawa bezpieczeństwa wobec agentów. Scentralizowane podejście mcp-firewall skupia rozproszoną logikę zezwoleń i odmów w jednej, audytowalnej konfiguracji. Warto ocenić, czy wbudowane uprawnienia używanego agenta pokrywają przestrzeń zasad wymaganą przez dany model zagrożeń.

Dla menedżerów inżynierii: odpowiedzią długofalową jest samorządność agentów — agenci, którzy przyswajają monitoring jako normę zachowania, a nie tylko zewnętrzne ograniczenie. Zanim to dojrzeje, warto zadać trzy pytania o własne narzędzia agentowe. Czy widać zużycie zasobów w przeliczeniu na sesję? Czy można definiować i audytować zasady wywołań narzędzi? Czy da się po fakcie zrekonstruować, co zrobił agent? Jeśli którakolwiek odpowiedź brzmi „nie”, mamy do czynienia z luką widoczności, która rośnie z każdym kolejnym agentem w przepływie pracy.

Często zadawane pytania

Czym jest obserwowalność agentów?

Obserwowalność agentów to zdolność monitorowania i rozumienia tego, co agent AI robi w trakcie działania: jakie zasoby zużywa, jakie działania podejmuje i czy działania te są zgodne ze zdefiniowanymi zasadami.

Dlaczego Cowork od Anthropic utworzył maszynę wirtualną o rozmiarze 10 GB?

Funkcja Cowork w Claude Desktop udostępnia maszynę wirtualną na potrzeby wspólnych sesji programistycznych. Claude Desktop tworzy pakiet maszyny wirtualnej automatycznie przy każdej instalacji macOS, również u użytkowników, którzy nigdy nie włączają tej funkcji, i przechowuje go aż do ręcznego usunięcia.¹

Czym jest mcp-firewall?

mcp-firewall to narzędzie open source do egzekwowania zasad, które przechwytuje żądania użycia narzędzi od agentów wiersza poleceń (Claude Code, GitHub Copilot CLI) i ocenia je przed wykonaniem względem reguł zezwoleń i odmów opartych na wyrażeniach regularnych.⁷

Czym jest audyt w czasie działania oparty na eBPF?

eBPF (extended Berkeley Packet Filter) umożliwia śledzenie wywołań systemowych na poziomie jądra bez modyfikowania audytowanego procesu. Narzędzia takie jak Logira wykorzystują sondy eBPF do zapisywania wykonania procesów, operacji na plikach oraz połączeń sieciowych podczas przebiegów agentów AI.⁹

W jaki sposób agenci uruchamiają subagentów bez widoczności dla operatora?

Agenci delegujący zadania uruchamiają procesy podrzędne z czystymi oknami kontekstu. Agent nadrzędny widzi końcowe wyjście dziecka, ale nie jego pojedyncze wywołania narzędzi, odczyty plików ani zużycie zasobów. Przy każdym kroku delegowania informacja ulega kompresji: pełna sesja wnuka zamienia się w jednowierszowy status w logu rodzica. Obserwowalność degraduje się w tym samym tempie, w jakim rośnie głębokość delegowania.²

Czym monitoring agentów różni się od tradycyjnego APM?

Tradycyjne monitorowanie wydajności aplikacji (APM) śledzi opóźnienia żądań, wskaźniki błędów i przepustowość deterministycznego oprogramowania. Monitoring agentów śledzi zachowanie niedeterministyczne: co agent postanowił zrobić w czasie działania, czy decyzje te mieściły się w zasadach i jakie zasoby zużyła każda z nich. APM zakłada, że aplikacja podąża znaną ścieżką kodu. Monitoring agentów zakłada, że agent sam wybiera swoją ścieżkę.²

Czy hooki Claude Code mogą zapewnić obserwowalność agentów?

Tak. System hooków w Claude Code uruchamia skrypty przy zdarzeniach cyklu życia (PreToolUse, PostToolUse, Notification), które potrafią mierzyć zasoby, egzekwować zasady i rejestrować działania. Zestaw trzech hooków — tracker budżetu tokenów, lista odmów w PreToolUse oraz rejestrator sesji w PostToolUse — pokrywa wszystkie trzy warstwy widoczności w mniej niż 100 liniach bash. Hooki są najbardziej dostępnym punktem wejścia dla zespołów, które już korzystają z Claude Code.

Co się dzieje, gdy agenci omijają własną piaskownicę?

Ominięcie piaskownicy oznacza, że warstwa egzekwowania zawodzi po cichu. Agent działa dalej poza zamierzonym zakresem, a bez audytu w czasie działania nie pozostaje żaden ślad naruszenia. Udokumentowane w marcu 2026 roku techniki ucieczki z piaskownicy obejmują obejście przez ścieżkę, samodzielne wyłączenie piaskownicy oraz wywołanie dynamicznego linkera — wszystkie niewidoczne dla monitoringu na poziomie aplikacji.

Dlaczego obserwowalność narzędzi MCP jest ważna?

Każde wywołanie narzędzia MCP jest potencjalnym kanałem danych: może czytać pliki, wysyłać żądania sieciowe i wykonywać kod. Serwery MCP powiększają powierzchnię ataku, ponieważ każdy serwer wnosi nowe możliwości, które agent może wywołać w czasie działania. Bez rejestrowania każdego wywołania i bez egzekwowania zasad wywołania narzędzi MCP pozostają dla operatora niewidoczne.

Jak monitorować łańcuchy delegowania między wieloma agentami?

Każdy agent w łańcuchu delegowania potrzebuje własnego pomiaru zasobów, własnego egzekwowania zasad i własnego audytu w czasie działania. Autonomiczna pętla ralph dobrze pokazuje problem: rodzic uruchamia agentów podrzędnych, z których każdy dostaje czyste okno kontekstu. Rodzic widzi wyjście końcowe, a nie pojedyncze wywołania narzędzi. Obserwowalność degraduje się w tym samym tempie, w jakim rośnie głębokość delegowania, co wymusza niezależny monitoring na każdym kroku.

Źródła