Niewidoczny agent: Dlaczego nie można zarządzać tym, czego nie widać

Anthropic wprowadził funkcję o nazwie Cowork w Claude Desktop. Funkcja ta tworzyła pakiet maszyny wirtualnej o rozmiarze 10 GB 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 jej ponowne pojawienie się. Jeden z użytkowników zgłosił, że pakiet urósł do 21 GB. 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 wiedzy 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 to przykład niewidoczny. Zarządzanie agentami wymaga trzech warstw obserwowalności: pomiaru zasobów (co zostało zużyte?), egzekwowania polityk (co agent mógł robić?) i audytu czasu wykonania (co faktycznie zrobił?). 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, stos trzech warstw, co każda warstwa wychwytuje, oraz minimalne punkty monitorowania, 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 szczegółowości.

Systemy agentowe odwracają tę relację. Agent decyduje, co wykonać w czasie działania. Agent programistyczny, 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ł 10 GB miejsca na dysku, zużywał 24–55% CPU w stanie bezczynności i powodował wzrost aktywności swap z 20 tys. do ponad 24 tys. swapinów na maszynach z 8 GB RAM.¹ Użytkownicy odkryli zużycie zasobów dzięki ostrzeżeniom macOS o pojemności dysku, a nie dzięki telemetrii Anthropic. Aplikacja nie zapewniała żadnego panelu, żadnego miernika ani żadnej informacji o alokacji maszyny wirtualnej wymagającej zgody użytkownika.

Przenieśmy ten wzorzec na sesje agentów. Mój system orkiestracji hooków przechwytuje 15 typów zdarzeń przy 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 fantomowej weryfikacji ani pętli rekurencyjnego uruchamiania opisanych 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 programowanie wspomagane przez AI, łącząc obserwowalność z tym, „jak kodowanie i testowanie wspomagane przez AI wpływają na jakość, czas realizacji i ogólną niezawodność”.⁴ Obserwowalność agentów to nie opcjonalny dodatek. Pomiar zachowania agentów jest warunkiem koniecznym ich zarządzania.

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 zagraża pozostałym.

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 buduje na tej poniżej.

Warstwa 1: Pomiar zasobów

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

Incydent z Cowork to awaria pomiaru zasobów. Pakiet maszyny wirtualnej zajmował 10 GB dysku. Proces renderera zużywał 24% CPU w stanie bezczynności. Aktywność swap rosła stale podczas sesji. Wszystkie te metryki istniały w macOS Activity Monitor. Żadna nie pojawiała się w interfejsie Claude Desktop.¹

Dla sesji agentów programistycznych pomiar zasobów obejmuje cztery wymiary:

Dysk. Każdy zapis pliku, każdy wpis pamięci podręcznej, każdy plik logu. Moje sesje generują 200–400 KB plików stanu na sesję (jiro.state.json, jiro.progress.json, logi hooków). W ciągu 60 sesji kumuluje się to do 12–24 MB danych stanu, które przetrwają między sesjami, o ile nie zostaną jawnie usunięte.²

Pamięć. Zużycie okna kontekstu na turę. Okno kontekstu o rozmiarze 200 000 tokenów kosztuje około 3 USD za pełne wypełnienie przy obecnych 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 dodaje 200 ms na prompt. Ten narzut jest niewidoczny dla użytkowników (pisanie przez człowieka jest wąskim gardłem), ale kumuluje się w zautomatyzowanych pipeline’ach. Autonomiczna pętla ralph uruchamia dispatcher 50–100 razy na story, dodając 10–20 sekund narzutu hooków na story.²

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

Żadne komercyjne narzędzie agentowe nie zapewnia panelu zużycia zasobów na sesję. Dostawcy chmurowi mierzą obliczenia na potrzeby rozliczeń, nie na potrzeby widoczności operatora. Luka między tym, co agenci zużywają, a tym, co operatorzy mogą zobaczyć, to deficyt pomiaru zasobów.

Ta nieobecność wydaje się niewidoczna, dopóki liczby się nie skumulują. Jedna sesja zapisująca 400 KB plików stanu to nic. Sześćdziesiąt sesji zapisujących po 400 KB każda, bez czyszczenia, pozostawia 24 MB osieroconego stanu. Jedno pobranie strony zwracające 847 KB jest znikome. Pipeline skanujący pobierający 80 adresów URL na przebieg generuje 67 MB zbuforowanej treści, którą abstrakcja narzędziowa agenta ukrywa przed operatorem. Pomiar zasobów czyni skumulowane zużycie widocznym, zanim stanie się kryzysem, który skłania kogoś do zgłoszenia GitHub issue #22543.¹

Warstwa 2: Egzekwowanie polityk

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

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

