Niewidzialny agent: dlaczego nie można zarządzać tym, czego nie widać

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

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

TL;DR

Narzędzia agentów alokują teraz zasoby obliczeniowe (dysk, pamięć, CPU, sieć) bez wglądu operatora. Maszyna wirtualna Cowork od Anthropic to widoczny przykład; każde wywołanie narzędzia MCP, każdy uruchomiony podagent i każde pobranie strony internetowej to przykład niewidoczny. Zarządzanie agentami wymaga trzech warstw obserwowalności: pomiarów zasobów (co zostało zużyte?), egzekwowania polityk (co było dozwolone?) i audytu środowiska uruchomieniowego (co faktycznie zostało zrobione?). Dwa projekty open-source adresują warstwy polityk i audytu (mcp-firewall i Logira), ale żadne narzędzie produkcyjne nie obejmuje wszystkich trzech. Poniżej: problem widoczności, trójwarstwowy stos, co wykrywa każda warstwa oraz minimalne punkty zaczepienia monitoringu, które można wdrożyć już dziś.

Problem widoczności

Tradycyjne oprogramowanie działa poniżej linii obserwowalności, którą operatorzy sami wyznaczają. Serwer WWW zapisuje logi dostępu, ponieważ inżynierowie skonfigurowali logowanie. Baza danych śledzi wolne zapytania, ponieważ ktoś ustawił log_min_duration_statement. Operator decyduje o poziomie szczegółowości.

Systemy agentów odwracają tę zależność. Agent sam decyduje, co wykonać w czasie działania. Agent kodujący, który otrzymuje polecenie „napraw endpoint logowania”, może przeczytać 47 plików, zapisać 12, uruchomić trzech podagentów, pobrać dwie strony internetowe i wykonać 15 poleceń bash. Każda akcja zużywa zasoby. Żadne z tych zużyć nie pojawia się w tradycyjnym monitoringu.

Incydent z Cowork ujawnił to odwrócenie na poziomie infrastruktury. Claude Desktop zaalokował 10GB przestrzeni dyskowej, zużywał 24-55% CPU na biegu jałowym i zwiększał aktywność swap z 20K do ponad 24K swapinów na maszynach z 8GB RAM.¹ Użytkownicy odkryli zużycie zasobów dzięki ostrzeżeniom macOS o przestrzeni dyskowej, a nie dzięki telemetrii Anthropic. Aplikacja nie udostępniała żadnego panelu, żadnego miernika ani żadnego ujawnienia alokacji maszyny wirtualnej wymagającego zgody.

Wzorzec nie jest hipotetyczny. W marcu 2026 roku pewien programista zgłosił, że Claude Code wykonał polecenie Terraform, które zniszczyło produkcyjną bazę danych. Agent uruchomił terraform apply na pliku stanu produkcyjnego. Nie pojawił się żaden monit o potwierdzenie. Żaden hook nie przechwycił polecenia. Programista odkrył zniszczenie, 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łą konfigurację produkcyjną, w tym migawki bazy danych reprezentujące 2,5 roku zapisów.¹³ Oba incydenty mają tę samą przyczynę: zerowy wgląd w to, co agent robił, zanim szkody stały się nieodwracalne.

Skalujmy ten wzorzec do sesji agentów. Mój system orkiestracji hooków przechwytuje 15 typów zdarzeń w każdym wywołaniu narzędzia.¹¹ W ciągu 60 sesji system zarejestrował 84 hooki uruchamiane przy każdej akcji, generując telemetrię, której żadna domyślna instalacja agenta nie zapewnia.² Bez tej instrumentacji nie wykryłbym 12 incydentów dryfu, awarii weryfikacji fantomowej ani pętli rekurencyjnego rozmnażania udokumentowanych w moim komentarzu publicznym do NIST.³

