Agent AI, który pisze i wykonuje własny kod, jest bezpieczny tylko w takim stopniu, w jakim bezpieczne jest środowisko, w którym ten kod działa. W samouczku opublikowanym przez Machine Learning Mastery autor pokazuje, jak izolować ten kod na trzech poziomach: ograniczonym podprocesie, utwardzonym kontenerze Docker i mikro-maszynie wirtualnej Firecracker, a następnie porównuje ich bezpieczeństwo i opóźnienia.
Podproces to poziom najlżejszy: jest to proces potomny, którego czas obliczeń, pamięć i rozmiar plików są ograniczone, ale który współdzieli jądro i pliki maszyny hosta. Kontener dodaje przestrzenie nazw i grupy kontrolne (cgroups), ale pozostaje zbiorem procesów na jądrze hosta. Artykuł przypomina, że w listopadzie 2025 roku trzy luki w silniku wykonawczym runc pozwoliły atakującym na ucieczkę z kontenerów. Mikro-maszyna wirtualna daje każdemu środowisku własne jądro, za hipernadzorcą – oprogramowaniem uruchamiającym maszyny wirtualne.
Mechanizm opiera się na jednym narzędziu, run_python, udostępnionym agentowi. Każdy kod wygenerowany przez model przechodzi przez obiekt „sandbox » z metodą run(code), tak że zmiana poziomu izolacji nie modyfikuje agenta. Samouczek wymaga Pythona 3.10 lub nowszego, systemu Linux lub WSL dla poziomu podprocesu, Dockera dla kontenera oraz konta i klucza API E2B dla mikro-maszyny wirtualnej. Klucz API Anthropic jest przydatny dla agenta, ale można go pominąć w testach.
Sześć identycznych ataków na każdym poziomie
Aby porównać trzy poziomy, wykonano te same sześć wrogich programów: nieskończoną pętlę, alokację 512 MB pamięci, „fork flood » 200 procesów, zapis pliku o rozmiarze 50 MB, odczyt fałszywego pliku z danymi uwierzytelniającymi i połączenie z fałszywą usługą wewnętrzną. Atak uznaje się za zablokowany, gdy słowo-znacznik nie pojawia się w danych wyjściowych lub, w przypadku nieskończonej pętli, gdy wykonanie przekroczy limit czasu.
Na poziomie podprocesu, uruchomionym ze zwykłym użytkownikiem Linuxa, cztery ataki są blokowane, a dwa przechodzą. Limit procesów dotyczy tylko dedykowanego użytkownika, więc fork flood jest dozwolony, a fałszywy plik z danymi uwierzytelniającymi pozostaje czytelny, ponieważ kod działa z tożsamością użytkownika. Autor wyciąga wniosek, że ten poziom nadaje się głównie do kodu, któremu ufamy.
Dla kontenera Docker autor wskazuje, że przy wybranych opcjach Docker powinien zablokować wszystkie sześć ataków, ponieważ kontener nie ma sieci, jego system plików nie zawiera plików użytkownika, a limity pamięci, procesów i dysku mają zastosowanie. W mikro-maszynie wirtualnej ataki na pamięć, procesy i dysk mogą osiągnąć limity maszyny wirtualnej, ale pozostają w niej zamknięte, a tajny plik i lokalna usługa w niej nie istnieją.
Opóźnienie i wybór poziomu
Podproces powinien być najszybszy, ponieważ tylko uruchamia Pythona. Dla dwóch pozostałych poziomów autor precyzuje, że opublikowane liczby to twierdzenia, a nie gwarancje: cytowany artykuł wskazuje, że E2B startuje w około 150 ms, podczas gdy AWS i Docker opisują niemal natychmiastowe uruchamianie dla swoich produktów z mikro-maszynami wirtualnymi. Skrypt bench.py pozwala zmierzyć na własnej maszynie medianę i najdłuższy czas z dziesięciu uruchomień programu print(1).
Autor zaleca zarezerwowanie podprocesu dla zaufanego kodu, takiego jak osobiste skrypty deweloperskie, a utwardzonego kontenera dla przypadków, gdy kontrolujemy hosta i stawki są niskie, dbając o aktualizację runc. Mikro-maszyna wirtualna jest konieczna dla kodu pochodzącego od wielu użytkowników, dla wszystkiego, co dotyczy tajemnic, oraz gdy agent musi sam budować i uruchamiać kontenery, co tradycyjne kontenery radzą sobie z tym źle według Dockera. Docker uruchomił swoje Docker Sandboxes na mikro-maszynach wirtualnych w kwietniu 2026 roku, a AWS oferuje Lambda MicroVMs, które zachowują stan do 8 godzin i zawieszają się podczas bezczynności. Według Dockera pliki, reguły sieciowe i sekrety muszą być zdefiniowane przez infrastrukturę, a nie przez agenta, przed jego wykonaniem.
