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

Tydzień temu opublikowałem 50 podatności MCP obejmujących SSRF, zatruwanie narzędzi i obchodzenie mechanizmów zaufania. Domniemany wniosek był ponury: powierzchnia ataku rośnie szybciej niż zdolność audytowa. Nowa praca Wei Zhao, Zhe Li, Peixina Zhanga i Jun Suna proponuje strukturalną odpowiedź, a rzeczywisty incydent telemetryczny z tego samego tygodnia pokazuje dokładnie, dlaczego ta odpowiedź ma znaczenie.

ClawGuard, opublikowany 13 kwietnia na arxiv, to framework bezpieczeństwa działający w czasie wykonania, który wymusza zestaw reguł potwierdzony przez użytkownika na każdej granicy wywołania narzędzia.¹ W ocenianej konfiguracji framework stosuje podstawowe reguły kontroli dostępu (blokowanie nieautoryzowanego dostępu do plików, zapobieganie eksfiltracji poświadczeń, ograniczanie wywołań sieciowych) przed każdym zewnętrznym wywołaniem narzędzia. Bez modyfikacji modelu. Bez zmiany infrastruktury. Bez fine-tuningu pod kątem bezpieczeństwa.¹ Autorzy przetestowali framework na AgentDojo, SkillInject i MCPSafeBench, używając pięciu czołowych LLM.¹ Praca opisuje również komponent indukcji reguł specyficznych dla zadania, który automatycznie wyprowadzałby ograniczenia z celu podanego przez użytkownika, ale autorzy nie uwzględnili go w ocenianej konfiguracji.

Twierdzenie, które ma znaczenie: ClawGuard przekształca obronę zależną od alignmentu w deterministyczny, auditowalny mechanizm.¹

Dlaczego alignment nie jest granicą 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ą rzeczą stojącą między tą iniekcją a wykonaniem jest zdolność modelu do odróżnienia prawidłowych instrukcji od wrogich. (Niektóre podatności, w tym SSRF, RCE i path traversal, wykorzystują luki po stronie serwera, które w ogóle nie zależą od wykonywania instrukcji przez model, ale granica wywołania narzędzia pozostaje istotna dla obrony.)

Trening alignmentu pomaga. RLHF sprawia, że modele chętniej odmawiają szkodliwych żądań. Ale „chętniej” nie jest właściwością bezpieczeństwa. Model, który odmawia 99% prób prompt injection, wciąż zawodzi w 1% przypadków, a atakujący kontrolujący dane wejściowe może iterować, aż trafi w to 1%. Wzorzec zatruwania narzędzi nie wymaga nawet, aby 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 zestawu, czy nie?

Trzy kanały iniekcji, jeden punkt wymuszania

ClawGuard identyfikuje trzy kanały ataku dla 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 eksfiltracji jest jednym z przykładów tego wzorca — instrukcje eksfiltracji 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 działa na ich podstawie. Katalog 50 podatności z zeszłego tygodnia dokumentuje ten kanał obszernie.

Iniekcja przez plik umiejętności. Atakujący umieszcza wrogie instrukcje w plikach umiejętności i konfiguracji, które agent ładuje jako zaufany kontekst. Agent traktuje zawartość pliku umiejętności jako autorytatywną, więc atakujący mogący zapisywać do pliku umiejętności lub konfiguracji może kierować zachowaniem agenta.

Architektura obrony umieszcza wymuszanie na granicy wywołania narzędzia — jedynym punkcie, przez który musi przejść każda zewnętrzna akcja, niezależnie od tego, który kanał wstrzyknął instrukcję.¹ Zanim agent wywoła jakiekolwiek narzędzie, ClawGuard sprawdza wywołanie względem zestawu reguł. W ocenianej konfiguracji reguły te to podstawowe ograniczenia kontroli dostępu (restrykcje ścieżek plików, listy dozwolonych wywołań sieciowych, blokady dostępu do poświadczeń). ClawGuard blokuje każde wywołanie wykraczające poza te ograniczenia, bez względu na to, jak przekonujący jest prompt iniekcyjny.

Warto wyraźnie sformułować kluczową obserwację architektoniczną: nie trzeba wykrywać każdej iniekcji, jeśli można wymusić politykę na granicy wykonania.

Incydent telemetryczny Vercel

Cztery dni przed publikacją pracy o 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 hookach, co oznaczało, że hooki uruchamiały się na wszystkich projektach, nie tylko na projektach Vercel.² Mechanizm zgody wykorzystywał prompt injection 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 rozwiązał problemy telemetryczne 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, poprzez mechanizm omijający natywne UI zgody.