Raport DORA 2024 Accelerate State of DevOps wykazał, że zespoły ze silnymi praktykami obserwowalności wdrażają częściej i szybciej odzyskują sprawność po awariach. Edycja 2025 rozszerza ramy na rozwój wspomagany AI, łącząc obserwowalność z tym, „jak kodowanie lub testowanie wspomagane AI wpływa na jakość, czas realizacji i ogólną niezawodność”.⁴ Obserwowalność agentów nie jest opcjonalnym dodatkiem. Mierzenie zachowania agentów jest warunkiem koniecznym zarządzania nimi.

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 kompromituje pozostałych.

Warstwy tworzą progresję: nie można egzekwować polityk wobec zasobów, których się nie mierzy, i nie można audytować zgodności z politykami, których nigdy nie zdefiniowano. Każda warstwa bazuje na tej poniżej.

Warstwa 1: Pomiary zasobów

Pomiary zasobów odpowiadają na pytanie: ile agent zużył i gdzie?

Incydent z Cowork to awaria pomiarów zasobów. Pakiet maszyny wirtualnej zajmował 10GB przestrzeni dyskowej. Proces renderowania zużywał 24% CPU na biegu jałowym. Aktywność swap stale rosła podczas sesji. Wszystkie te metryki istniały w macOS Activity Monitor. Żadna nie pojawiła się w interfejsie Claude Desktop.¹

Dla sesji agentów kodujących pomiary zasobów śledzą cztery wymiary:

Dysk. Każdy zapis pliku, każdy wpis cache, każdy plik logów. Moje sesje generują 200-400KB plików stanu na sesję (jiro.state.json, jiro.progress.json, logi hooków). W ciągu 60 sesji gromadzi się to do 12-24MB danych stanu, które utrzymują się między sesjami, chyba że zostaną jawnie wyczyszczone.²

Pamięć. Zużycie okna kontekstowego na turę. Okno kontekstowe o rozmiarze 200 000 tokenów kosztuje około 3 dolarów za pełne wypełnienie przy bieżących cenach Opus. Mój moduł śledzenia 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 dziewięciohookowy dispatcher promptów dodaje 200ms na prompt. Ten narzut jest niewidoczny dla użytkowników (wąskim gardłem jest pisanie na klawiaturze), ale kumuluje się w zautomatyzowanych pipeline’ach. Pętla autonomiczna ralph uruchamia dispatcher 50-100 razy na historię, dodając 10-20 sekund narzutu hooków na historię.²

Sieć. Pobrania stron, wywołania API, wywołania narzędzi MCP. Każde żądanie wychodzące to potencjalny kanał danych. Moja biblioteka do ekstrakcji treści z sieci loguje adresy URL pobrań i rozmiary odpowiedzi. Bez pomiarów sieci pobranie zwracające odpowiedź o rozmiarze 50MB jest nie do odróżnienia od tego zwracającego 5KB.⁶

Żadne komercyjne narzędzie agentowe nie udostępnia panelu zasobów na sesję. Dostawcy usług chmurowych mierzą obliczenia do celów rozliczeniowych, a nie dla widoczności operatora. Luka między tym, co agenty zużywają, a tym, co operatorzy mogą zobaczyć, to deficyt pomiarów zasobów.

Ta nieobecność jest niewidoczna, dopóki liczby się nie nagromadzą. Jedna sesja zapisująca 400KB plików stanu to nic. Sześćdziesiąt sesji zapisujących po 400KB, bez czyszczenia, pozostawia 24MB osieroconego stanu. Jedno pobranie zwracające 847KB jest pomijalne. Pipeline skanujący pobierający 80 adresów URL na uruchomienie generuje 67MB cache’owanej treści, którą abstrakcja narzędziowa agenta ukrywa przed operatorem. Pomiary zasobów czynią to skumulowane widocznym, zanim stanie się kryzysem skłaniającym kogoś do złożenia zgłoszenia GitHub #22543.¹

Warstwa 2: Egzekwowanie polityk

Egzekwowanie polityk odpowiada na pytanie: jakie reguły ograniczają agenta i czy są stosowane konsekwentnie?

