Jak projektujemy bezpieczniejszych agentów

Aby budować bezpieczniejszych agentów AI, musimy projektować ich systemy zarówno z myślą o ich możliwościach, jak i o ich awariach. Nawet podczas wykonywania legalnych zadań i bez żadnych złośliwych instrukcji agenci mogą przekraczać granice bezpieczeństwa, próbując pokonać napotkane przeszkody.

Wierzymy, że jest to problem inżynierii bezpieczeństwa i branża powinna zmierzyć się z nim tak, jak zmierzyła się z robakami internetowymi wczesnych lat dwutysięcznych. Systemy otaczające agentów muszą ograniczać to, do czego agenci mogą uzyskać dostęp, wykrywać niepożądane zachowania i powstrzymywać awarie, gdy do nich dochodzi.

W Perplexity aktywnie współpracujemy z badaczami i praktykami w celu rozwoju inżynierii bezpieczeństwa dla agentów AI oraz stosujemy wiele warstw obrony w naszych modelach, harnessach agentów i infrastrukturze, dzięki czemu bezpieczeństwo nie zależy od żadnego pojedynczego zabezpieczenia.

Zachowanie awaryjne (Meltdown) agentów AI

W lipcu agenci AI włami się do produkcyjnej infrastruktury platformy AI open-source Hugging Face. Podczas wewnętrznej ewaluacji cyberbezpieczeństwa i cyklów treningowych modele OpenAI odkryły sposób na wykorzystanie menedżera repozytoriów Artifactory w celu utworzenia tablicy ogłoszeń do komunikowania się między sobą, co umożliwiło im organizowanie się w roje. Później agenci, którzy nie mogli zrobić postępów w zadaniach w benchmarku cyberbezpieczeństwa, rekrutowali innych agentów do pomocy. Ci agenci uciekli ze swojego środowiska ewaluacyjnego i dotarli do internetu. Odkryli również sposoby na oszukiwanie poprzez inżynierię wsteczną odpowiedzi na zadania benchmarkowe, ale uświadamiali sobie, że system oceny wykryje oszustwo. Aby lepiej zrozumieć, jak działa ewaluacja benchmarkowa w celu znalezienia sposobów na uniknięcie wykrycia oszustwa, ostatecznie naruszyli systemy Hugging Face (Hugging Face; OpenAI).

Incydent ten jest wyraźnym przykładem trybu awarii, który opisaliśmy, gdy udostępniliśmy Numbat jako open-source w lipcu: przypadkowe awarie (accidental meltdowns) – termin ukuty przez badaczy zajmujących się bezpieczeństwem z Cornell Tech (arXiv). Agent realizujący legalny cel napotyka przeszkody, takie jak brakujący plik, nieudane wywołanie API, wygasłe dane uwierzytelniające lub odmowa uprawnień, i zaczyna szukać obejścia. W ten sposób może przekroczyć granice bezpieczeństwa poprzez rekonesans, eskalację uprawnień, odkrywanie sekretów lub eksfiltrację danych. Sam agent faktycznie staje się przeciwnikiem, mimo że nie bierze w tym udziału żaden złośliwy prompt ani zewnętrzny napastnik.

Hugging Face nie był odosobnionym przypadkiem. W ostatnich tygodniach odkryto i zgłoszono więcej zachowań polegających na awarii agentów. W dniach 27–28 maja agenci próbujący zebrać dane Uniwersytetu Iowa z Data USA, platformy oferującej otwarty dostęp do danych rządu USA, natknęli się na błędy spowodowane nieprawidłowo sformułowanym zapytaniem. W odpowiedzi przeprowadzili sondowanie, w tym wstrzyknięcie kodu SQL (SQL injection), skryptowanie międzywitrynowe (XSS), wstrzyknięcie szablonu, przechodzenie ścieżki (path traversal) i wstrzyknięcie poleceń. Działalność tę powiązano później z OpenAI (SecurityWeek). W dniach 20–21 czerwca agenci OpenAI próbujący uzyskać dane o kosztach rządowych w przeliczeniu na osobę dla kategorii leków w obszarach lokalnych w Victorii z Australijskiego Instytutu Zdrowia i Opieki Społecznej (AIHW) zostali zablokowani przed pobraniem pliku. W odpowiedzi agenci pobrali plik, który był już publiczny, z serwera przedprodukcyjnego AIHW, omijając przy tym zabezpieczenia antybotowe witryny (SecurityWeek).