Wystarczy zastąpić „telemetrię” przez „eksfiltrację”, a architektura jest identyczna. Hook z nadmiernie szerokim matcherem, działający na każdym projekcie, wysyłający dane do zewnętrznego endpointu. Różnica między telemetrią a atakiem to intencja, a intencji nie można audytować w czasie wykonania.

Od publikacji do praktyki: co praktycy już mają

ClawGuard formalizuje coś, co praktycy budowali nieformalnie. Claude Code dostarcza system hooków obsługujący przechwytywanie PreToolUse i PostToolUse. Prowadzę ponad 95 hooków wymuszających restrykcje ścieżek plików, walidujących dane wejściowe narzędzi i bramkujących destrukcyjne operacje za 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 do katalogów projektu, wymagaj zatwierdzenia dla git force-push. Oceniana konfiguracja ClawGuard stosuje podstawowe reguły kontroli dostępu podobne duchem do ręcznie pisanych hooków. Proponowany w pracy komponent indukcji reguł specyficznych dla zadania automatycznie wyprowadzałby ograniczenia z celu podanego przez użytkownika.¹ Zamiast pisać „blokuj zapisy do /etc”, framework wnioskowałby, że zadanie opisane jako „zrefaktoryzuj moduł logowania” nie powinno wymagać dostępu do zapisu w katalogach systemowych. Ten komponent pozostaje pracą przyszłą.

Automatyczne wyprowadzanie ograniczeń to trudniejszy problem, a komponent indukcji reguł ClawGuard stanowi pracę przyszłą, nie ocenione wyniki. Podstawowa konfiguracja regułowa, którą autorzy faktycznie ocenili, wykazała silne, ale nie idealne wyniki: AgentDojo osiągnęło 0% wskaźnika sukcesu ataku (ASR), ale SkillInject wciąż notował 4,8–14% ASR, a MCPSafeBench wykazał 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 pokryć ataki nieprzewidziane, ponieważ operują na zbiorze pozytywnym (co powinno się wydarzyć), a nie negatywnym (co nie powinno).

Czy automatyczne wyprowadzanie działa niezawodnie w produkcji — to pytanie otwarte. Benchmarki to środowiska kontrolowane. Rzeczywiste sesje agentów obejmują niejednoznaczne zadania, wielokrokowe łańcuchy narzędzi i wywołania, 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łania narzędzia 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 wskaźnik fałszywych alarmów, ale wychwytuje tylko znane złośliwe wzorce.

Warstwa 2: Wymuszanie podstawowych reguł. Ograniczanie zestawu dozwolonych narzędzi i argumentów na podstawie reguł kontroli dostępu (restrykcje ścieżek, listy dozwolonych połączeń sieciowych, blokady poświadczeń). Oceniana konfiguracja ClawGuard działa na tej warstwie.¹ Praca proponuje również wyprowadzanie ograniczeń w zakresie zadania, które mieściłoby się między tą warstwą a następną, ale ten komponent pozostaje pracą przyszłą. Większe pokrycie niż sama walidacja danych wejściowych, ale reguły wymagają aktualizacji wraz ze zmianą środowiska.

Warstwa 3: Inspekcja danych wyjściowych. Hooki PostToolUse badające wyniki narzędzia, zanim agent je przetworzy. Wychwytuje eksfiltrację danych, wykrywa anomalne odpowiedzi, oznacza nieoczekiwane zachowanie narzędzi. Post o pośredniku dokumentuje, dlaczego inspekcja wyjścia 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 przeglądu po fakcie. Nie mechanizm prewencji, lecz detekcji. Akshay Chugh odkrył incydent telemetryczny Vercel właśnie poprzez tego rodzaju audyt: czytanie konfiguracji hooków i śledzenie, co hooki robiły.²

Żadna pojedyncza warstwa nie jest wystarczająca. Walidacja danych wejściowych nie wychwytuje nowych wzorców. Ograniczenia w zakresie zadania mogą być zbyt restrykcyjne lub zbyt permisywne. Inspekcja wyjścia dodaje opóźnienie. Audyt sesji wychwytuje problemy po wyrządzeniu szkody. Stos działa, ponieważ każda warstwa pokrywa luki pozostawione przez inne.

Co ClawGuard robi dobrze

