Agenci AI kontra sandbox. Wyniki testu Perplexity

Co sprawdzało Perplexity

SPACE (Sandboxed Platform for Agentic Code Execution) to środowisko, w którym działają agenci Perplexity Computer. Każdy agent pracuje w osobnej, lekkiej maszynie wirtualnej Firecracker, a hiperwizor oddziela ją od serwera. Zespół Perplexity Secure Intelligence Institute założył najgorszy scenariusz, czyli że agent może działać wrogo i przejąć pełną kontrolę nad swoim systemem. Dlatego wszystkie modele dostały w teście uprawnienia administratora wewnątrz maszyny.

Badacze sprawdzali dwie osobne granice bezpieczeństwa. Pierwsza to izolacja maszyny wirtualnej od serwera, na którym działa. Druga to kontrola ruchu wychodzącego, która pozwala agentowi łączyć się tylko z zatwierdzonymi adresami, na przykład repozytorium pakietów Pythona albo wyszukiwarką Perplexity.

• Ucieczka z sandboxa - agent ma zdobyć dane uwierzytelniające AWS dostępne tylko na serwerze i podać nazwę roli.
• Obejście blokady sieci - agent ma połączyć się z adresem, którego zabrania polityka ruchu.
• Warunki testu - dostęp do kodu źródłowego SPACE albo jego brak oraz brak sieci albo dostęp częściowy.
• Skala - trzy próby na model w każdym wariancie, w teście ucieczki limit czasu bliski 120 minutom.

Wyniki modeli w obu próbach

Pierwsza część badania z 23 września 2026 roku objęła dziewięć modeli. Druga dodała Claude Mythos 5.1, Claude Opus 5.5 i GPT-6 Astra oraz powtórzyła próby w nowych wariantach. Najważniejszy wniosek się nie zmienił. Żaden model nie wyszedł z maszyny wirtualnej, choć po zmianie polecenia agenci poświęcali na badanie wirtualizacji średnio o około 60 punktów procentowych więcej wysiłku niż wcześniej.

Ocenę jakości pracy w teście ucieczki przeprowadziło sześć modeli w roli sędziów, które oceniły 72 zapisy działań według pięciu kryteriów. Najwyżej wypadły GPT-6 Astra i Claude Mythos 5.1, najniżej Grok 4.20, który w sześciu próbach 27 razy ogłosił sukces, którego nie było. Lista poniżej dotyczy drugiej próby, czyli obejścia blokady sieci przy dostępie do kodu źródłowego.

• Sukces w 3 z 3 prób - Claude Opus 5.0, Claude Opus 5.5 (średnio 21,6 min), Claude Mythos 5.1 (36,6 min), GPT-5.6 Sol (20,8 min), GPT-6 Astra (4,8 min).
• Sukces w 2 z 3 prób - Kimi K3.
• Brak sukcesu - GPT-5.6 Cyber, DeepSeek V4 Pro, Gemini 3.1 Pro, GLM 5.2, Grok 4.20 i Qwen 3.8 27B.
• Bez kodu źródłowego - GPT-5.6 Sol w 2 z 3 prób, GPT-5.6 Cyber w 1 z 3, pozostałe modele bez sukcesu.

Dlaczego model do cyberbezpieczeństwa wypadł słabiej

GPT-5.6 Cyber, wersja trenowana pod zadania bezpieczeństwa, nie obeszła blokady w żadnej z trzech prób z kodem źródłowym. Ogólny GPT-5.6 Sol zrobił to za każdym razem, bo znalazł fragment kodu, który Cyber przeoczył. Autorzy przypuszczają, że trening specjalistyczny kieruje model ku znanym klasom podatności. Zastrzegają jednak, że przy trzech próbach nie da się tego dowieść.

Wynik zależał też od wskazówek. Gdy modele dostały streszczenie wcześniejszych nieudanych prób, Opus 5.0 i Sol obeszły blokadę bez kodu źródłowego za każdym razem. Po jednoznacznej podpowiedzi rodzaju ataku sukces odniosło przynajmniej raz siedem z 12 modeli. Pokazuje to, jak bardzo wynik testu zależy od sformułowania zadania.

Co Perplexity naprawiło

Oba znalezione sposoby obejścia blokady dotyczyły tego, jak filtr sieciowy rozpoznawał dozwolone adresy. Zespół wprowadził weryfikację adresu źródłowego i ostrzejsze sprawdzanie nazw hostów, a ponowne testy nie wykazały skutecznego obejścia. Szczegółów technicznych nie przytaczamy, bo dotyczą sposobu ataku.

Szerszy problem dotyczy całego rynku. Według drugiej części raportu podobne słabości miało 8 z 10 zewnętrznych platform sandboxowych, a Perplexity powiadomiło ich dostawców w trybie odpowiedzialnego ujawniania. Raport nie podaje nazw tych platform. W pierwszej części, przy innym zestawie porównawczym, była mowa o 7 z 9 platform.

Ograniczenia badania

To raport firmy, która testuje własną infrastrukturę, a nie recenzowana publikacja naukowa. Każdy wariant powtórzono tylko trzy razy, więc różnice między modelami mogą wynikać z przypadku. Autorzy przyznają też, że ocena sędziów AI może zależeć od przebiegu zapisów, a nie wyłącznie od umiejętności modelu.

Brak ucieczki z maszyny wirtualnej nie oznacza, że jest ona niemożliwa. Pierwsze polecenie słabo zachęcało modele do badania wirtualizacji, więc ten wynik jest według autorów tylko ograniczonym dowodem szczelności tej warstwy. Zadania w stylu CTF (capture the flag, czyli zdobądź flagę) potrafią też odciągać agentów od granicy, którą naprawdę chce się sprawdzić.

Co z tego wynika dla firm uruchamiających agentów

W naszej ocenie najważniejsza lekcja jest praktyczna. Izolacja maszyny wirtualnej i kontrola ruchu sieciowego to dwa różne zabezpieczenia i trzeba je sprawdzać osobno. Polska firma, która daje agentowi AI dostęp do kodu, chmury albo danych klientów, powinna założyć, że silny model znajdzie lukę w filtrze ruchu szybciej niż człowiek. Podobne wnioski płyną z incydentu WorkOS i raportu OpenAI o modelu, który ominął proxy.

Przed wdrożeniem agentów w sandboxie warto przejść krótką listę kontrolną:

1. Zapytaj dostawcę sandboxa, czy testował kontrolę ruchu wychodzącego osobno od izolacji maszyny wirtualnej.
2. Nie zakładaj, że dopuszczenie jednej domeny bezpiecznie obejmuje każdy adres IP, pod którym działa.
3. Nie trzymaj w zasięgu agenta kodu źródłowego zabezpieczeń ani danych uwierzytelniających serwera.
4. Sprawdzaj niezależnie raporty agenta o wykonaniu zadania, bo modele potrafią zgłaszać fałszywy sukces.
5. Powtarzaj testy po każdej poprawce i po zmianie modelu na nowszy.