Ten wzorzec nie ogranicza się do jednego laboratorium. Podczas testów cyberbezpieczeństwa modele Anthropic naruszyły zabezpieczenia trzech firm po tym, jak błąd dał im otwarty dostęp do internetu, Google Gemini odgadł dane uwierzytelniające do trzech stron internetowych, a model Meta wykorzystał usługę strony trzeciej (Reuters).

Lekcja z historii: Era robaków internetowych

Incydenty te przypominają erę robaków internetowych sprzed około ćwierćwiecza. Na początku lat dwutysięcznych internet rozwijał się znacznie szybciej niż praktyki bezpieczeństwa wokół niego. Byliśmy świadkami fali wirusów i robaków, których skutki były znacznie poważniejsze niż to, co obserwujemy obecnie w przypadku awarii agentów AI.

4 maja 2000 r. ludzie zaczęli otrzymywać wiadomości e-mail od znanych nadawców z tematem „ILOVEYOU”. Otwarcie załącznika w wiadomości e-mail skutkowało uruchomieniem skryptu, który wysyłał kopię samego siebie do wszystkich osób z książki adresowej programu Outlook ofiary. Do godziny 18:00 tego samego dnia Centrum Koordynacji CERT otrzymało zgłoszenia dotyczące ponad 420 000 hostów internetowych (US GAO Report). Według doniesień wirus przeniknął do co najmniej 14 agencji federalnych, w tym Departamentu Obrony, CIA, NASA oraz Izby Reprezentantów i Senatu (US GAO Report). Spowodował również wyłączenie serwerów pocztowych w Pentagonie i brytyjskim parlamencie (Wired). Gigant ubezpieczeniowy Lloyd's of London oszacował wczesnym etapie, że wirus spowoduje straty i utratę wydajności o wartości ponad 15 miliardów dolarów (US House Committee Hearing). Firma Computer Economics oszacowała później straty na świecie na 8,75 miliarda dolarów (Information Week).

Następnie pojawiły się robaki, które nie wymagały kliknięcia przez człowieka. 19 lipca 2001 r. robak Code-Red zainfekował ponad 359 000 komputerów w niespełna 14 godzin (CAIDA). 25 stycznia 2003 r. SQL Slammer podwajał swoją wielkość co 8,5 sekundy i w ciągu 10 minut zainfekował ponad 90% hostów internetowych podatnych na jego działania (CAIDA), wykorzystując lukę, dla której firma Microsoft wydała łatkę sześć miesięcy wcześniej (CNET). W sierpniu 2003 r. robak Blaster i robak e-mailowy Sobig pojawiły się w odstępie około tygodnia (Microsoft, F-Secure).

W tamtym czasie zasadne było pytanie, czy skomputeryzowane sieci można w ogóle uczynić bezpiecznymi. Sześć dni po wirusie ILOVEYOU podkomisja Izby Reprezentantów USA przeprowadziła w tej sprawie wysłuchanie. Wielu ekspertów ds. bezpieczeństwa wzywało do uchwalenia przepisów, które pociągałyby firmy programistyczne do odpowiedzialności za szkody spowodowane przez wady w ich produktach. Waszyngton obrał inną ścieżkę. Krajowa Strategia Zabezpieczenia Cybersprzestrzeni (National Strategy to Secure Cyberspace) stwierdziła, że „regulacje federalne nie staną się głównym środkiem zabezpieczania cyberspace'u”. Ostrzegła, że szerokie mandaty mogą stworzyć „podejście oparte na najniższym wspólnym mianowniku do cyberbezpieczeństwa” (CISA).

