Sandboxing agenta: izolacja to nowa warstwa bezpieczeństwa runtime

Większość rozmowy o bezpieczeństwie agentów dotyczy zapobiegania: jak powstrzymać złośliwą instrukcję — ukrytą w stronie internetowej, w pliku, w wyniku narzędzia — przed przejęciem twojego agenta. To słuszny instynkt, a badania z 2026 roku mają na to głęboko niewygodną odpowiedź. Prawdopodobnie nie potrafisz. Nie niezawodnie, nie wobec zmotywowanego napastnika i być może nigdy. Co oznacza, że pytaniem o bezpieczeństwo wartym największej części twojej uwagi nie jest „jak powstrzymać injection?”. Brzmi ono „gdy injection trafi, ile agent faktycznie może zniszczyć?”.

To przeformułowanie — od zapobiegania do powstrzymywania — jest tą zmianą, która czyni izolację kluczową warstwą bezpieczeństwa stosu agentowego. Nie jedyną warstwą, ale tą, która trzyma, gdy pozostałe zawiodą.

Obrona, która nie może w pełni wygrać

Zacznij od tego, jak zły naprawdę jest problem zapobiegania, bo to uzasadnia wszystko, co następuje. Systematyczna analiza z 2026 roku dotycząca prompt injection wobec agentowych asystentów kodowania — wymieniająca wprost Claude Code, GitHub Copilot i Cursor (arXiv 2601.17548) — przeprowadziła meta-analizę 78 badań z lat 2021–2026 i doszła do bezceremonialnego wniosku: wskaźniki skuteczności ataków wobec najnowocześniejszych zabezpieczeń przekraczają 85%, gdy zastosowane są adaptacyjne strategie ataku. Katalogizuje 42 odrębne techniki ataku, a spośród 18 mechanizmów obronnych, które przejrzała, „większość osiąga poniżej 50% mitygacji wobec wyrafinowanych ataków adaptacyjnych”.

Robi się jeszcze bardziej fundamentalnie. Drugi artykuł z 2026 roku (arXiv 2605.17634) otwiera się płaskim stwierdzeniem, że „prompt injection to najbardziej krytyczna podatność we wdrożonych agentach AI”, a następnie argumentuje coś silniejszego niż „obecne zabezpieczenia są słabe”. Oferuje wynik niemożliwości: ponieważ granica między legalną instrukcją a złośliwą jest kontekstowa, „napastnik zawsze może skonstruować kontekst, w którym zablokowany przepływ wygląda na legalny, albo obrońca, który zaostrza normy, zablokuje przepływy autentycznie legalne”. Innymi słowy, problem zapobiegania nie jest nierozwiązany dlatego, że nie byliśmy dość sprytni. Istnieje pryncypialny argument, że nie da się go w pełni rozwiązać na warstwie instrukcji bez zniszczenia użyteczności agenta.

Nie powinieneś czytać tego jako „zrezygnuj z zapobiegania”. Powinieneś czytać to jako „zapobieganie będzie przeciekać, z założenia — więc buduj pod przeciek”.

Przestań pytać „czy możemy to zablokować?” — zapytaj „jaki jest blast radius?”

Gdy zaakceptujesz, że jakaś część injections się przedostanie, model bezpieczeństwa się odwraca. Przestajesz próbować gwarantować, że agent nigdy nie zrobi złej rzeczy, a zaczynasz ograniczać, ile ta zła rzecz może kosztować. To pytanie o blast radius, a odpowiada na nie runtime, w którym agent się wykonuje, a nie prompt.

Konkretnie: gdy przejęty agent uruchamia komendę powłoki, do czego ta komenda może sięgnąć? Jeśli agent wykonuje się w twoim środowisku produkcyjnym, z twoimi poświadczeniami i twoją siecią, udany injection to włamanie. Jeśli wykonuje się w jednorazowym, sieciowo ograniczonym, pozbawionym poświadczeń sandboxie, który jest niszczony na końcu zadania, ten sam injection to powstrzymany incydent — napastnik dostaje zamknięty pokój z niczym w środku. Ten sam injection, ten sam model, radykalnie inny wynik. Różnicą jest w całości granica izolacji, a tę granicę inżynierujesz, a nie liczysz na to, że model ją poprawnie ustawi.

Dlatego „sandboxuj agenta” po cichu stało się pierwszą prawdziwą kontrolą, a nie ostatnią. To jedyna warstwa, której gwarancja nie zależy od poprawnego sklasyfikowania instrukcji, której — jak mówią badania — często nie potrafisz sklasyfikować. To ta sama logika, jaką bank stosuje wobec szuflady kasjera: szkolisz kasjerów i prześwietlasz pod kątem oszustw, ale także ograniczasz, ile jest w szufladzie, bo zaakceptowałeś, że jakieś złe transakcje się przedostaną, a najtańszym ubezpieczeniem jest ograniczenie tego, ile pojedyncza z nich może zabrać. Limit szuflady nie zależy od złapania oszusta — i to dokładnie dlatego działa.

Spektrum izolacji

Nie każda izolacja jest równa, a wybór to realna decyzja inżynierska. Uruchom niezaufany, wygenerowany przez AI kod, a spektrum biegnie z grubsza od najsłabszego do najsilniejszego: sandboxy procesów OS (Seatbelt, bubblewrap) → zwykłe containery → kernel w przestrzeni użytkownika jak gVisor, który przechwytuje syscalle (silniejsza izolacja, przy typowym narzucie I/O na poziomie 10–30%) → microVM jak Firecracker, które dają każdemu obciążeniu własny prawdziwy kernel poprzez wirtualizację sprzętową (Firecracker startuje jeden w mniej więcej 125 ms) → pełne dedykowane VM. Dla autentycznie niezaufanego albo wygenerowanego przez agenta kodu konsensus ustalił się na microVM jako praktycznym złotym środku: prędkość bliska natywnej przy izolacji klasy VM.

