Obrona w czasie wykonania dla agentów wyposażonych w narzędzia

Tydzień temu opublikowałem 50 podatności MCP obejmujących wzorce SSRF, zatruwania narzędzi i obchodzenia zaufania. Wniosek domyślny był ponury: powierzchnia ataku rośnie szybciej niż zdolności audytowe. Nowa praca Wei Zhao, Zhe Li, Peixin Zhang i Jun Sun proponuje odpowiedź strukturalną — a incydent telemetryczny z tego samego tygodnia dokładnie pokazuje, dlaczego ta odpowiedź ma znaczenie.

ClawGuard, opublikowany 13 kwietnia na arxiv, to framework bezpieczeństwa działający w czasie wykonania, który egzekwuje zestaw reguł potwierdzonych przez użytkownika na każdej granicy wywołania narzędzia.¹ W ewaluowanej konfiguracji framework stosuje podstawowe reguły kontroli dostępu — blokowanie nieautoryzowanego dostępu do plików, zapobieganie ekstrakcji poświadczeń, ograniczanie wywołań sieciowych — przed każdym wywołaniem zewnętrznego narzędzia. Bez modyfikacji modelu. Bez zmian infrastruktury. Bez fine-tuningu ukierunkowanego na bezpieczeństwo.¹ Autorzy przetestowali go na AgentDojo, SkillInject i MCPSafeBench, używając pięciu najnowocześniejszych LLM.¹ Praca opisuje również komponent indukcji reguł specyficznych dla zadania, który automatycznie wyprowadzałby ograniczenia z celu sformułowanego przez użytkownika, ale nie był on częścią ewaluowanej konfiguracji.

Kluczowe twierdzenie: ClawGuard przekształca obronę zależną od alignmentu w mechanizm deterministyczny i audytowalny.¹

Dlaczego alignment nie stanowi granicy bezpieczeństwa

Wiele podatności MCP, które skatalogowałem w zeszłym tygodniu, wykorzystuje wspólną lukę strukturalną. Agent otrzymuje instrukcje z opisu narzędzia, pobranej strony internetowej lub pliku umiejętności — a jedyną barierą między tą iniekcją a wykonaniem jest zdolność modelu do odróżnienia prawidłowych instrukcji od wrogich. (Niektóre podatności — SSRF, RCE, path traversal — wykorzystują błędy po stronie serwera, które nie zależą od podążania modelu za instrukcjami, ale granica wywołania narzędzia pozostaje istotna dla obrony.)

Trening alignmentu pomaga. RLHF sprawia, że modele częściej odmawiają realizacji szkodliwych żądań. Ale „częściej” nie jest właściwością bezpieczeństwa. Model, który odrzuca 99% iniekcji promptów, wciąż zawodzi w 1% przypadków, a atakujący kontrolujący dane wejściowe może iterować, aż trafi w ten 1%. Wzorzec zatruwania narzędzi nawet nie wymaga, by model zawiódł — zatruty opis sprawia, że złośliwa akcja wygląda jak zamierzona.

Przechwytywanie w czasie wykonania działa na zupełnie innej warstwie. Hook lub silnik polityk, który sprawdza wywołanie narzędzia przed wykonaniem, nie zależy od tego, czy model zrozumiał atak. Sprawdzenie jest deterministyczne: czy wywołanie pasuje do dozwolonego zbioru, czy nie?

Trzy kanały iniekcji, jeden punkt egzekwowania

ClawGuard identyfikuje trzy kanały ataku na agentów wyposażonych w narzędzia:¹

Iniekcja przez treści webowe i lokalne. Agent czyta stronę internetową lub plik lokalny zawierający wrogie instrukcje. Instrukcje kierują agenta do wywoływania narzędzi w sposób niezamierzony przez użytkownika. Powierzchnia ataku cichej ekstrakcji jest jednym z przykładów tego wzorca — instrukcje ekstrakcji ukryte w pobranej treści.