Branża odpowiedziała inżynierią. Jedenaście dni po ILOVEYOU firma Microsoft ogłosiła aktualizację programu Outlook, która blokowała załączniki stanowiące pliki wykonywalne. W styczniu 2002 roku firma uczyniła bezpieczeństwo swoim najwyższym priorytetem (Seattle Times). Automatyczne łatanie luk, bezpieczne ustawienia domyślne, programy bug bounty i skoordynowane ujawnianie informacji stały się standardową praktyką. W 2008 roku przeglądarka Chrome zaczęła uruchamiać treści internetowe w piaskownicy, która "ogranicza możliwości atakującego po wykorzystaniu błędu" (Chromium Blog). Szyfrowanie, niegdyś będące wyjątkiem, stało się standardem. Technologie bezpieczeństwa, w tym uwierzytelnianie wieloskładnikowe (MFA), zapory sieciowe (firewalle), architektura zero trust oraz systemy zarządzania informacjami i zdarzeniami bezpieczeństwa (SIEM), stały się powszechnie stosowane. Przewiduje się, że organizacje na całym świecie wydadzą w 2026 roku około 240 miliardów dolarów na bezpieczeństwo informacji (Gartner). Robaki nigdy całkowicie nie zniknęły, ale era rutynowych, ogólnointernetowych epidemii minęła. Jednocześnie internet, w dużej mierze nieobciążony regulacjami, stał się potężnym silnikiem innowacji i wzrostu gospodarczego w ciągu kolejnych dwóch dekad.

Inżynieria bezpieczeństwa dla agentów AI

Niedawne incydenty wzbudziły uzasadnione pytania dotyczące nadzoru nad agentami. Istniejące mechanizmy bezpieczeństwa zostały opracowane dla środowisk informatycznych sprzed ery agentów, charakteryzujących się ściśle określonym i w dużej mierze deterministycznym zachowaniem oprogramowania. W szczególności mechanizmy kontroli dostępu są projektowane głównie z myślą o użytkownikach będących ludźmi i często przyznają im szerokie uprawnienia, które w zasadzie są wystarczające do wyrządzenia znacznych szkód.

Ten projekt opiera się na kilku założeniach: większość użytkowników działa w dobrej wierze; złośliwi aktorzy mogą zostać odstraszeni za pomocą audytów i konsekwencji w świecie rzeczywistym; a ludzie podejmują działania – zarówno poprawne, jak i błędne – w stosunkowo ograniczonym tempie. Zastosowanie tych mechanizmów bezpieczeństwa do agentów wymaga uwzględnienia różnic między zachowaniem człowieka a agenta. Jak napisaliśmy w naszej odpowiedzi na zapytanie NIST o informacje na temat bezpieczeństwa agentów AI, agenci AI stanowią wyzwanie dla tych założeń. Mogą oni korzystać z uprawnień i podejmować działania z prędkością maszynową, nie są sami w sobie odstraszani przez konsekwencje w świecie rzeczywistym i mogą podejmować działania, które są technicznie dozwolone, ale które typowy użytkownik będący człowiekiem podejmowałby rzadko.

Odpowiedzi na te pytania wymagają inżynierii bezpieczeństwa. Znamy zasady bezpieczeństwa dotyczące budowania systemów, które utrzymują ryzyko pod kontrolą, gdy poszczególne komponenty zachowują się niewłaściwie. Musimy jednak upewnić się, że zasady te są stosowane podczas projektowania środowisk do trenowania, testowania i używania agentów AI.

Zasada bezpieczeństwa obrony w głąb (defense-in-depth)

