Sandboxing agentów

1. Przegląd koncepcji i problem systemowy

Autonomiczne agenty ujawniają swój pełny potencjał dopiero wtedy, gdy mają możliwość wykonywania poleceń systemowych w terminalu, pisania kodu, instalowania pakietów oraz testowania aplikacji w czasie rzeczywistym. Jednakże przyznanie agentowi bezpośredniego dostępu do systemu hosta dewelopera lub serwera stanowi krytyczne ryzyko dla bezpieczeństwa informacji:

1. Nieprzewidywalność LLM: Model może wygenerować destrukcyjne polecenie na skutek halucynacji (np. przypadkowe rekurencyjne rm -rf na błędnie sformułowanej ścieżce).
2. Ataki Indirect Prompt Injection: Jeśli agent analizuje zewnętrzne strony internetowe lub czyta repozytoria GitHub należące do osób trzecich, ukryty w treści złośliwy prompt może nakazać modelowi odczyt plików ~/.ssh/id_rsa, .env i przesłanie ich na zdalny serwer atakującego za pomocą curl.
3. Wyczerpanie zasobów hosta: Nieskończona pętla lub Fork Bomb mogą sparaliżować działanie całego serwera.

Agent Sandboxing rozwiązuje ten konflikt, zapewniając agentowi całkowicie bezpieczne, izolowane, jednorazowe (ephemeral) środowisko.

2. Taksonomia architektoniczna i model mentalny

W zależności od wymagań dotyczących bezpieczeństwa i szybkości uruchamiania wyróżnia się cztery poziomy izolacji architektonicznej:

• 1. Izolacja procesowa OS (Namespaces & Cgroups, Bubblewrap): Podstawowe oddzielenie systemu plików, PID oraz limitów pamięci wewnątrz Linuxa. Oferuje najszybsze uruchomienie (<50 ms), ale nie chroni przed exploitami na poziomie jądra.
• 2. Wirtualizacja na poziomie jądra (gVisor / User-space Kernel): Specjalna warstwa opracowana przez Google, która emuluje jądro Linuxa w przestrzeni użytkownika. Każde wywołanie systemowe (syscall) jest filtrowane i nie kontaktuje się z rzeczywistym jądrem hosta.
• 3. Sprzętowe MicroVM (AWS Firecracker, Kata Containers): Złoty standard bezpieczeństwa w chmurze. Prawdziwa, minimalistyczna maszyna wirtualna z własnym jądrem Linuxa, uruchamiająca się w 100–150 ms i całkowicie izolowana na poziomie sprzętowego hypervisora KVM.
• 4. WebAssembly (Wasm / WASI Runtimes): Wykonywanie kodu wewnątrz izolowanego bytecode’u (np. Wasmtime). Idealne do bezpiecznego uruchamiania JavaScript/Python bez systemu operacyjnego, choć obarczone ograniczeniami w zakresie wywołań narzędzi systemowych.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia izolowanego wykonania zadania składa się z 4 etapów:

1. Ephemeral Provisioning (Szybkie wdrożenie): Orkiestrator tworzy świeży egzemplarz mikrokontenera z wcześniej przygotowanego snapshot-image zawierającego skonfigurowane środowisko (Node.js, Python, Git).
2. Virtual Workspace Mount & Secret Redaction (Montowanie środowiska): Do piaskownicy montowany jest wyłącznie folder roboczy bieżącego projektu. Wszystkie rzeczywiste tokeny dostępu (klucze AWS, dane uwierzytelniające do produkcyjnej bazy danych) są podmieniane na mockowe lub jednorazowe, ograniczone tokeny.
3. Execution & Syscall Interception (Kontrolowane wykonanie): Agent wysyła polecenie poprzez gRPC lub WebSocket API. Sterownik piaskownicy wykonuje komendę, streamuje stdout/stderr do agenta, automatycznie przerywając wykonanie, jeśli proces przekroczy limit czasu (Execution Timeout) lub pamięci (OOM Watchdog).
4. Instant Teardown & Garbage Collection (Pełne oczyszczenie): Po zakończeniu zadania cały kontener jest nieodwracalnie niszczony wraz ze wszystkimi tymczasowymi artefaktami. Żaden stan nie przechodzi do kolejnej sesji.

4. Praktyczne scenariusze inżynierskie w produkcji

01. Bezpieczny Code Interpreter dla użytkowników

Serwis pozwala użytkownikom na przesyłanie tabel CSV/Excel i proszenie agenta o napisanie skryptu Python do złożonej wizualizacji. Kod jest uruchamiany w mikrokontenerze E2B bez ryzyka odczytu plików innych użytkowników.

02. Autonomiczne testowanie repozytoriów zewnętrznych i PR

Agent automatycznie pobiera Pull Request, wykonuje npm install i przeprowadza testy. Jeśli w zależnościach znajduje się złośliwy skrypt preinstall (Supply-chain attack), atak rozbije się o ściany piaskownicy.

03. Izolowany web scraping i browsing

Agent wykorzystuje Headless Chromium do przeglądania niebezpiecznych stron w sieci. Przeglądarka działa w izolowanym kontenerze bez dostępu do systemowego menedżera haseł ani korporacyjnego VPN.

5. Pułapki, typowe błędy i bezpieczeństwo

• Network Egress SSRF Leaks (Przeciek adresów wewnętrznych): Domyślnie kontener może pingować lokalną sieć hosta. Konieczne jest skonfigurowanie surowej polityki ruchu egress (Network Isolation), blokującej dostęp do localhost oraz podsieci metadanych chmury.
• Nierównowaga Latency vs Security: Pełnoprawne maszyny wirtualne uruchamiają się przez sekundy, co frustruje użytkownika. Stosuj pulę „podgrzanych” kontenerów (Warm Pools) lub technologię Forking MicroVM dla natychmiastowej odpowiedzi.
• Resource Starvation (Fork Bombs): Agent lub skrypt może nieskończenie mnożyć procesy (:(){ :|:& };:). Zawsze rygorystycznie limituj maksymalną liczbę procesów (pids_limit) oraz pamięć (mem_limit).