Architektura odzwierciedla kluczową obserwację: każdy agent implementuje własne prowizoryczne rozwiązanie logiki zezwól/odmów. Claude Code używa wzorców glob. Codex CLI używa dopasowania tylko prefiksowego. 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 oddzielny skrypt powłoki z własnymi wzorcami regex. Gdy muszę dodać nową regułę odmowy, piszę nowy skrypt. Gdy muszę sprawdzić, jakie 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 ryzyka wymagają egzekwowania polityk na poziomie wywołania narzędzia. Agent, który przechwytuje cel, nadal wykonuje wywołania narzędzi. Agent z nadmiernymi uprawnieniami nadal żąda pozwoleń. 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ść na kontekst stanowi wyzwanie. Polecenie 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 agentów nie potrafią.

Warstwa 3: Audyt czasu wykonania

Audyt czasu wykonania 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ń) i połączenia sieciowe (ze śledzeniem celu). Każdy audytowany przebieg generuje trzy pliki: events.jsonl do przeglądu osi czasu, index.sqlite do filtrowalnych zapytań i meta.json z metadanymi przebiegu.

Filozofia projektowa 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 czasu wykonania odkrywa nieznane złe akcje po fakcie. Dwie warstwy pełnią różne funkcje temporalne: zapobieganie (przed) i kryminalistyka (po).

Sondy eBPF Logiry działają poniżej warstwy aplikacji. Agent, który konstruuje nowatorskie polecenie do 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. To podejście wychwytuje to, czego hooki na poziomie aplikacji nie widzą: efekty uboczne omijające abstrakcję wywołań narzędzi.

Wbudowane reguły detekcji są ukierunkowane specyficznie na 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 te stanowią opiniowane wartości domyślne dla modelu zagrożeń agentów, a nie generyczny audyt systemowy.

Ograniczenie platformowe ma znaczenie. Logira wymaga Linuxa 5.8+ z cgroup v2. Agenci na macOS (Claude Desktop, Claude Code na Darwin) nie mogą korzystać z audytu opartego na eBPF. Mój sandbox systemowy używa profili macOS Seatbelt jako najbliższego odpowiednika: wymuszanych na poziomie jądra reguł odmowy, które blokują zapisy do wrażliwych ścieżek.³ Seatbelt to egzekwowanie, a nie audyt. macOS nie posiada gotowego do produkcji odpowiednika śladu audytowego Logiry opartego na samej obserwacji.

Rozróżnienie między egzekwowaniem a audytem odpowiada podziałowi temporalnemu w reagowaniu na incydenty. Egzekwowanie zapobiega incydentowi. Audyt umożliwia rekonstrukcję po incydencie. Oba są konieczne. Warstwa egzekwowania, która blokuje cały dostęp do poświadczeń, zapobiega eksfiltracji, ale uniemożliwia również legalne operacje SSH. Warstwa audytu, która loguje cały dostęp do poświadczeń bez blokowania, umożliwia operatorowi przegląd wzorców dostępu i dostrajanie reguł egzekwowania na podstawie dowodów. Pętla zwrotna między danymi audytu a udoskonalaniem polityk jest sposobem, w jaki stos widoczności doskonali się z czasem: audyt ujawnia wzorce, wzorce informują polityki, polityki zmniejszają powierzchnię, którą audyt musi pokrywać.

Izolacja cgroup v2 w Logirze dodaje funkcję, której audyt na poziomie aplikacji nie jest w stanie odtworzyć: 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 śladzie audytu sesji B. Hooki na poziomie aplikacji nie mogą zapewnić takiej samej gwarancji, ponieważ uruchamiają się wewnątrz procesu agenta, który nie posiada granicy na poziomie jądra oddzielającej równoległe sesje.⁹

Co faktycznie uruchamiam

Mój system orkiestracji obejmuje 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ę wobec konfigurowalnych progów budżetowych.⁵ Monitor wydajności systemu sprawdza CPU, pamięć, dysk i swap w konfigurowalnych odstępach, 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 cosinusowe między embeddingiem oryginalnego promptu a ruchomym oknem ostatnich akcji.²

Egzekwowanie polityk. Osiem hooków dispatchera PreToolUse kieruje do handlerów 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. Zabezpieczenie przed rekurencją wymusza maksymalną głębokość dwóch poziomów i maksymalnie pięcioro dzieci na agenta nadrzędnego.²

Audyt czasu wykonania. 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ą każde ukończenie story, werdykt recenzenta i wynik bramy 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, o co agent poprosił, a nie co system operacyjny faktycznie wykonał. Agent, który konstruuje polecenie bash z osadzonymi podpowłokami, wykonuje kod, który hook widzi jako pojedynczy ciąg znaków. Audyt na poziomie jądra widziałby każdy podproces.

Kumulujący się martwy punkt

Agenci uruchamiający agentów mnożą nieprzejrzystość. Każdy skok delegacji wprowadza utratę informacji.