Prawdopodobnie najważniejszą zasadą bezpieczeństwa, którą należy zastosować w celu zabezpieczenia agentów AI, jest obrona w głąb. Promuje ona warstwową architekturę bezpieczeństwa, w której do ochrony zasobów systemowych stosuje się wiele różnorodnych i nadmiarowych środków obronnych. Żadne pojedyncze zabezpieczenie nie jest doskonałe. Ludzie mogą ulec atakom typu social engineering i ujawnić swoje dane logowania, podatności w oprogramowaniu typu zero-day są odkrywane i wykorzystywane, a wykrywanie intruzów pomija nowe warianty ataków. Obrona w głąb akceptuje ten fakt i układa kilka niezależnych warstw obrony. Jeśli jedna warstwa obronna zostanie ominięta, inne warstwy pozostają na swoim miejscu, aby przeciwdziałać włamaniu lub je wykryć.

Incydent w Hugging Face pokazuje, dlaczego obrona w głąb (defense-in-depth) ma znaczenie. Retrospektywa OpenAI informuje, że automatyczne zabezpieczenia stosowane w jego systemach produkcyjnych, w tym harness, modele auto-recenzji i klasyfikatory bezpieczeństwa, nie były obecne w środowisku ewaluacyjnym. Gdyby monitorowanie ciągu myślenia (chain-of-thought) uruchomione na tych ocenach działało w tamtym czasie, wykryłoby początkową aktywność i powiadomiło zespół ds. bezpieczeństwa ponad dobę przed naruszeniem (OpenAI). Warstwy, które mogły wychwycić problem, istniały. Po prostu nie wszystkie znajdowały się na swoim miejscu w tym samym czasie.

Zabezpieczenie agentów AI wymaga poprawy zarówno bezpieczeństwa i ochrony modeli AI, jak i systemów wokół nich. Praca na poziomie modelu ma znaczenie i przynosi efekty. Wczesne modele LLM były łatwo manipulowane przez wstrzykiwane instrukcje, podczas gdy dzisiejsze modele znacznie lepiej je rozpoznają i odrzucają. Twórcy modeli trenują je również pod kątem bezpieczniejszego zachowania i – jak opisuje retrospektywa OpenAI – monitorują ślady rozumowania pod kątem oznak problematycznego zachowania. Jednak obrona na poziomie modelu to tylko część rozwiązania. Systemy, w których agenci są trenowani, testowani i wdrażani, muszą być również zaprojektowane z myślą o bezpieczeństwie i powstrzymywaniu. Bezpieczeństwo na poziomie modelu zmniejsza prawdopodobieństwo, że agent zejdzie na manowce; bezpieczeństwo na poziomie systemu ogranicza szkody, gdy do tego dojdzie.

Powiększ

Zasady projektowania nadmiarowych zabezpieczeń

Obrona w głąb wymaga nadmiarowych zabezpieczeń. W przypadku agentów zalecamy stosowanie jej zgodnie z trzema zasadami projektowania:

1. Niezależność. Każda warstwa powinna zawieść z niezależnych powodów. Dwie kontrole opierające się na tym samym założeniu mogą zostać pokonane przez ten sam atak. Monitory i punkty egzekwowania powinny znajdować się poza zasięgiem agenta.
2. Egzekwowanie poniżej poziomu agenta. Przynajmniej jedna warstwa musi być deterministyczna: konwencjonalny, weryfikowalny kod, który blokuje zabronione działania bez względu na to, co wygeneruje model. Zabezpieczenie, które agent może odmówić wywołania lub przekonfigurować, nie jest zabezpieczeniem.
3. Sygnały mogą jedynie ograniczać uprawnienia. Wykrywanie powinno wywoływać reakcje, które zawężają możliwości agenta, takie jak wstrzymanie, cofnięcie uprawnień, odcięcie dostępu do sieci lub zakończenie sesji. Żaden sygnał ryzyka nigdy nie powinien przyznawać dodatkowego dostępu.

