Zabezpieczanie agentów w punktach końcowych za pomocą Numbat

Agenci AI muszą być bezpieczni, aby mogli być użyteczni. W miarę wzrostu możliwości modeli i systemów, rośnie również czujność wymagana do ochrony użytkowników.

Wczesne badania nad bezpieczeństwem agentów koncentrowały się na wstrzykiwaniu poleceń (prompt injection) i innych formach wprowadzania danych o charakterze wrogim. Jednak niedawne postępy w autonomii agentów prowadzą do incydentów bezpieczeństwa, które nie zakładają istnienia wrogich danych wejściowych ani w ogóle ludzkich przeciwników.

Zamiast tego agenci skierowani na realizację celów wysokiego poziomu, bez wytycznych dotyczących sposobu osiągnięcia tych celów, mogą stać się przeciwnikiem. Dzieje się tak, gdy agent, w odpowiedzi na cel określony przez użytkownika, wybiera sposób działania, którego użytkownik nie zamierzał i którego by nie zatwierdził. Choć incydenty takie były teoretyzowane zaledwie kilka miesięcy temu, szybko stały się kwestią praktycznej troski.

Ponieważ zachowań tych nie można w pełni naprawić na warstwie modelu, solidna obrona musi znajdować się w systemie otaczającym, w tym w oprzyrządowaniu agenta (agent harness), które służy jako interfejs modelu do świata zewnętrznego. Udostępniamy na zasadach open source Numbat, nasz pakiet bezpieczeństwa agentów, który pomaga obrońcom zapobiegać incydentom związanym z agentami, wykrywać je i ograniczać ich skutki. Numbat identyfikuje i bezpośrednio integruje się z oprzyrządowaniem agentów powszechnie spotykanym w punktach końcowych klientów korporacyjnych, egzekwując zasady bezpieczeństwa i umożliwiając szybkie wykrywanie oraz reagowanie.

Wdrożenie agentów wiąże się z nowymi wyzwaniami w zakresie bezpieczeństwa zarówno dla programistów, użytkowników, jak i obrońców. Jest to szczególnie istotne, gdy przedsiębiorstwa wdrażają agentów bezpośrednio w punktach końcowych klientów, zapewniając im uprzywilejowany dostęp do systemów i danych przedsiębiorstwa.

Wdrożenia agentów w punktach końcowych klientów, takie jak agenci kodujący oparty na CLI lub aplikacji komputerowej, wiążą się z różnymi poziomami piaskownicy i izolacji. Użytkownicy wykorzystują tych agentów do niezliczonych przypadków użycia, z których każdy posiada własną przestrzeń działań, mogącą wpłynąć na sam punkt końcowy lub inne systemy dostępne z poziomu punktu końcowego. Coraz częściej oczekuje się, że agenci będą działać autonomicznie przez wiele godzin, a nawet dni. W przypadku tych przepływów pracy, wielu użytkowników decyduje się na delegowanie zatwierdzania działań agenta klasyfikatorom lub całkowite pomijanie zatwierdzeń za pomocą niepokojąco nazwanych flag konfiguracyjnych, takich jak --dangerously-skip-permissions oraz --yolo. Mnogość przypadków użycia i konfiguracji agentów, w połączeniu z zakresem działań, jakie agenci kodujący mogą wykonywać w uprzywilejowanych punktach końcowych, tworzy profil ryzyka wymagający proaktywnego zarządzania przez zespoły ds. bezpieczeństwa.

Dziś udostępniamy Numbat, pakiet bezpieczeństwa agentów typu open source, który stworzyliśmy w celu wykrywania, badania i zapobiegania niebezpiecznym działaniom agentów AI. W miarę jak coraz więcej firm wdraża pionierskie produkty oparte na agentach, Numbat wzmacnia zespoły ds. bezpieczeństwa w dotrzymywaniu kroku wynikającym z tego wyzwaniom. Integruje się on z każdym z najczęściej używanych systemów oprzyrządowania agentów po stronie klienta, udostępniając spójny interfejs we wszystkich z nich. Dzięki temu Numbat uwalnia zespoły ds. bezpieczeństwa od ciężaru budowania niestandardowych zabezpieczeń i narzędzi monitorujących dla każdego indywidualnego agenta, na którym polegają użytkownicy. Numbat jest dostępny dla ekosystemu obrońców w ramach członkostwa Perplexity w Open Secure AI Alliance wraz z NVIDIA i innymi organizacjami.