mcp-firewall adresuje warstwę polityk dla agentów CLI.⁷ Narzędzie umieszcza się między agentem a wszystkimi żądaniami użycia narzędzi, oceniając każde żądanie według polityki opartej na wyrażeniach regularnych przed wykonaniem. Polityki używają plików konfiguracyjnych JSONNet, zakresowanych według folderu, repozytorium git lub użytkownika. Firewall obsługuje Claude Code i GitHub Copilot CLI poprzez integrację z hookiem PreToolUse.

Architektura odzwierciedla kluczowe spostrzeżenie: każdy agent implementuje własne połowiczne rozwiązanie logiki zezwól/odmów. Claude Code używa wzorców glob. Codex CLI używa dopasowywania tylko prefiksów. Każde podejście obejmuje podzbiór przestrzeni polityk. mcp-firewall centralizuje reguły w jednym silniku działającym między agentami.

Rozważmy lukę w politykach bez 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 i polecenia wdrożeniowe.² Każdy handler to osobny skrypt powłoki z własnymi wzorcami regex. Gdy muszę dodać nową regułę odmowy, piszę nowy skrypt. Gdy muszę audytować, które reguły istnieją, przeszukuję 12 plików za pomocą grep. mcp-firewall konsoliduje to w jednym pliku konfiguracyjnym z jawnymi tablicami zezwoleń.

OWASP Top 10 for Agentic Applications (2025) identyfikuje Agent Goal Hijacking (ASI01) i Excessive Agency (LLM06:2025) jako główne ryzyka.⁸ Oba wymagają egzekwowania polityk na poziomie wywołań narzędzi. Agent, którego cel został przejęty, nadal wykonuje wywołania narzędzi. Agent z nadmiernymi uprawnieniami nadal żąda uprawnień. Egzekwowanie polityk przechwytuje oba na granicy, gdzie intencja agenta spotyka się z narzędziami systemu.

Egzekwowanie polityk różni się od kontroli dostępu. Tradycyjna kontrola dostępu pyta: „czy ten użytkownik ma uprawnienia?” Egzekwowanie polityk dla agentów pyta: „czy ta akcja, w tym kontekście, dla tego zadania, mieści się w zatwierdzonym zakresie?” Wrażliwość kontekstowa stanowi wyzwanie. git push do gałęzi funkcyjnej i git push --force do main to to samo narzędzie (Bash) z różnym promieniem rażenia. Wzorce regex mcp-firewall potrafią je rozróżnić. Domyślne uprawnienia agenta nie.

Egzekwowanie polityk na poziomie aplikacji wiąże się również z ryzykiem obejścia. Analiza z marca 2026 udokumentowała trzy eskalujące techniki ucieczki z sandboxa wobec wbudowanej listy blokad Claude Code: obejście ścieżek (/proc/self/root/usr/bin/npx rozwiązuje się do tego samego pliku binarnego co zablokowany /usr/bin/npx), samodzielne wyłączenie sandboxa (agent niezależnie wyrozumował usunięcie sandboxa, gdy blokował on ukończenie zadania) oraz wywołanie dynamicznego linkera (ld-linux-x86-64.so.2 ładuje pliki binarne przez mapowanie pamięci, omijając hooki egzekwowania na poziomie jądra).¹⁴ Trzecia technika to klasa eksploitów: każde ładowanie kodu omijające execve omija egzekwowanie na poziomie procesu. Wniosek dla egzekwowania polityk jest taki, że listy blokad oparte na dopasowywaniu ciągów to konieczna pierwsza warstwa, ale niewystarczająca. Egzekwowanie oparte na adresowaniu zawartości (identyfikacja plików binarnych po hashu SHA-256 zamiast nazwy pliku) zamyka lukę obejścia ścieżek, ale obejście dynamicznego linkera wymaga kontroli na poziomie jądra, które znajdują się poniżej warstwy polityk.

Warstwa 3: Audyt środowiska uruchomieniowego

Audyt środowiska uruchomieniowego odpowiada na pytanie: co agent faktycznie zrobił na poziomie wywołań systemowych?

Logira adresuje warstwę audytu za pomocą sond eBPF przechwytujących wywołania systemowe 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 poświadczeń) 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 za pomocą zapytań i meta.json z metadanymi przebiegu.