Iniekcja przez serwer MCP. Skompromitowany lub złośliwy serwer MCP osadza instrukcje w opisach narzędzi lub ładunkach odpowiedzi. Agent odczytuje te instrukcje jako kontekst i na ich podstawie działa. Katalog 50 podatności z zeszłego tygodnia dokumentuje ten kanał obszernie.

Iniekcja przez pliki umiejętności. Wrogie instrukcje umieszczone w plikach umiejętności i konfiguracji, które agent ładuje jako zaufany kontekst. Agent traktuje zawartość pliku umiejętności jako autorytatywną — atakujący, który może pisać do pliku umiejętności lub konfiguracji, może kierować zachowaniem agenta.

Architektura obrony umieszcza egzekwowanie na granicy wywołania narzędzia — jedynym punkcie, przez który musi przejść każda akcja zewnętrzna, niezależnie od kanału iniekcji.¹ Zanim agent wywoła jakiekolwiek narzędzie, ClawGuard sprawdza wywołanie względem ograniczeń wyprowadzonych z oryginalnego zadania użytkownika. Wywołanie wykraczające poza te ograniczenia zostaje zablokowane, bez względu na to, jak przekonujący był prompt iniekcji.

Warto jasno sformułować kluczową myśl architektoniczną: nie trzeba wykrywać każdej iniekcji, jeśli można egzekwować politykę na granicy wykonania.

Incydent telemetryczny Vercel

Cztery dni przed publikacją pracy ClawGuard, 9 kwietnia, Akshay Chugh opublikował ujawnienie dotyczące wtyczki Vercel dla Claude Code.² Ustalenia w momencie ujawnienia:

Wtyczka rejestrowała hooki, które wysyłały ciągi poleceń bash do telemetry.vercel.com.² Trwały UUID przechowywany w ~/.claude/vercel-plugin-device-id wiązał te ciągi poleceń z urządzeniem.² Wtyczka używała pustych matcherów w swoich hookach, co oznaczało, że hooki uruchamiały się dla wszystkich projektów — nie tylko projektów Vercel.² Mechanizm zgody używał iniekcji promptu zamiast natywnego UI do uzyskania zgody użytkownika.² Telemetria uruchamiała się przy każdym dopasowanym zdarzeniu, chyba że użytkownik ustawił VERCEL_PLUGIN_TELEMETRY=off.²

Vercel odniósł się do problemów z telemetrią 14 kwietnia, usuwając szerokie matchery i mechanizm zgody oparty na promptach.²

Incydent Vercel nie jest podatnością w tradycyjnym sensie. Nikt nie kradnie poświadczeń. Ale demonstruje dokładnie tę klasę problemów, którą adresuje obrona w czasie wykonania: hook uruchamiający się szerzej niż zamierzał użytkownik, zbierający dane, na których udostępnienie użytkownik nie wyraził jawnej zgody, za pomocą mechanizmu omijającego natywne UI zgody.

Wystarczy zastąpić „telemetrię” przez „ekstrakcję” — architektura jest identyczna. Hook z nadmiernie szerokim matcherem, działający we wszystkich projektach, wysyłający dane do zewnętrznego endpointu. Różnica między telemetrią a atakiem to intencja — a intencja nie podlega audytowi w czasie wykonania.

Od teorii do praktyki: co praktycy już mają

ClawGuard formalizuje coś, co praktycy budowali nieformalnie. Claude Code jest dostarczany z systemem hooków obsługującym przechwytywanie PreToolUse i PostToolUse. Prowadzę ponad 95 hooków, które egzekwują ograniczenia ścieżek plików, walidują dane wejściowe narzędzi i warunkują destrukcyjne operacje jawnym potwierdzeniem.³

Różnica między moimi hookami a wizją ClawGuard to automatyzacja. Moje hooki to ręcznie pisane reguły: blokuj wewnętrzne adresy IP w danych wejściowych MCP, ogranicz zapisy plików do katalogów projektu, wymagaj zatwierdzenia dla git force-push. Ewaluowana konfiguracja ClawGuard używa podstawowych reguł kontroli dostępu o podobnym duchu do ręcznie pisanych hooków. Proponowany w pracy komponent indukcji reguł specyficznych dla zadania automatycznie wyprowadzałby ograniczenia z celu sformułowanego przez użytkownika¹ — zamiast pisać „blokuj zapisy do /etc”, framework wnioskowałby, że zadanie opisane jako „refaktoryzuj moduł logowania” nie powinno wymagać dostępu do zapisu w katalogach systemowych. Ten komponent pozostaje przedmiotem przyszłych prac.

