Perplexity otwiera SPACE - sandbox dla agentów AI

Perplexity udostępniła na GitHubie kod źródłowy SPACE – platformy, na której działają wszystkie zadania wykonywane w ramach Perplexity Computer. Projekt trafił do sieci na licencji Apache 2.0, a jego znaczenie wykracza poza samo narzędzie: to gotowa do wdrożenia produkcyjnego warstwa izolacji, którą zespoły budujące agentów kodujących lub przeglądających sieć mogą postawić u siebie.

SPACE, czyli Sandboxed Platform for Agentic Code Execution, powstała w Rusta i osiągnęła wersję 0.8.0 – publiczną bazę, od której zaczyna się dalszy rozwój. Platforma wystawia API HTTP oraz strumieniowanie zdarzeń server-sent events, a uruchomić ją można wyłącznie na hoście Linux x86_64 z KVM, urządzeniem /dev/kvm, systemem plików btrfs oraz Dockerem. Warianty wdrożenia obejmują lokalny klaster Kind (Kubernetes) albo tryb bezpośredni. Użytkownicy macOS muszą obejść się smakiem.

Jak działa izolacja zadań agentów w SPACE

Każde zadanie powierzone agentowi trafia do odrębnej mikromaszyny wirtualnej Firecracker z własnym jądrem gościa. To fundamentalna różnica względem podejść opartych na kontenerach – granica izolacji przebiega na poziomie hiperwizora, a nie przestrzeni nazw systemu operacyjnego. Nad ruchem wychodzącym czuwa brama sieciowa działająca po stronie hosta, która weryfikuje politykę dostępu przy każdym połączeniu.

Kluczowa decyzja architektoniczna dotyczy sekretów: poświadczenia nigdy nie trafiają do wnętrza maszyny gościa. Zgodnie z lipcowym wpisem inżynierskim Perplexity są wstrzykiwane na poziomie sieci, a magazyn danych uwierzytelniających oferuje hierarchiczne zakresy uprawnień, limity zapytań i rejestrowanie zdarzeń audytowych. Agent może więc działać z uprawnieniami roota wewnątrz sandboxa, ale host pozostaje poza jego kontrolą.

Cztery stany cyklu życia sandboxa

Środowiska przechodzą przez cztery fazy: działanie, pauzę, zawieszenie i usunięcie. W trybie pauzy pamięć maszyny pozostaje w zasobach workera, ale nie stanowi trwałego zrzutu. Zawieszenie tworzy snapshot pamięci, stanu runtime i głównego systemu plików, zwalniając aktywne zasoby. Domyślnie bezczynny sandbox ulega zawieszeniu po sześciu godzinach.

Szybkie tworzenie nowych środowisk umożliwiają pule ciepłych, już wystartowanych sandboxów w wdrożeniach kubernetesowych oraz snapshoty bazowe w konfiguracjach jednomaszynowych. Efekt? Mediana opóźnienia tworzenia spadła w produkcji ze 185 ms do 60 ms względem poprzedniego dostawcy, a dziewięćdziesiąty percentyl skrócił się z 447 ms do 89 ms. Wszystkie sesje Perplexity Computer działają obecnie na SPACE.

Red team: co pokazały testy ucieczki z sandboxa

Perplexity poddała własną platformę testom ofensywnym, opisując wyniki w raporcie „Escaping SPACE: Part I”. Badanie objęło dziewięć modeli frontier działających z uprawnieniami roota wewnątrz gościa, 216 przebiegów w dwóch zadaniach i czterech konfiguracjach sieciowych.

Ucieczka z sandboxa: żaden ze 108 przebiegów nie dotarł do sekretu po stronie hosta.
Całkowita blokada sieci: zero udanych obejść na 54 próby.
Sieć częściowa: przed poprawkami agenci omijali politykę ruchu wychodzącego w 11 z 54 przebiegów – sztuka ta udała się czterem modelom.

Wśród modeli, którym udało się znaleźć lukę, raport wymienia Claude Opus 5.0, GPT-5.6 Sol, GPT-5.6 Cyber oraz Kimi K3. Ataki opierały się na fałszowaniu DNS i współdzielonych adresach IP sieci CDN. Perplexity zareagowała, dodając walidację adresu źródłowego przez nftables, a brama sieciowa zaczęła terminować TLS i porównywać zarówno SNI, jak i nagłówek HTTP host z listą dozwolonych. W retestach żaden model nie uzyskał potwierdzonego obejścia.

Ten sam zespół sprawdził dziesięć zewnętrznych platform sandboxowych. W ośmiu przypadkach wykryto co najmniej jedno obejście polityki sieciowej. Perplexity poinformowała o wynikach wszystkich zainteresowanych dostawców.

SPACE na tle innych otwartych sandboxów

Na rynku otwartych środowisk izolacji dla agentów jest tłoczno, ale szczegóły implementacji mocno różnią się między projektami. E2B Runtime stawia na Firecracker z natywnym wsparciem SDK, Daytona korzysta z libkrun, a microsandbox również sięga po Firecracker – przy czym publiczne repozytorium tego ostatniego pozostaje nieutrzymywane od czerwca 2026 roku.

Wspólnym mianownikiem jest licencja Apache 2.0, ale różnice widać w kontroli ruchu wychodzącego. SPACE stosuje bramę per sandbox z terminacją TLS, E2B opiera się na firewallu nftables z listami SNI i Host, a pozostałe projekty nie ujawniają szczegółów. W testach egress Perplexity wypadła najlepiej po wdrożeniu poprawek – zero obejść. E2B odnotowało obejście HTTPS z planowaną mitygacją, Daytona radziła sobie z HTTP i HTTPS w wersji 0.6.18, a microsandbox również zaliczył obejście HTTPS z wydanym rozwiązaniem.

Jak wdrożyć SPACE u siebie

Instalacja przewiduje deployment do lokalnego klastra Kind. Host musi udostępniać /dev/kvm, /dev/net/tun, urządzenia loop oraz btrfs. Uruchomienie wewnątrz maszyny wirtualnej wymaga zagnieżdżonej wirtualizacji. Zespoły korzystające już z E2B mogą przetestować wrapper kompatybilności ECW, którego bazą referencyjną jest pakiet Pythona e2b w wersji 2.21.1. W repozytorium znajdziemy też przykładowe wdrożenie na AWS EKS.

Co to oznacza dla budujących agentów AI

Publikacja SPACE zmienia układ sił w warstwie infrastruktury dla agentów. Zespoły, które do tej pory same składały izolację z kontenerów i firewalli, dostają sprawdzony w boju komponent – z udokumentowanymi wynikami red teamu i jasno opisanymi ograniczeniami. To szczególnie istotne, gdy agenci wykonują nieprzewidywalny kod, instalują pakiety i odwołują się do zewnętrznych usług z uprawnieniami roota.

Nie bez znaczenia jest też sygnał rynkowy: Perplexity ujawniła luki w ośmiu z dziesięciu konkurencyjnych platform. To przypomnienie, że izolacja agentów to wciąż młoda dziedzina, w której „działa w demo” nie znaczy „jest bezpieczne w produkcji”. Otwarty kod i publiczny raport z testów pozwalają społeczności zweryfikować te zapewnienia samodzielnie – i to prawdopodobnie najważniejszy efekt tej publikacji.