Architektura systemu agentów zabezpieczonych za pomocą Numbat. Numbat kładzie nacisk na wykrywanie w pierwszej kolejności lokalnie oraz na informatykę śledczą niezależną od agenta.

Ten artykuł rozpoczyna się od dyskusji na temat wyzwań związanych z bezpieczeństwem, które stały się podstawą powstania Numbat. Następnie przedstawiamy projekt i architekturę Numbat, wraz z naszymi wnioskami z wdrożenia Numbat w tysiącach własnych punktów końcowych Perplexity.

Krajobraz incydentów bezpieczeństwa związanych z agentami AI szybko ewoluuje. Znaczna część istniejącej literatury dotyczącej bezpieczeństwa agentów koncentruje się na atakach wstrzykiwania, w których złośliwy ładunek jest wprowadzany do podpowiedzi modelu (prompts) lub kontekstu, aby wprowadzić agentów w błąd i skłonić do niewłaściwego zachowania. Ataki wstrzykiwania i mechanizmy obronne zostały obszernie przebadane, a programiści agentów, w tym Perplexity, opracowali coraz bardziej solidne obrony przed atakami wstrzykiwania.

Jednak agent AI nie potrzebuje złośliwego ładunku, aby stworzyć incydent bezpieczeństwa. W rzeczywistości nie trzeba w ogóle zakładać istnienia przeciwnika. Zaufany agent, działający w zaufanym środowisku przy użyciu zatwierdzonych przez administratora narzędzi, może podjąć szkodliwe działania tylko dlatego, że zbyt mocno stara się wykonać swoje zadanie.

Badacze opisują ten tryb awarii jako „przypadkowe stopienie” (accidental meltdown): szkodliwe zachowanie agenta wywołane nie przez wrogie dane wejściowe, ale przez zwykły błąd środowiskowy. Brakujący plik, nieudane żądanie API, wygasłe poświadczenia lub odmowa uprawnień mogą sprawić, że agent zacznie szukać obejścia. Realizując pierwotny cel określony przez użytkownika, agent może przekroczyć granice bezpieczeństwa poprzez nieautoryzowane rozpoznanie, zmiany w kontroli dostępu, odkrywanie haseł lub eksfiltrację danych. Zamiast agenta przejętego przez atakującego, sam agent staje się atakującym. Co więcej, atak może być skierowany na systemy wewnętrzne, zewnętrzne lub oba naraz, bez możliwości rozpoznania, dopóki atak nie trwa już w najlepsze.

Pierwszy szeroko zgłoszony przypadek „przypadkowego stopienia” pojawił się w tym miesiącu wraz z ujawnieniem przez OpenAI ataku zainicjowanego przez agenta, który naruszył infrastrukturę produkcyjną Hugging Face. Podczas ewaluacji modelu GPT przed wydaniem, model nie był w stanie poczynić postępów w ewaluacji przy użyciu dostarczonego kontekstu. Aby przełamać ten impas, model znalazł sposób na ucieczkę ze swojego środowiska testowego piaskownicy i wyeksfiltrowanie odpowiedzi ewaluacyjnych z Hugging Face. Model wykorzystał swoje oprzyrządowanie, aby uciec od zamierzonych ograniczeń sieciowych, eskalować uprawnienia poza granice piaskownicy, uzyskać sekrety i uzyskać dostęp do bezpiecznych systemów Hugging Face, a wszystko to w celu realizacji wąskiego celu, jakim było rozwiązanie ewaluacji.

Stopienia obejmują również niezamierzone mutacje i usunięcia systemowe. Choć może to być mniej spektakularne niż naruszenie systemu zewnętrznego, zdarzenia te są częstsze i bardziej istotne dla każdego zaawansowanego użytkownika agentów kodujących. Usuwanie baz danych produkcyjnych lub katalogów domowych to najgorszy koszmar każdego programisty, a agenci muszą być w stanie unikać takich zachowań w trakcie swojego działania.

Badacze AI pracują nad ograniczeniem tych zachowań w samych modelach. Chociaż wysiłki te są z pewnością cenne, wielu członków społeczności badawczej dostrzega fundamentalne napięcie między trenowaniem modeli pod kątem silnych właściwości bezpieczeństwa a trenowaniem tych samych modeli do realizacji coraz bardziej złożonych zadań. Uważamy, że jest mało prawdopodobne, aby obrona koncentrująca się wyłącznie na warstwie modelu zmniejszyła ryzyko stopienia do akceptowalnego poziomu.