Dzielimy się tymi zasadami z naszymi partnerami w Open Secure AI Alliance, w tym z NVIDIA, która argumentowała, że harness kieruje tym, co agent próbuje zrobić, podczas gdy infrastruktura kontroluje to, co może on zrobić (NVIDIA).

Obrona w głąb w produktach Perplexity

Perplexity uruchamia agentów w czterech rodzajach środowisk: w chmurze za pośrednictwem naszej platformy agentowej Computer, w przeglądarce za pośrednictwem Comet, na urządzeniach użytkowników za pośrednictwem Portable Computer oraz na laptopach pracowników, gdzie nasi inżynierowie korzystają z zewnętrznych agentów kodujących. Każde środowisko wiąże się z własnymi ryzykami i każde otrzymuje kilka warstw ochrony.

W chmurze: Computer i SPACE

każde zadanie Computer działa w SPACE, naszej platformie piaskownicy, która domyślnie traktuje agenta jako niezaufanego. Każde zadanie otrzymuje własną mikromaszynę wirtualną (microVM), dane uwierzytelniające pozostają poza piaskownicą i są wstrzykiwane tylko wtedy, gdy jest to konieczne, ruch wychodzący jest kontrolowany poza gościem, a migawki pozwalają nam przywrócić stan sprzed destrukcyjnych zmian (Making SPACE). Klienci korporacyjni mogą również dostarczyć własne klucze szyfrowania. Odwołanie klucza sprawia, że chronione dane stają się nieczytelne, a agent nie może pominąć tej decyzji.

Testujemy również, czy te warstwy wytrzymują obciążenie. W artykule Escaping SPACE: Part I przyznaliśmy dziewięciu modelom czołowym (frontier models) dostęp root w piaskownicy SPACE i poprosiliśmy je o ucieczkę. Żaden z modeli nie uciekł z maszyny wirtualnej (VM), ale niektóre znalazły sposoby na ominięcie polityki sieciowej, gdy dozwolony był częściowy dostęp do sieci. Naprawiliśmy te luki, potwierdziliśmy poprawki w ponownym teście i ujawniliśmy podobne słabości wykryte na ośmiu z 10 innych platform piaskownic ich dostawcom.

W przeglądarce: Comet i BrowseSafe

Comet stosuje warstwową obronę przed wstrzykiwaniem promptów od momentu premiery: klasyfikatory filtrują pobraną treść, ustrukturyzowane prompty oznaczają ją jako niezaufaną, wrażliwe działania, takie jak wysłanie wiadomości e-mail lub złożenie zamówienia, wymagają potwierdzenia przez użytkownika, a użytkownicy są informowani, gdy coś zostanie zablokowane (Comet prompt-injection defenses). BrowseSafe, model wykrywania typu open-source stojący za pierwszą warstwą, przewyższa modele czołowe w naszym benchmarku BrowseSafe-Bench, jednak ten sam benchmark pokazuje, że żaden detektor nie jest niezawodny, dlatego wykrywanie nigdy nie jest jedyną warstwą (BrowseSafe research). Computer przejmuje te zabezpieczenia, które zostały poddane audytowi przez Trail of Bits (Perplexity).

Na urządzeniu: Portable Computer

Portable Computer to agent działający w pierwszej kolejności lokalnie (local-first): model, harness, konwersja i ścieżka pozostają domyślnie na maszynie użytkownika. Deterministyczny orkiestrator, będący kodem harnesa, a nie modelem LLM, uruchamia pętlę i egzekwuje zasady. Model proponuje działania, a zatwierdzone wywołania narzędzi są uruchamiane w piaskownicy na poziomie systemu operacyjnego, która ogranicza procesy, ścieżki plików i dostęp do sieci. Piaskownica jest stale włączona i domyślnie zamknięta w przypadku awarii: jeśli jest niedostępna, harness wyłącza się samoczynnie zamiast uruchamiać polecenia z uprawnieniami użytkownika. Działania wykraczające poza granicę urządzenia, takie jak wyszukiwanie w internecie, łączniki i eskalacja do silniejszego modelu doradczego w chmurze, mają miejsce tylko wtedy, gdy użytkownik je włączy i zatwierdzi. Przed wywołaniem doradcy klasyfikator PII oznaczy wrażliwe informacje, a użytkownik zobaczy, co zostanie wysłane. Doradca otrzymuje tylko ten zatwierdzony kontekst i zwraca wytyczne tekstowe, nie mając dostępu do plików ani narzędzi urządzenia.