Praca wnosi trzy rzeczy istotne 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ść z czasu treningu, która degraduje w warunkach wrogich. Deterministyczne wymuszanie to właściwość czasu wykonania, która utrzymuje się niezależnie od zachowania modelu. Rozróżnienie brzmi akademicko, ale zmienia to, co można obiecać w kwestii poziomu bezpieczeństwa systemu.

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

Brak wymogu modyfikacji modelu. Niewymaganie ani fine-tuningu, ani modyfikacji architektonicznych oznacza, że obrona działa z dowolnym modelem, w tym z modelami, nad którymi nie mamy kontroli. Operator korzystający z Claude Code, Codex CLI lub dowolnego innego frameworka 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 lub ścieżki są w zakresie. Wyprowadzanie ograniczeń z mglistych celów grozi albo blokowaniem uzasadnionych wywołań (zbyt restrykcyjne), albo dopuszczaniem niebezpiecznych (zbyt permisywne).

Łańcuchy wielokrokowe. 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 przewidywać kroków pośrednich.

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

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

Wnioski operacyjne

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

Wdróż hooki PreToolUse już teraz. Nie trzeba czekać na ClawGuard ani żaden inny framework. System hooków Claude Code obsługuje przechwytywanie wywołań narzędzi już dzisiaj. Warto zacząć od walidacji danych wejściowych: blokowanie adresów wewnętrznych, ograniczanie ścieżek plików, bramkowanie destrukcyjnych operacji. Poradnik o hookach opisuje implementację.

Audytuj matchery hooków. Incydent Vercel wydarzył się, ponieważ puste matchery uruchamiały się na wszystkich projektach.² Należy przejrzeć każdy hook w .claude/settings.json i zweryfikować, że każdy matcher celuje wyłącznie w zamierzony kontekst. Hook z nadmiernie szerokim matcherem to odpowiedzialność, nie obrona.

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

Oceń ClawGuard względem własnego stosu. Praca linkuje repozytorium, choć w momencie pisania autorzy nie opublikowali jeszcze kodu. Gdy będzie dostępny, warto ocenić podstawową konfigurację regułową 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 to powierzchnia ataku. Należy stosować te same kontrole dostępu, co do poświadczeń produkcyjnych.

Katalog podatności MCP udokumentował powierzchnię ataku. ClawGuard proponuje architekturę obrony. Incydent Vercel demonstruje, dlaczego jedno i drugie ma znaczenie. Obrona w czasie wykonania na granicy wywołania narzędzia to warstwa, którą można wyegzekwować — nie dlatego, że alignment nie pomaga, lecz dlatego, że wymuszanie 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 obsługuje zarówno zatwierdzanie na poziomie narzędzia (zatwierdzenie lub odmowa kategorii narzędzi), jak i specyfikatory na poziomie argumentów (np. Bash(git diff *) dla dopuszczania wyłącznie pasujących poleceń). Oceniana konfiguracja ClawGuard wymusza podstawowe reguły kontroli dostępu na poziomie argumentów. Proponowany komponent indukcji reguł specyficznych dla zadania automatycznie wyprowadzałby ograniczenia argumentów z bieżącego zadania, ale autorzy tego komponentu nie ocenili. Oba systemy się uzupełniają: uprawnienia Claude Code bramkują, które narzędzia i wzorce argumentów mogą działać, podczas gdy ograniczenia w czasie wykonania w stylu ClawGuard dodają drugą warstwę wymuszania.

Czy muszę czekać na wydanie ClawGuard, aby dodać obronę w czasie wykonania?

Nie. System hooków Claude Code obsługuje przechwytywanie PreToolUse i PostToolUse już dzisiaj. 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 opisał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 poprzez natywne UI. Vercel od tego czasu rozwiązał te problemy. Wzorzec architektoniczny (szerokie matchery hooków, transmisja danych na zewnątrz, nienatywna zgoda) pozostaje pouczający, ponieważ odzwierciedla ten sam wzorzec, który złośliwy hook wykorzystałby do eksfiltracji danych.

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

W przypadku ręcznie pisanych hooków wykorzystujących skrypty powłoki lub lekkie walidatory, narzut w moim doświadczeniu operacyjnym powinien utrzymywać się poniżej 200 ms na wywołanie narzędzia. Praca o ClawGuard nie raportuje pomiarów opóźnień dla ewaluacji ograniczeń, co może dodawać dodatkowy narzut. Dla sesji interaktywnych opóźnienie na wywołanie narzędzia ma znaczenie, dlatego warto przetestować przed wdrożeniem złożonej logiki walidacyjnej.