Automatyczne wyprowadzanie ograniczeń to trudniejszy problem — a komponent indukcji reguł specyficznych dla zadania w ClawGuard stanowi przyszłe prace, nie ewaluowane wyniki. Podstawowa konfiguracja reguł, którą autorzy faktycznie ewaluowali, wykazała silne, ale nie idealne rezultaty: AgentDojo osiągnął 0% współczynnika sukcesu ataku (ASR), ale SkillInject nadal wykazywał 4,8–14% ASR, a MCPSafeBench pokazał 7,1–11,0% ASR w zależności od modelu.¹ Ręcznie pisane reguły są kruche — pokrywają ataki, które przewidziano. Wyprowadzone ograniczenia mogłyby pokrywać ataki nieprzewidziane, ponieważ operują na zbiorze pozytywnym (co powinno się wydarzyć), a nie negatywnym (co nie powinno się wydarzyć).

Czy automatyczne wyprowadzanie działa niezawodnie w produkcji, pozostaje pytaniem otwartym. Benchmarki to kontrolowane środowiska. Rzeczywiste sesje agentów obejmują niejednoznaczne zadania, wieloetapowe łańcuchy narzędzi i wywołania narzędzi, które wyglądają anomalnie, ale są uzasadnione. Fałszywe alarmy blokujące prawidłowe wywołania narzędzi szybko podważyłyby twierdzenie o „zachowaniu użyteczności agenta”.

Warstwowy stos obrony

Obrona w czasie wykonania to nie pojedynczy mechanizm. Praktyczny stos dla agentów wyposażonych w narzędzia obejmuje co najmniej cztery warstwy:

Warstwa 1: Walidacja danych wejściowych. Hooki sprawdzające argumenty wywołań narzędzi przed wykonaniem. Blokowanie wewnętrznych adresów IP, walidacja ścieżek plików, odrzucanie metaznaków powłoki. Moje hooki PreToolUse działają na tej warstwie. Niski współczynnik fałszywych alarmów, ale wyłapuje tylko znane szkodliwe wzorce.

Warstwa 2: Ograniczenia w zakresie zadania. Ograniczenie zbioru dozwolonych narzędzi i dozwolonych argumentów do tego, czego wymaga bieżące zadanie. ClawGuard działa głównie na tej warstwie.¹ Większe pokrycie niż sama walidacja danych wejściowych, ale wymaga dokładnego zrozumienia zadania.

Warstwa 3: Inspekcja danych wyjściowych. Hooki PostToolUse badające wyniki narzędzi, zanim agent je przetworzy. Wyłapują ekstrakcję danych, wykrywają anomalne odpowiedzi, sygnalizują nieoczekiwane zachowanie narzędzi. Wpis o pośredniku dokumentował, dlaczego inspekcja danych wyjściowych ma znaczenie — skompromitowany router modyfikuje odpowiedzi po ich wygenerowaniu.

Warstwa 4: Audyt sesji. Logowanie każdego wywołania narzędzia, każdego argumentu, każdego wyniku do późniejszej analizy. Nie mechanizm zapobiegania, lecz wykrywania. Akshay Chugh odkrył incydent telemetryczny Vercel właśnie dzięki takiemu audytowi — czytając konfigurację hooków i śledząc ich działanie.²

Żadna pojedyncza warstwa nie jest wystarczająca. Walidacja danych wejściowych nie wyłapuje nowych wzorców. Ograniczenia w zakresie zadania mogą być zbyt restrykcyjne lub zbyt permisywne. Inspekcja danych wyjściowych dodaje opóźnienia. Audyt sesji wyłapuje problemy po fakcie. Stos działa, ponieważ każda warstwa pokrywa luki pozostawione przez pozostałe.