Filozofia projektowania to „tylko obserwacja”: Logira rejestruje i wykrywa, ale nie egzekwuje ani nie blokuje.⁹ Oddzielenie od warstwy egzekwowania jest celowe. Egzekwowanie polityk zapobiega znanym złym akcjom. Audyt środowiska uruchomieniowego odkrywa nieznane złe akcje po fakcie. Obie warstwy pełnią różne funkcje czasowe: prewencja (przed) i forensyka (po).

Sondy eBPF Logiry działają poniżej warstwy aplikacji. Agent konstruujący nowatorskie polecenie w celu eksfiltracji danych nadal wykonuje wywołania systemowe. Agent nie może ukryć odczytów plików, połączeń sieciowych ani uruchomień procesów przed śledzeniem na poziomie jądra. Podejście to wychwytuje to, co hooki na poziomie aplikacji pomijają: efekty uboczne omijające abstrakcję wywołań narzędzi.

Wbudowane reguły detekcji celują konkretnie w ryzyka agentów AI: dostęp do plików poświadczeń, zmiany mechanizmów persystencji (/etc, systemd, cron), podejrzane łańcuchy poleceń (wzorce curl-pipe-sh), operacje destrukcyjne (rm -rf) oraz anomalny ruch sieciowy wychodzący.⁹ Reguły to opiniowane wartości domyślne dla modelu zagrożeń agentów, a nie generyczny audyt systemu.

Ograniczenie platformowe ma znaczenie. Logira wymaga Linuxa 5.8+ z cgroup v2. Agenty na macOS (Claude Desktop, Claude Code na Darwinie) nie mogą korzystać z audytu opartego na eBPF. Mój sandbox na poziomie systemu operacyjnego używa profili macOS Seatbelt jako najbliższego odpowiednika: reguł odmowy egzekwowanych przez jądro, które blokują zapisy do wrażliwych ścieżek.³ Seatbelt to egzekwowanie, nie audyt. macOS nie posiada gotowego produkcyjnie odpowiednika ścieżki audytu Logiry w trybie wyłącznie obserwacyjnym.

Agent Safehouse, natywne narzędzie sandboxingu dla macOS, które zebrało 802 punkty i 181 komentarzy na Hacker News w marcu 2026, adresuje lukę platformową od strony egzekwowania.¹⁵ Narzędzie zapewnia profile sandboxa zaprojektowane specjalnie dla lokalnych agentów AI na macOS. Reakcja społeczności (802 punkty to wyjątkowy wynik dla narzędzia sandboxingowego) odzwierciedla pilność: praktycy uruchamiający agentów na macOS mają ograniczone opcje między „brakiem sandboxa” a „napisz własny profil Seatbelt”. Agent Safehouse wypełnia tę lukę w zakresie egzekwowania. Luka audytowa na macOS pozostaje otwarta.

Rozróżnienie między egzekwowaniem a audytem mapuje się na podział czasowy w reagowaniu na incydenty. Egzekwowanie zapobiega incydentowi. Audyt umożliwia rekonstrukcję po incydencie. Oba są konieczne. Warstwa egzekwowania blokująca cały dostęp do poświadczeń zapobiega eksfiltracji, ale uniemożliwia także legalne operacje SSH. Warstwa audytu logująca cały dostęp do poświadczeń bez blokowania umożliwia operatorowi przegląd wzorców dostępu i dostrojenie reguł egzekwowania na podstawie dowodów. Pętla zwrotna między danymi audytu a udoskonalaniem polityk to sposób, w jaki stos widoczności ulepsza się z czasem: audyt ujawnia wzorce, wzorce kształtują polityki, polityki zmniejszają powierzchnię, którą audyt musi pokryć.

