Sandbox dla agentów AI: bezpieczna architektura wykonania

Sandbox dla agentów AI ogranicza skutki błędnego planu, prompt injection i złośliwego kodu. Sam kontener nie jest pełną granicą bezpieczeństwa: agent może nadal mieć sieć, sekrety, socket runtime’u lub nadmiernie szeroki mount.

Warstwy izolacji

Uruchamiaj każde zadanie w efemerycznym środowisku z nieuprzywilejowanym użytkownikiem, read-only base image i osobnym wolumenem roboczym. Usuń Linux capabilities, zablokuj privileged, ogranicz syscall przez seccomp i zastosuj AppArmor/SELinux.

Nie montuj socketu Dockera ani katalogu domowego. Pliki wejściowe kopiuj do katalogu kwarantanny, a wynik eksportuj dopiero po walidacji.

Sieć i sekrety

Domyślnie blokuj egress. Allowlista powinna zawierać konkretne domeny, porty i metody, z ochroną przed DNS rebinding oraz dostępem do metadata service. Proxy rejestruje rzeczywisty cel po rozwiązaniu DNS.

Sekret przekazuj bezpośrednio do narzędzia, z TTL i minimalnym scope. Model nie powinien widzieć tokenu. Po zakończeniu zadania tożsamość oraz środowisko są usuwane.

Budżety wykonania

Ustaw limity CPU, pamięci, procesów, miejsca, czasu, tokenów, retry i wywołań narzędzi. Circuit breaker zatrzymuje pętlę, gdy agent nie zbliża się do kryterium sukcesu.

Każda operacja wysokiego wpływu powinna wychodzić z sandboxa jako propozycja wymagająca osobnej autoryzacji. Sandbox nie nadaje prawa do produkcji.

Testy

Przetestuj escape, symlink traversal, fork bomb, pobranie payloadu, połączenie z metadata, odczyt sekretów procesu i exfiltrację przez DNS. Powtarzaj test po zmianie obrazu, runtime’u i polityki.

OWASP zaleca arbitralny kod uruchamiać wyłącznie w izolacji oraz ograniczać narzędzia zgodnie z least privilege. Uzupełnij sandbox o tożsamości agentów i playbook incydentu AI.

Granice zaufania w architekturze

Rozrysuj osobno model, orkiestrator, executor narzędzi, magazyn artefaktów, proxy sieciowe i system zatwierdzeń. Model proponuje działanie, ale nie powinien sam egzekwować polityki. Executor waliduje nazwę narzędzia, schemat argumentów, tożsamość zadania i aktualną decyzję autoryzacyjną. Dzięki temu tekst z dokumentu lub strony nie może samodzielnie poszerzyć uprawnień.

Środowisko uruchomieniowe powinno powstawać dla jednego zadania i jednego tenantu. Nie współdziel cache, katalogu roboczego ani procesu przeglądarki między użytkownikami. Wyjściowy artefakt nie trafia automatycznie do kolejnego systemu: najpierw przechodzi kontrolę typu pliku, rozmiaru, symlinków, zawartości aktywnej i danych wrażliwych.

Przykładowa polityka wykonania

Domyślna decyzja to odmowa. Polecenie może korzystać tylko z zatwierdzonego obrazu, nieuprzywilejowanego UID, ograniczonego katalogu roboczego i jawnie wskazanego profilu sieci. Każde odstępstwo — dodatkowa domena, zapis poza workspace, dłuższy czas lub nowy sekret — tworzy osobny wniosek do autoryzacji. Zgoda jest związana z konkretnym zadaniem i wygasa, zamiast stawać się trwałym uprawnieniem agenta.

Loguj identyfikator zadania, wersję obrazu i polityki, wywołane narzędzie, znormalizowane argumenty, decyzję, zużycie zasobów i wynik eksportu. Nie zapisuj pełnych sekretów ani nieograniczonej treści promptów. Telemetria musi pochodzić z middleware i executora, nie z narracji modelu.

Test odbiorczy sandboxa

Przed wdrożeniem uruchom zestaw negatywny: dostęp do host filesystem, socketu kontenerów, adresów link-local i metadata, innych tenantów, urządzeń, procesu nadrzędnego oraz niedozwolonego DNS. Sprawdź limity procesów, pamięci, dysku, czasu i liczby połączeń. Następnie wymuś awarię w połowie zadania i potwierdź, że środowisko, tożsamość oraz tymczasowe sekrety zostały usunięte.

Sandbox ogranicza skutek błędu, ale nie zastępuje walidacji celu, kontroli człowieka i bezpiecznej konstrukcji narzędzi. Traktuj go jako jedną z kilku niezależnych barier.

Minimalny kontrakt narzędzia

Każde narzędzie wystawione agentowi powinno mieć jednoznaczną nazwę, zamknięty schemat wejścia, limit wielkości i listę możliwych skutków. Unikaj uniwersalnego run_command, jeśli można udostępnić węższą operację, na przykład odczyt konkretnego artefaktu lub uruchomienie zatwierdzonego testu. Im bardziej ogólne narzędzie, tym więcej kontroli musi przejąć executor.

Odpowiedź narzędzia zawiera status, ustrukturyzowane dane i identyfikator dowodu. Nie powinna zwracać sekretu ani arbitralnej instrukcji do następnego kroku. Błędy normalizuj, aby stos technologiczny i ścieżki hosta nie trafiały bez potrzeby do kontekstu modelu.

Utrzymanie i odpowiedzialność

Wyznacz właściciela obrazu bazowego, polityki sieciowej, profilu seccomp i zestawu testów. Aktualizacja runtime’u jest zmianą bezpieczeństwa, więc wymaga ponownego testu izolacji oraz kontroli eksportu. Mierz czas życia sandboxa, liczbę odmów, próby niedozwolonego egressu i przypadki przekroczenia budżetu.

Raz na kwartał przeprowadź próbę incydentu: znajdź zadania uruchomione na podatnym obrazie, unieważnij ich tożsamości, zablokuj wersję i odtwórz artefakty. Architektura jest gotowa dopiero wtedy, gdy zespół umie nie tylko zatrzymać wykonanie, lecz także ustalić jego zasięg.

---

Źródła: OWASP AI Agent Security Cheat Sheet, NIST — Agentic AI Emerging Threats.