Wniosek jest taki, że bezpieczeństwo agentów nie może opierać się wyłącznie na zabezpieczeniach modelu, użytkownika lub poziomu zadania. Zespoły ds. bezpieczeństwa potrzebują widoczności tego, co agenci faktycznie robią w punktach końcowych klientów, oraz kontroli, które mogą powstrzymać niebezpieczne działania, zanim zostaną one uruchomione. Są to kontrole na poziomie systemu, które muszą być ściśle zintegrowane z oprzyrządowaniem agenta.

Numbat zapewnia te kontrole w postaci lekkiego, statycznego pliku binarnego Go, który płynnie integruje się z wiodącymi systemami oprzyrządowania agentów po stronie klienta. Oferuje on monitorowanie na żywo, egzekwowanie polityk i rekonstrukcję śledczą w ramach oprzyrządowania agentów i środowisk wykonawczych.

Kluczowymi punktami integracji między Numbat a oprzyrządowaniem agenta są punkty zaczepienia (hooks), artefakty sesji oraz telemetria OTLP. Omówimy każdy z nich po kolei.

Praktycznie wszyscy agenci kodujący posiadają podsystem hook. Punkty zaczepienia pozwalają agentom deterministycznie wykonywać podprogramy w określonych punktach cyklu życia wykonywania agenta. Użytkownicy agentów zazwyczaj konfigurują punkty zaczepienia, aby dostarczać modelom dodatkowy kontekst w przewidywalny sposób, wdrażać pętle testowania i weryfikacji oraz wprowadzać inne ulepszenia możliwości agenta.

Te same właściwości deterministyczne, które czynią punkty zaczepienia atrakcyjnymi do tych celów, sprawiają, że są one również atrakcyjne dla wykrywania i reagowania. Zazwyczaj nie wystarczy wyłapać większości wystąpień potencjalnie niepokojącego zdarzenia. Zamiast tego, należy objąć wszystkie takie wystąpienia w celu wykrycia i reakcji. Numbat konfiguruje wiele typów punktów zaczepienia, umożliwiając zespołom ds. bezpieczeństwa i administratorom IT wdrażanie zaawansowanej logiki wykrywania.

W większości agentów kodujących, niektóre typy punktów zaczepienia (powszechnie nazywane punktami „przed akcją”) są również w stanie zablokować wykonanie następnej akcji agenta. Używając tych punktów zaczepienia przed akcją, Numbat jest w stanie wdrożyć nie tylko logikę wykrywania, ale także prewencyjne zasady bezpieczeństwa, aby zapobiec wystąpieniu stopienia w pierwszej kolejności.

Punkty zaczepienia są potężnymi środkami wdrażania logiki wykrywania i zapobiegania w czasie rzeczywistym. Jednak logika ta musi być możliwa do określenia w kodzie. Często incydent bezpieczeństwa agenta przybiera formę, której nie można było przewidzieć z wyprzedzeniem, nie wspominając o sprowadzeniu jej do kodu źródłowego. Dlatego Numbat ma również możliwość uzyskiwania dostępu do artefaktów sesji i analizowania ich z mocą wsteczną.

Artefakty sesji obejmują wiele typów dzienników i diagnostyki. Być może najważniejszym typem dziennika jest zapis sesji (transcript), który rejestruje konwersacje LLM dyktujące sekwencję działań agenta. Zaawansowani użytkownicy agentów kodujących są już przyzwyczajeni do eksportowania zapisów sesji w celu dalszej analizy za pomocą poleceń dostarczonych przez oprzyrządowanie. Jednak eksporty te są zazwyczaj w formacie czystego tekstu, co jest źle dopasowane do potrzeb zespołów ds. bezpieczeństwa, które wymagają dzienników czytelnych maszynowo ze spójnym, przewidywalnym schematem.