Co ClawGuard robi dobrze

Praca wnosi trzy istotne kontrybucje dla praktyków:

Determinizm ponad alignment. Ujęcie obrony w czasie wykonania jako mechanizmu deterministycznego, a nie właściwości alignmentu, to właściwe podejście. Alignment to właściwość czasu treningu, która degraduje w warunkach wrogich. Deterministyczne egzekwowanie to właściwość czasu wykonania, która utrzymuje się niezależnie od zachowania modelu. To rozróżnienie brzmi akademicko, ale zmienia to, co można obiecać w kwestii stanu bezpieczeństwa systemu.

Egzekwowanie niezależne od kanału. Obrona przed iniekcją webową, iniekcją MCP i iniekcją plików umiejętności za pomocą jednego punktu egzekwowania jest architektonicznie solidna. Trzy oddzielne mechanizmy obrony dla trzech kanałów iniekcji stworzyłyby obciążenie utrzymaniowe i pozostawiły luki na ich przecięciach. Jeden punkt egzekwowania na granicy wywołania narzędzia pokrywa wszystkie trzy kanały z samej konstrukcji.

Brak wymagań modyfikacji modelu. Brak wymogu fine-tuningu ani modyfikacji architektury oznacza, że obrona działa z dowolnym modelem, w tym modelami, nad którymi nie mamy kontroli. Operator używający Claude Code, Codex CLI lub dowolnego innego frameworku agentowego może dodać obronę w czasie wykonania bez czekania, aż dostawca modelu wyda aktualizację bezpieczeństwa.

Co pozostaje otwarte

ClawGuard testowano na benchmarkach. Produkcyjne sesje agentów są bardziej chaotyczne. Zanim praktycy będą mogli polegać na automatycznym wyprowadzaniu ograniczeń, pozostaje kilka pytań:

Niejednoznaczne zadania. „Pomóż mi z tym projektem” nie precyzuje, które narzędzia ani ścieżki są w zakresie. Wyprowadzanie ograniczeń z mglistych celów grozi albo blokowaniem prawidłowych wywołań (zbyt restrykcyjne), albo dopuszczaniem niebezpiecznych (zbyt permisywne).

Łańcuchy wieloetapowe. Agent, który musi odczytać plik konfiguracyjny, wywołać API i zapisać wyniki do bazy danych, ma złożony wzorzec dostępu. Ograniczenia wyprowadzone z początkowego opisu zadania mogą nie przewidzieć kroków pośrednich.

Wrogie opisy zadań. Jeśli wyprowadzanie ograniczeń zależy od sformułowanego celu użytkownika, atakujący kontrolujący opis zadania (poprzez współdzieloną przestrzeń roboczą, zatruty tracker zgłoszeń lub zmanipulowany plik projektu) może wpływać na same ograniczenia.

Koszt wydajnościowy. Ewaluacja ograniczeń na każdej granicy wywołania narzędzia dodaje opóźnienia. Praca twierdzi, że framework zachowuje użyteczność, ale nie podaje pomiarów opóźnień.¹ Przy interaktywnych sesjach agentów nawet 200ms na wywołanie narzędzia zmienia doświadczenie użytkownika.

Wnioski operacyjne

Dla praktyków prowadzących agentów wyposażonych w narzędzia:

Wdróż hooki PreToolUse teraz. Nie trzeba czekać na ClawGuard ani żaden inny framework. System hooków Claude Code obsługuje przechwytywanie wywołań narzędzi już teraz. Zacznij od walidacji danych wejściowych — blokuj wewnętrzne adresy, ogranicz ścieżki plików, warunkuj destrukcyjne operacje. Samouczek hooków opisuje implementację.

Przeprowadź audyt swoich matcherów hooków. Incydent Vercel wydarzył się, ponieważ puste matchery uruchamiały się we wszystkich projektach.² Przejrzyj każdy hook w swoim .claude/settings.json i zweryfikuj, że każdy matcher celuje tylko w zamierzony kontekst. Hook z nadmiernie szerokim matcherem to zagrożenie, nie obrona.