Najjaśniejszym sygnałem, że to teraz mainstream, jest fakt, że platformy to sproduktyzowały. Vercel Sandbox stał się ogólnie dostępny 30 stycznia 2026, zbudowany na microVM Firecracker, gdzie — słowami Vercela — „każdy sandbox jest izolowany, z własnym systemem plików, siecią i przestrzenią procesów”. Startuje w czasie poniżej sekundy, jest stworzony specjalnie do uruchamiania niezaufanego albo wygenerowanego przez AI kodu w krótkotrwałych środowiskach i jest już w produkcji z zespołami od kodowania AI, jak Roo Code i Blackbox AI. Efemeryczność-z-założenia jest kluczową właściwością: świeże, izolowane środowisko na każde zadanie, rozbierane potem, nie daje injection niczego trwałego do skompromitowania ani nigdzie, gdzie mógłby się utrzymać.

Izolacja jest konieczna, ale nie wystarczająca

Uczciwe zastrzeżenie: sandbox kurczy blast radius; nie czyni agenta bezpiecznym. Izolowany agent wciąż może wyciekać dane, które są w jego sandboxie, wciąż może wykonywać szkodliwe połączenia wychodzące, jeśli egress nie jest ograniczony, wciąż może zwrócić zatrutą odpowiedź czemukolwiek, co ją konsumuje. Izolacja to zabezpieczenie awaryjne, a zabezpieczenie awaryjne potrzebuje wokół siebie reszty obrony.

Więc warstwa runtime to naprawdę mały stos kontroli, każda niezależna od osądu modelu: filtrowanie egress (sandbox może rozmawiać tylko z zatwierdzonymi celami), tool allowlists i least privilege (agent trzyma minimum poświadczeń i uprawnień potrzebnych do zadania, a nie token w trybie boga), efemeryczne środowiska (świeże na każde zadanie, niszczone potem) oraz audyt wyjścia (nic, co agent produkuje, nie jest zaufane dalej bez sprawdzenia). I to uzupełnia zabezpieczenia warstwy modelu, zamiast je zastępować — prace takie jak ARGUS (arXiv 2605.03378) pokazują, że dobre zabezpieczenie potrafi obniżyć attack success rate do 3,8%, zachowując 87,5% użyteczności zadania. Sednem wyniku niemożliwości nie jest to, że takie zabezpieczenia są bezwartościowe; to, że redukują częstotliwość, a nie możliwość — więc wciąż zakładasz, że jakieś ataki trafią, a sandbox jest tym, co je łapie, gdy to się stanie.

To runtime’owy odpowiednik argumentów o bezpieczeństwie, które stawialiśmy gdzie indziej. Pisaliśmy o problemie bezpieczeństwa MCP — ryzyku w tym, jak agenci sięgają do narzędzi — oraz o guardrails jako powierzchni produktowej. Sandboxing to warstwa pod obiema: założenie, że guardrails czasem zostaną pokonane, a wywołanie narzędzia czasem będzie złośliwe, więc samo wykonanie musi być powstrzymane. Liczy się jeszcze bardziej, gdy agenci zaczynają delegować innym agentom poprzez otwarte protokoły jak A2A, gdzie kompromitacja może przyjść z odległości trzech przeskoków — jedyną rzeczą, którą w pełni kontrolujesz, jest pudełko, w którym działa twój własny agent.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która liczy się dla tego regionu, i jest to znajomy kształt zaostrzony do punktu. Bezpieczeństwo runtime to konfiguracja i osąd, nie kapitał. Postawienie efemerycznej microVM na każde zadanie, napisanie ciasnej polityki egress, zakreślenie poświadczenia least-privilege, rozebranie środowiska potem — nic z tego nie wymaga frontierowego modelu, GPU ani dużego budżetu. Wymaga inżyniera, który rozumie model zagrożeń i starannie projektuje pudełko. To umiejętność na laptopa i dokładnie ten rodzaj trwałej, wolnej od GPU zdolności, o której wciąż argumentujemy, że region jest dobrze ustawiony, by ją budować.

Kumuluje się to też z suwerennością. Zespół, który prowadzi swoich agentów w samodzielnie hostowanych, izolowanych sandboxach — łącząc modele open-weight na urządzeniu, o których pisaliśmy z izolacją microVM on-premise — trzyma wrażliwe dane wewnątrz własnej granicy oraz powstrzymuje blast radius, jeśli agent zostanie przejęty. Dla kambodżańskiego banku albo ministerstwa wdrażającego agentów na regulowanych danych ta kombinacja nie jest miłym dodatkiem; to wdrażalna architektura. Model może być otwarty, runtime może być lokalny, a izolacja może być szczelna — wszystko na infrastrukturze, którą mały zespół posiada i kontroluje.

Frontierowe laboratoria będą wciąż ścigać się, by uczynić model trudniejszym do oszukania, i ten wyścig warto biec. Ale badania są jasne, że to wyścig, którego nikt w pełni nie wygrywa. Zespół, który to zinternalizuje — który traktuje agenta jako coś, co w końcu zostanie skompromitowane, i inżynieruje runtime tak, by ta kompromitacja była do przeżycia — dostarcza agentów, którym faktycznie może zaufać w produkcji. Ta dyscyplina to najbardziej niedoceniana umiejętność bezpieczeństwa w stosie agentowym, a działa na pudełku, które już posiadasz.