Izolacja cgroup v2 w Logirze dodaje funkcję, której audyt na poziomie aplikacji nie może replikować: atrybucję w zakresie przebiegu. System przypisuje każde zdarzenie do konkretnego audytowanego przebiegu, a nie do systemu globalnie. Gdy dwie sesje agentów działają równocześnie na tej samej maszynie, izolacja cgroup zapewnia, że dostęp do plików w sesji A nie pojawia się w ścieżce audytu sesji B. Hooki na poziomie aplikacji nie mogą zapewnić tej samej gwarancji, ponieważ uruchamiają się wewnątrz procesu agenta, który nie ma granicy na poziomie jądra oddzielającej równoczesne sesje.⁹

Co faktycznie uruchamiam

Mój system orkiestracji obejmuje wszystkie trzy warstwy poprzez hooki, a nie dedykowane narzędzia monitorujące.

Pomiary zasobów. Hook bramki kosztowej ś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 interwałach, wstrzykując ostrzeżenia, gdy obciążenie zasobów przekracza progi.¹⁰ Detektor dryfu sesji uruchamia się co 25 wywołań narzędzi, obliczając podobieństwo kosinusowe między embeddingiem oryginalnego promptu a przesuwnym oknem ostatnich akcji.²

Egzekwowanie polityk. Osiem hooków dispatchera PreToolUse kieruje do hooków obsługi według typu narzędzia. Sam PreToolUse:Bash uruchamia 12 handlerów obejmujących wzorce poświadczeń, destrukcyjne operacje git, dostęp do wrażliwych ścieżek i polecenia wdrożeniowe. Strażnik rekurencji egzekwuje maksymalną głębokość dwóch i maksymalnie pięciu dzieci na agenta nadrzędnego.²

Audyt środowiska uruchomieniowego. Hooki PostToolUse logują wynik każdego wywołania narzędzia. Hooki skanowania bezpieczeństwa sprawdzają wyjście bash pod kątem wycieków poświadczeń po wykonaniu. Pliki stanu sesji (jiro.state.json) rejestrują ukończenie każdej historii, werdykt recenzenta i wynik bramki dowodowej.² System nie używa eBPF (ograniczenie macOS), ale przechwytuje telemetrię na poziomie narzędzi przez pipeline hooków.

System działa, ponieważ każda akcja przechodzi przez pipeline 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 konstruujący polecenie bash z osadzonymi podpowłokami wykonuje kod, który hook widzi jako pojedynczy ciąg. Audyt na poziomie jądra zobaczyłby każdy podproces.

Konkretne wyniki z incydentów produkcyjnych, w których trójwarstwowy stos wykrył awarie, które domyślny monitoring by przeoczył:

Kumulujący się martwy punkt

Agenty uruchamiające agentów multiplikują brak przejrzystości. Każdy skok delegacji wprowadza utratę informacji.

Gdy mój system orkiestracji uruchamia pętlę autonomiczną ralph, proces nadrzędny uruchamia świeże instancje Claude Code dla każdej historii PRD. Każdy agent podrzędny otrzymuje skoncentrowane zadanie i świeże okno kontekstowe. Agent nadrzędny śledzi stan ukończenia. Agent nadrzędny nie widzi indywidualnych wywołań narzędzi, odczytów plików ani zużycia zasobów agenta podrzędnego.²

Na głębokości jeden (rodzic uruchamia dziecko) rodzic widzi końcowe wyjście dziecka. Na głębokości dwa (dziecko uruchamia wnuka) rodzic widzi raport dziecka o wyjściu wnuka. Każdy skok kompresuje informację. Analiza łańcucha delegacji w moim komentarzu do NIST zmierzyła trzy kumulujące się ryzyka: kompresję semantyczną (kontekst redukuje się do ciągu promptu), amplifikację uprawnień (dzieci dziedziczą uprawnienia bez zrozumienia wrażliwości) oraz dyfuzję odpowiedzialności (agent główny ponosi odpowiedzialność za wyniki, których nigdy nie zweryfikował).³

Obserwowalność degraduje się w tym samym tempie. Trójwarstwowy stos widoczności na agencie głównym zapewnia zerowy wgląd w agenta-wnuka, chyba że każde dziecko niezależnie uruchamia własny monitoring. Mój strażnik rekurencji egzekwuje limit głębokości, ale jest to kontrola polityk, nie kontrola obserwowalności. Wiedza, że delegacja zatrzymała się na głębokości dwa, nie mówi, co się działo na głębokości dwa.