Loguj każde wywołanie narzędzia. Audyt sesji to warstwa obrony o najniższym nakładzie i najwyższej wartości. Nawet jeśli nie można zapobiec każdemu atakowi, można go wykryć po fakcie — ale tylko dysponując logami.

Ewaluuj ClawGuard względem własnego stosu. Kod pracy jest publicznie dostępny. Przetestuj konfigurację podstawowych reguł względem istniejącego stosu hooków. Jeśli komponent indukcji reguł specyficznych dla zadania dojrzeje, automatyczne wyprowadzanie ograniczeń uzupełni ręcznie pisane reguły, a nie je zastąpi.

Traktuj konfigurację jako granicę zaufania. Pliki umiejętności, konfiguracja hooków, definicje serwerów MCP — każdy plik wpływający na zachowanie agenta stanowi powierzchnię ataku. Stosuj te same mechanizmy kontroli dostępu, które stosowałbyś do poświadczeń produkcyjnych.

Katalog podatności MCP udokumentował powierzchnię ataku. ClawGuard proponuje architekturę obrony. Incydent Vercel pokazuje, dlaczego jedno i drugie ma znaczenie. Obrona w czasie wykonania na granicy wywołania narzędzia jest warstwą egzekwowalną — nie dlatego, że alignment nie pomaga, lecz dlatego, że egzekwowanie od niego nie zależy.

Źródła

Najczęściej zadawane pytania

Czym ClawGuard różni się od wbudowanego systemu uprawnień Claude Code?

System uprawnień Claude Code prosi o zgodę użytkownika na poziomie narzędzia — zatwierdzenie lub odrzucenie określonych kategorii narzędzi. ClawGuard działa na poziomie argumentów, automatycznie wyprowadzając ograniczenia dotyczące tego, jakie argumenty powinno zawierać wywołanie narzędzia na podstawie bieżącego zadania. Oba mechanizmy są komplementarne: uprawnienia kontrolują, które narzędzia mogą działać, a ograniczenia w czasie wykonania kontrolują, jak te narzędzia mogą być wywoływane.

Czy muszę czekać na wydanie ClawGuard, zanim dodam obronę w czasie wykonania?

Nie. System hooków Claude Code obsługuje przechwytywanie PreToolUse i PostToolUse już teraz. Ręcznie pisane hooki walidujące dane wejściowe narzędzi pokrywają najczęstsze wzorce ataków natychmiast. Wkładem ClawGuard jest automatyczne wyprowadzanie ograniczeń, które uzupełniłoby ręczne reguły, a nie je zastąpiło.

Czy incydent telemetryczny Vercel był podatnością bezpieczeństwa?

Ujawnienie opisywało problem prywatności i zgody, a nie tradycyjną podatność. W momencie ujawnienia wtyczka zbierała ciągi poleceń bash ze wszystkich projektów i wysyłała je do zewnętrznego endpointu bez jawnej zgody wyrażonej przez natywne UI. Vercel odniósł się od tego czasu do tych problemów. Wzorzec architektoniczny — szerokie matchery hooków, zewnętrzna transmisja danych, mechanizm zgody poza natywnym UI — pozostaje pouczający, ponieważ odzwierciedla ten sam wzorzec, który złośliwy hook wykorzystałby do ekstrakcji danych.

Jaki jest wpływ wydajnościowy przechwytywania wywołań narzędzi w czasie wykonania?

W przypadku ręcznie pisanych hooków korzystających ze skryptów powłoki lub lekkich walidatorów, narzut powinien utrzymywać się poniżej 200ms na wywołanie narzędzia, zgodnie z wytycznymi dokumentacji hooków. Praca o ClawGuard nie podaje pomiarów opóźnień dla ewaluacji ograniczeń, co może generować dodatkowy narzut. Przy interaktywnych sesjach opóźnienie na wywołanie narzędzia ma znaczenie — należy przeprowadzić testy przed wdrożeniem złożonej logiki walidacji.