Numbat pobiera zatem artefakty sesji bezpośrednio z systemu plików. Ponieważ większość systemów oprzyrządowania agentów po stronie klienta przechowuje oryginalne artefakty w systemie plików (zazwyczaj w katalogu kropkowym specyficznym dla agenta pod $HOME), wykorzystanie systemu plików zapewnia najbardziej bezpośrednią drogę do tych danych w ich najbardziej użytecznej i nieskażonej formie. Zespoły ds. bezpieczeństwa korzystające z Numbat mogą zbierać te artefakty w znormalizowanym formacie osi czasu NDJSON poprzez numbat scan, zarówno do lokalnego przetwarzania w punkcie końcowym klienta, jak i do asynchronicznej analizy zdalnej. Ponieważ artefakty sesji są statycznymi, autonomicznymi zapisami, Numbat jest w stanie zrekonstruować te osie czasu nawet dla sesji, które miały miejsce na długo przed zainstalowaniem Numbat.

Większość systemów oprzyrządowania agentów po stronie klienta oferuje rozbudowaną telemetrię poprzez protokół OpenTelemetry (OTLP). Telemetria ta zazwyczaj dostarcza wielu sygnałów wykraczających poza te dostępne poprzez punkty zaczepienia lub artefakty sesji.

Numbat może pełnić funkcję odbiornika OTLP poprzez polecenie numbat collect. Polecenie to uruchamia serwer, do którego agenci kodujący wysyłają telemetrię OTLP w celu dalszej analizy. Co ważne, serwer ten jest lokalny i domyślnie nasłuchuje tylko na localhost, co oznacza, że cała telemetria domyślnie pozostaje na urządzeniu. Administratorzy bezpieczeństwa mogą następnie zdecydować, co zrobić z zarejestrowaną telemetrią, czy wiąże się to z wdrożeniem lekkiego przetwarzania na urządzeniu, zdalnym przetwarzaniem za pomocą numbat ship, czy bardziej zaangażowaną analizą na platformach analitycznych, takich jak ClickHouse.

Wewnątrz Perplexity używamy Numbat do zabezpieczania korzystania przez naszych inżynierów z agentów kodujących po stronie klienta, w tym Claude Code, Codex, OpenCode i Pi.

Zarówno nasze wysiłki w zakresie zapobiegania, jak i wykrywania w szerokim stopniu wykorzystują reguły Numbat, które są wdrażane poprzez podsystem punktów zaczepienia każdego agenta. Sformułowaliśmy kilka podstawowych reguł na własne potrzeby, z których wiele udostępniliśmy jako część 52 wbudowanych reguł Numbat. Reguły te są zorganizowane w 11 kategorii zachowań oraz zestaw wieloetapowych detekcji sekwencji, takich jak dostęp do sekretów, eksfiltracja, eskalacja uprawnień i ruch boczny. Reguły używają wyrażeń CEL nad znormalizowanymi zdarzeniami, a operatorzy mogą dodawać własne reguły i testy bez zmiany kodu Numbat.

Na przykład wbudowana reguła privilege.sudoers_tamper wykrywa zapisy do polityki sudoers, użycie visudo oraz próby instalacji uprawnień NOPASSWD. Są to działania o wysokim sygnale, które mogą zmienić ograniczony proces agenta w trwały dostęp roota.

yaml

# privilege.sudoers_tamper (simplified for readability)
id: privilege.sudoers_tamper
severity: high
expr: |
  (
    event.event_type == "file.write" &&
    event.file_path.matches("(^|/)etc/sudoers$|(^|/)etc/sudoers\\.d/[^/]+$")
  ) || (
    event.event_type == "command.exec" &&
    event.command.matches("\\bvisudo\\b|\\bNOPASSWD\\s*:")
  )

Indywidualne polecenia nie zawsze wyglądają na złośliwe same w sobie, więc Numbat koreluje również sekwencje w ramach sesji agenta. Wbudowana reguła chain.secret_manager_read_then_egress wykrywa moment, gdy agent odczytuje wartość z popularnego narzędzia do zarządzania sekretami, a później próbuje żądania curl lub wget niosącego dane. Odczyt sekretu może być uzasadniony. Żądanie wychodzące może być uzasadnione. Zsekwencjonowane razem wymagają dochodzenia.

yaml

# chain.secret_manager_read_then_egress (simplified for readability)
id: chain.secret_manager_read_then_egress
severity: high
sequence:
  within_events: 64
  steps:
    - expr: |
        event.event_type == "command.exec" &&
        event.command.matches("secretsmanager|get-secret|vault read")
    - expr: |
        event.event_type == "command.exec" &&
        event.command.matches("curl.*(--data|--upload-file)|wget.*--post")