Konkretny przykład z mojego systemu produkcyjnego: pętla ralph uruchomiła agenta podrzędnego do implementacji historii migracji bazy danych. Agent podrzędny zdecydował, że migracja potrzebuje „kroku weryfikacji” i uruchomił własnego podagenta do uruchomienia testów integracyjnych. Agent-wnuk zawiódł cicho (testowa baza danych nie była skonfigurowana). Agent podrzędny otrzymał pustą odpowiedź, zinterpretował ciszę jako sukces i zgłosił historię jako ukończoną. Agent nadrzędny zalogował „historia 4: ukończona”. Odkryłem uszkodzoną migrację trzy godziny później, gdy aplikacja padła z powodu brakującej kolumny. Telemetria agenta głównego pokazywała czysty przebieg. Awaria kryła się dwa skoki głębiej, niewidoczna dla każdej warstwy monitoringu, którą wdrożyłem na agencie głównym.²

Framework OWASP Agentic Applications adresuje kaskadowe awarie i zbuntowanych agentów, ale nie precyzuje wymagań obserwowalności dla wieloagentowych łańcuchów delegacji.⁸ Luka jest strukturalna: każdy agent w łańcuchu potrzebowałby własnych pomiarów zasobów, egzekwowania polityk i audytu środowiska uruchomieniowego, niezależnie skonfigurowanych i niezależnie raportowanych. Narzut jest multiplikatywny. Trzy warstwy monitoringu na trzech agentach w łańcuchu to dziewięć instancji monitoringu, każda generująca własną telemetrię, każda wymagająca własnej konfiguracji. Żadne istniejące narzędzie nie zarządza tą koordynacją.

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

Trzy minimalne hooki monitorujące obejmujące stos widoczności:

1. Zasoby: monitor budżetu tokenów. Logowanie skumulowanych tokenów wejściowych i wyjściowych na sesję. Ustawienie twardego limitu. Alert przy 80%. Implementacja wymaga odczytu statystyk użycia agenta (Claude Code udostępnia koszty sesji przez /cost) i porównania z progiem. Mój hook bramki kosztowej realizuje to w 47 liniach bash.⁵

2. Polityka: lista blokad PreToolUse. Utworzenie hooka uruchamianego przed każdym wywołaniem narzędzia Bash. Sprawdzanie polecenia względem listy wzorców: rm -rf /, git push --force, ścieżki zawierające .ssh lub .env, curl | sh. Blokowanie dopasowań. Implementacja wymaga jednego skryptu powłoki, który czyta stdin (wywołanie narzędzia w formacie JSON), wyodrębnia pole polecenia i sprawdza je za pomocą grep względem pliku wzorców. Mój hook sprawdzania poświadczeń realizuje to w 31 liniach.²

3. Audyt: log sesji PostToolUse. Dopisywanie każdego wywołania narzędzia i wyniku do pliku JSONL specyficznego dla sesji. Uwzględnienie znacznika czasu, nazwy narzędzia, argumentów i kodu wyjścia. Log umożliwia rekonstrukcję po sesji: co agent zrobił, w jakiej kolejności i czy coś zawiodło cicho? Mój logger sesji realizuje to w 22 liniach bash.²

Działający przykład hooka listy blokad w settings.json:

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

Skrypt hooka odczytuje wywołanie narzędzia ze stdin, wyodrębnia ciąg polecenia i sprawdza go względem wzorców. Zablokowane polecenie zwraca obiekt JSON z {"decision": "block", "reason": "Sensitive path access denied"}. Dozwolone polecenie zwraca {"decision": "approve"}. Claude Code respektuje obie odpowiedzi bez dalszego pytania. Cały hook dodaje zero opóźnienia do zatwierdzonych poleceń (sprawdzanie regex trwa poniżej 5ms) i zapewnia natychmiastową informację zwrotną dla zablokowanych.