Gdy mój system orkiestracji uruchamia autonomiczną pętlę ralph, proces nadrzędny tworzy świeże instancje Claude Code dla każdego story PRD. Każdy agent podrzędny otrzymuje skoncentrowane zadanie i świeże okno kontekstu. Agent nadrzędny śledzi status 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 (nadrzędny uruchamia podrzędnego), nadrzędny widzi końcowe wyjście podrzędnego. Na głębokości dwa (podrzędny uruchamia wnuka), nadrzędny widzi raport podrzędnego o wyjściu wnuka. Każdy skok kompresuje informacje. 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ń (podrzędni dziedziczą uprawnienia bez rozumienia wrażliwości) i rozmycie odpowiedzialności (agent główny ponosi odpowiedzialność za wyniki, których nigdy nie sprawdził).³

Obserwowalność degraduje się w tym samym tempie. Trójwarstwowy stos widoczności na agencie głównym zapewnia zerową widoczność agenta-wnuka, chyba że każdy podrzędny niezależnie uruchamia własny monitoring. Moje zabezpieczenie przed rekurencją wymusza limit głębokości, ale zabezpieczenie to kontrola politykowa, a nie kontrola obserwowalności. Wiedza, że delegacja zatrzymała się na głębokości dwa, nie mówi, co się wydarzyło na głębokości dwa.

Konkretny przykład z mojego systemu produkcyjnego: pętla ralph uruchomiła agenta podrzędnego do implementacji story z migracją bazy danych. Agent podrzędny zdecydował, że migracja wymaga „kroku weryfikacyjnego” i uruchomił własnego podagenta do przeprowadzenia 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ł story jako ukończone. Agent nadrzędny zalogował „story 4: ukończone”. Odkryłem uszkodzoną migrację trzy godziny później, gdy aplikacja uległa awarii z powodu brakującej kolumny. Telemetria agenta głównego pokazywała czysty przebieg. Awaria znajdowała się dwa skoki głębiej, niewidoczna dla żadnej warstwy monitorowania wdrożonej na agencie głównym.²

Framework OWASP Agentic Applications adresuje awarie kaskadowe i zbuntowanych agentów, ale nie określa wymagań obserwowalności dla wieloagentowych łańcuchów delegacji.⁸ Luka jest strukturalna: każdy agent w łańcuchu potrzebowałby własnego pomiaru zasobów, egzekwowania polityk i audytu czasu wykonania, niezależnie skonfigurowanych i niezależnie raportowanych. Narzut jest multiplikatywny. Trzy warstwy monitorowania na trzech agentach w łańcuchu to dziewięć instancji monitorowania, 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, które pokrywają stos widoczności:

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

2. Polityka: Lista odmów PreToolUse. Stworzenie hooka uruchamianego przed każdym wywołaniem narzędzia Bash. Sprawdzanie polecenia wobec 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 przeszukuje plik wzorców za pomocą grep. 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.²

Przykład działania hooka listy odmów 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 wobec 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 dalszych zapytań. Cały hook dodaje zerowe opóźnienie do zatwierdzonych poleceń (sprawdzanie regex zajmuje poniżej 5 ms) i zapewnia natychmiastową informację zwrotną dla zablokowanych.

Te trzy hooki to łącznie mniej niż 100 linii kodu. Nie zastępują dedykowanych narzędzi monitorujących. Zastępują zerową widoczność minimalną widocznością. Minimalna widoczność jest warunkiem koniecznym dla każdej decyzji zarządczej, która po niej nastąpi. Nie można ustalić budżetu zasobów bez pomiaru. Nie można egzekwować polityki zakresu bez listy odmów. Nie można zbadać incydentu bez logu audytu. Zacznij od logu. Pozostałe dwa wynikną z niego.

Kluczowe wnioski

Dla inżynierów platformowych: Agenci 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: 10 GB zaalokowane przy zerowej widoczności operatora.

Dla zespołów bezpieczeństwa: Egzekwowanie polityk na granicy wywołania narzędzia to minimalna wystarczająca postawa bezpieczeństwa agenta. Scentralizowane podejście mcp-firewall konsoliduje logikę zezwól/odmów poszczególnych agentów w jednej audytowalnej konfiguracji. Należy ocenić, czy wbudowane uprawnienia agenta pokrywają przestrzeń polityk wymaganą przez model zagrożeń.

Dla menedżerów inżynierii: Trzy pytania dotyczące narzędzi agentowych: Czy można zobaczyć zużycie zasobów na sesję? Czy można definiować i audytować polityki wywołań narzędzi? Czy można zrekonstruować, co agent zrobił po fakcie? Jeśli którakolwiek odpowiedź brzmi „nie”, istnieje luka w widoczności, która rośnie z każdym dodatkowym agentem w przepływie pracy.

FAQ

Czym jest obserwowalność agentów? Obserwowalność agentów to zdolność monitorowania i rozumienia, co agent AI robi podczas wykonania: 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 10 GB? Funkcja Cowork w Claude Desktop udostępnia maszynę wirtualną do wspólnych 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 zachowuje go do 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 wobec reguł zezwól/odmów opartych na wyrażeniach regularnych przed wykonaniem.⁷

Czym jest audyt czasu wykonania 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 wykorzystują sondy eBPF do rejestrowania wykonania procesów, operacji na plikach i połączeń sieciowych podczas przebiegów agentów AI.⁹

Źródła