Podobnie jak Bumblebee, nasz skaner open source pod kątem ekspozycji łańcucha dostaw w punktach końcowych programistów, Numbat jest wdrażany w naszej flocie poprzez MDM. Każdy Numbat rejestruje aktywność agenta lokalnie i wysyła ustrukturyzowaną telemetrię do naszych scentralizowanych systemów bezpieczeństwa.

Stamtąd Perplexity Computer przegląda niedawne ustalenia Numbat i dzienniki audytu zgodnie z harmonogramem pod kątem podejrzanych lub złośliwych zachowań. Badane są detekcje, rekonstruowane są odpowiednie sesje agentów i poddawane dodatkowej kontroli działania, które zostały zablokowane przez Numbat.

Wewnętrzny potok Perplexity do monitorowania telemetrii Numbat. Zaplanowane zadanie Perplexity Computer asynchronicznie przegląda nowe sygnały i ostrzega zespół ds. bezpieczeństwa o ryzykownych działaniach.

Computer szuka również luk w naszym zasięgu. Analizuje nowe zachowania, proponuje ulepszenia detekcji Numbat, testuje te zmiany i otwiera pull requesty do weryfikacji przez człowieka. Po zatwierdzeniu i wdrożeniu, reguły te poprawiają monitorowanie w całej flocie i tworzą lepsze dowody dla następnego dochodzenia.

Tworzy to samodoskonalące się koło zamachowe bezpieczeństwa: agenci generują aktywność, Numbat zamienia tę aktywność w znormalizowane osie czasu i telemetrię, Computer bada i ulepsza reguły, a aktualizacje zweryfikowane przez człowieka wzmacniają kontrole chroniące przyszłe sesje agentów.

W Perplexity wierzymy, że agenci AI będą działać we wszystkich typach środowisk: lokalnych, chmurowych i hybrydowych. Każda kombinacja oprzyrządowania agenta i środowiska wykonawczego stwarza unikalne wyzwania w zakresie bezpieczeństwa, przy czym złożoność kombinatoryczna grozi przytłoczeniem zespołów ds. bezpieczeństwa z ograniczonymi zasobami. Stopienia agentów i inne nowe podatności jeszcze bardziej komplikują obraz bezpieczeństwa.

Obrona, która zamieszkuje sam system agenta, może poprawić poziom bezpieczeństwa użytkownika bez względu na to, gdzie agent wykonuje swoje zadania. To właśnie zapewnia Numbat: ściśle zintegrowane zabezpieczenia agentów, które pozwalają obrońcom zapobiegać, wykrywać i reagować na niepokojące zachowania w czasie rzeczywistym. Połączenie Numbat z Perplexity Computer tworzy potężną platformę bezpieczeństwa agentów, która wzmacnia obrońców, aby wyprzedzali zagrożenia.

Numbat jest dostępny już dziś jako projekt open source dla systemów macOS, Linux i Windows. Nasze własne punkty końcowe klientów są zabezpieczone przez Numbat, co pozwala członkom zespołu Perplexity na pewne korzystanie z agentów przy szeroko zakrojonych zadaniach i długich horyzontach czasowych. Zapraszamy zespoły ds. bezpieczeństwa na całym świecie do wykorzystania podejścia Numbat na poziomie systemu w celu zabezpieczenia i ochrony ich wdrożeń agentów.

BibTeX

@online{perplexity2026SecuringAgentsAcrossPerplexitySClientEndpointsWithNumbat,
  author = {{Perplexity} and Adel Karimishiraz and Bex Brooker and Phi Hoang and Jerry Ma},
  title = {{Securing agents across Perplexity's client endpoints with Numbat}},
  date = {2026-07-29},
  url = {https://perplexity.coolkeypoint.com/hub/blog/securing-agents-across-perplexity-s-client-endpoints-with-numbat}
}

Wprowadzenie

Określenie krajobrazu podatności

Zabezpieczanie agentów kodujących poprzez natywne integracje z oprzyrządowaniem

Punkty zaczepienia (Hooks)

Artefakty sesji

Telemetria OTLP

Wdrażanie Numbat wewnątrz Perplexity

Zarządzanie i monitorowanie Numbat w całej flocie

Podsumowanie

Cytowanie