Te trzy hooki zajmują łącznie mniej niż 100 linii. Nie zastępują dedykowanych narzędzi monitorujących. Zastępują zerowy wgląd minimalnym wglądem. Minimalny wgląd jest warunkiem koniecznym każdej kolejnej decyzji zarządczej. Nie można ustalić budżetu zasobów bez pomiarów. Nie można egzekwować polityki zakresu bez listy blokad. Nie można zbadać incydentu bez logu audytu. Zacznij od logu. Pozostałe dwa z niego wynikają.

Kluczowe wnioski

Dla inżynierów platform: Agenty zużywają zasoby, których istniejący monitoring nie śledzi. Zużycie dysku, pamięci, CPU i sieci na sesję agenta powinno znajdować się na tym samym panelu co metryki kontenerów. Incydent z Cowork dowodzi potrzeby: 10GB zaalokowane przy zerowym wglądzie operatora.

Dla zespołów bezpieczeństwa: Egzekwowanie polityk na granicy wywołań narzędzi to minimalna żywotna postura bezpieczeństwa agentów. Scentralizowane podejście mcp-firewall konsoliduje logikę zezwól/odmów poszczególnych agentów w jedną audytowalną konfigurację. Należy ocenić, czy wbudowane uprawnienia agenta pokrywają przestrzeń polityk wymaganą przez model zagrożeń.

Dla menedżerów inżynierii: Zadaj trzy pytania o swoje narzędzia agentowe: Czy widzisz zużycie zasobów na sesję? Czy możesz definiować i audytować polityki wywołań narzędzi? Czy możesz zrekonstruować, co agent zrobił po fakcie? Jeśli którakolwiek odpowiedź brzmi „nie”, masz lukę w widoczności, która rośnie z każdym kolejnym agentem w przepływie pracy.

FAQ

Czym jest obserwowalność agentów? Obserwowalność agentów to zdolność monitorowania i rozumienia tego, co agent AI robi podczas wykonywania: jakie zasoby zużywa, jakie akcje podejmuje i czy te akcje są zgodne ze zdefiniowanymi politykami.

Dlaczego Cowork od Anthropic utworzył maszynę wirtualną o rozmiarze 10GB? Funkcja Cowork w Claude Desktop tworzy maszynę wirtualną dla współpracujących sesji programistycznych. Claude Desktop tworzy pakiet maszyny wirtualnej automatycznie na każdej instalacji macOS, nawet dla użytkowników, którzy nigdy nie włączają tej funkcji, i utrzymuje go do momentu ręcznego usunięcia.¹

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

Czym jest audyt środowiska uruchomieniowego oparty na eBPF? eBPF (extended Berkeley Packet Filter) umożliwia śledzenie wywołań systemowych na poziomie jądra bez modyfikacji audytowanego procesu. Narzędzia takie jak Logira używają sond eBPF do rejestrowania wykonywania procesów, operacji na plikach i połączeń sieciowych podczas przebiegów agentów AI.⁹

Jak agenty uruchamiają podagentów bez wglądu operatora? Agenty delegujące zadania uruchamiają procesy podrzędne z nowymi oknami kontekstowymi. Agent nadrzędny widzi końcowe wyjście agenta podrzędnego, ale nie jego indywidualne wywołania narzędzi, odczyty plików ani zużycie zasobów. Przy każdym skoku delegacji informacja ulega kompresji: pełna sesja wnuka staje się jednoliniowym statusem w logu rodzica. Obserwowalność degraduje się w tym samym tempie, co wzrasta głębokość delegacji.²

Czym monitoring agentów różni się od tradycyjnego APM? Tradycyjny Application Performance Monitoring (APM) śledzi opóźnienia żądań, wskaźniki błędów i przepustowość dla deterministycznego oprogramowania. Monitoring agentów śledzi niedeterministyczne zachowanie: co agent zdecydował się zrobić w czasie działania, czy te decyzje mieściły się w politykach i jakie zasoby zużyła każda decyzja. APM zakłada, że aplikacja podąża znaną ścieżką kodu. Monitoring agentów zakłada, że agent sam wybiera swoją ścieżkę.²

Źródła