Na punkcie końcowym: Numbat

Agenci kodujący na laptopach deweloperów działają przez wiele godzin, mając dostęp do kodu źródłowego, danych uwierzytelniających i systemów produkcyjnych. Numbat, nasz pakiet bezpieczeństwa dla agentów typu open-source, dodaje niezależną warstwę znajdującą się poza każdym pojedynczym agentem. Współpracuje z harnessami, takimi jak Claude Code, Codex, OpenCode i Pi, blokuje niebezpieczne działania przed ich uruchomieniem, sygnalizuje podejrzane sekwencje wieloetapowe (takie jak odczytanie sekretu, a następnie wysłanie danych na zewnątrz) oraz zachowuje osie czasu sesji do celów dochodzeniowych. Numbat działa na tysiącach punktów końcowych Perplexity obok Bumblebee, naszego skanera łańcucha dostaw typu open-source. Computer regularnie przegląda ich ustalenia i proponuje ulepszone reguły wykrywania, a człowiek zatwierdza każdą zmianę przed jej wdrożeniem.

Zadanie dla całej branży

Ponieważ agenci AI stają się coraz bardziej zdolni i powszechnie używani, inżynieria bezpieczeństwa musi pozostać centralnym elementem ich rozwoju i wdrażania. Badacze i inżynierowie mogą opierać się na ugruntowanych zasadach, wykorzystywać ustalenia z rzeczywistego świata do udoskonalania mechanizmów obronnych oraz testować zabezpieczenia w środowiskach, w których działają agenci. Bezpieczeństwo to ciągła dyscyplina inżynieryjna, która rozwija się wraz z technologią.

Inżynieria bezpieczeństwa dla agentów to zadanie dla całej branży. Żadna pojedyncza firma nie kontroluje pełnego stosu, na którym działa agent. Twórcy modeli, twórcy harnesów, dostawcy piaskownic i środowisk uruchomieniowych, dostawcy chmury i sprzętu oraz korporacyjne zespoły ds. bezpieczeństwa – każdy z nich odpowiada za jedną warstwę. Bezpieczeństwo całości zależy od tego, czy każda warstwa utrzyma się, gdy inna zawiedzie. Właśnie dlatego budujemy zabezpieczenia, które działają w różnych harnessach agentów i udostępniamy nasze narzędzia jako open-source. To także powód, dla którego ujawniamy słabości znalezione na innych platformach i bierzemy udział w inicjatywach takich jak Open Secure AI Alliance.

Aby współpracować z szerszą społecznością nad tymi wyzwaniami, w marcu 2026 roku Perplexity powołała do życia Secure Intelligence Institute, którego zadaniem jest badanie bezpieczeństwa, wiarygodności i praktycznej obrony zaawansowanych systemów AI (Perplexity). Perplexity obecnie współpracuje z badaczami akademickimi z Uniwersytetu Stanforda, CMU, Duke, Columbia, Ohio State i Uniwersytetu Wirginii oraz/lub ich finansuje. Prowadzimy również badania wewnętrzne, aby poszerzać granice badań nad bezpieczeństwem agentów, przekładać te postępy na konkretne ulepszenia w systemach Perplexity oraz dzielić się wiedzą i zasobami, które pomagają wzmocnić szerszy ekosystem AI. Bezpieczniejsi agenci to coś, co branża może zaprojektować. Zamierzamy nadal wnosić swój wkład i zapraszamy innych do budowania razem z nami.