Żadna obrona nie jest doskonała. Prompt injection, permission injection, tool poisoning, context poisoning — wszystkie mają wektory ataku dla których nie istnieje niezawodne rozwiązanie. Nie możesz zagwarantować że agent nigdy nie zostanie przejęty.
Możesz zagwarantować że jeśli zostanie przejęty, wyrządzona szkoda będzie ograniczona.
To jest logika sandboxingu — nie eliminacja ryzyka, ale zawężenie jego konsekwencji. Jeśli agent działa w izolowanym środowisku z minimalnym dostępem do zasobów zewnętrznych, przejęty agent ma mały promień rażenia. Kompromitacja agenta nie jest kompromitacją całego systemu.
Czym jest sandboxing agenta
Sandboxing agenta to zestaw mechanizmów izolacji środowiska wykonawczego agenta AI — ograniczających dostęp do zasobów systemu, sieci, danych i innych agentów — tak że kompromitacja lub błędne działanie agenta ma ograniczony zasięg i nie może rozprzestrzeniać się poza zdefiniowane granice. Implementacja zasady defence in depth dla systemów agentowych.
Warstwy sandboxingu
Izolacja procesów: agent działa w osobnym procesie lub kontenerze bez dostępu do systemu plików hosta, zmiennych środowiskowych innych procesów, ani pamięci innych aplikacji. Konteneryzacja (Docker, containerd) i VM-level isolation (Firecracker, gVisor) to praktyczne implementacje.
Izolacja sieci: agent ma dostęp tylko do określonych endpointów sieciowych — lista allowlist domen i IP do których może się łączyć. Wszystkie inne połączenia są blokowane na poziomie sieci, nie na poziomie kodu agenta. Przejęty agent który próbuje eksfiltrować dane do zewnętrznego serwera trafi na mur sieciowy.
Izolacja danych: agent ma dostęp tylko do danych których potrzebuje do swojego zadania. Dane są przekazywane do agenta w momencie wywołania, nie przez permanentny dostęp do bazy. Agent który przetwarza jedno zamówienie nie ma dostępu do historii wszystkich zamówień.
Izolacja narzędzi: agent może wywoływać tylko narzędzia z zaakceptowanej listy, z z góry zdefiniowanymi uprawnieniami. Nie może dynamicznie dodawać nowych narzędzi ani rozszerzać uprawnień istniejących w trakcie wykonania.
Ograniczenia zasobów: limity CPU, pamięci i czasu wykonania. Agent który wpada w nieskończoną pętlę lub jest wykorzystywany do kryptomining nie może konsumować nieograniczonych zasobów.
Sandboxing a vibe coding
Vibe coding produkuje kod który „działa” — ale który może mieć podatności których twórca nie przewidział. Sandboxing jest odpowiedzią na ten problem nie przez naprawienie kodu, ale przez ograniczenie tego co nawet podatny kod może zrobić.
Agent zbudowany przez vibe coding działający w właściwie skonfigurowanym sandbox — nawet jeśli ma podatność — nie może eksfiltrować danych bo nie ma dostępu do sieci zewnętrznej. Nie może skompromitować systemu hosta bo działa w izolowanym kontenerze. Nie może uzyskać dostępu do danych innych agentów bo każdy ma swój izolowany kontekst.
Sandbox nie zastępuje security review kodu. Ale dla systemów gdzie security review jest trudny lub niemożliwy — w tym dla systemów budowanych przez vibe coding — jest kluczową warstwą defense in depth.
Praktyczne wdrożenie
Dla małych wdrożeń: Claude Code i podobne narzędzia mają wbudowane mechanizmy sandboxingu dla wykonywania kodu. Dla agentów w produkcji — Docker z restrictive security profiles (seccomp, AppArmor) i network policies.
Dla enterprise: Kubernetes z Network Policies i Pod Security Standards, Istio service mesh z mTLS między agentami, AWS Lambda lub Azure Functions jako środowisko wykonawcze z wbudowaną izolacją.
Kluczowa zasada: domyślnie wszystko jest zablokowane. Dostęp do każdego zasobu wymaga jawnej konfiguracji. Nie „zablokuj co niebezpieczne” — „zezwól tylko na to co potrzebne”.