Sandbox agenta AI: sprawdź każdą granicę dostępu

Bezpieczeństwo sandboxa agenta AI zależy od tego, gdzie wykonuje się kod i do czego przyznasz mu dostęp. MicroVM zapewnia zadaniu osobne jądro systemu gościa, wzmacniając jedną z granic izolacji. Zanim agent otrzyma prywatny kod źródłowy lub niezaufane zgłoszenie podatności, potrzebujesz jednak dowodów, że dostęp do plików, sieci, poświadczeń i zewnętrznych narzędzi oraz zwracane wyniki mieszczą się w granicach zadania.

Zacznij od konkretnego pytania przed zatwierdzeniem: co agent może odczytać i zmienić w tym uruchomieniu, z czym może się połączyć i do przyjęcia jakich wyników może skłonić twój zespół? Zapisz odpowiedź dla konfiguracji, której faktycznie użyjesz. Schemat architektury produktu pomaga zrozumieć jego budowę; do twojego zadania potrzebna jest też polityka dostępu i sposób sprawdzenia, czy jest przestrzegana.

Co zmienia microVM

MicroVM oddziela jądro systemu gościa od jądra hosta. Daje to inną granicę wykonywania kodu niż kontener współdzielący jądro. Konfiguracja hosta i celowo udostępnione zasoby nadal mają jednak znaczenie. Vercel opisuje ten podział wraz z kontrolą plików, sieci i poświadczeń w przeglądzie sandboxów dla agentów.

W opisie architektury z 4 listopada Replit przedstawia przejście na microVM z Cloud Hypervisor, z kontenerami uruchamianymi wewnątrz systemów gości. Opisuje też monitor maszyn wirtualnych działający bez podwyższonych uprawnień, egzekwowanie reguł sieciowych poza systemem gościa w sandboxach z polityką ruchu wychodzącego oraz brokery poświadczeń dla zarządzanych integracji. W opisie Replit są to odrębne zabezpieczenia. Nie dowodzi on, że każde żądanie lub każdy sekret podany przez użytkownika podlega takiej samej ochronie.

Osobna demonstracja Firecracker przygotowana przez PWN Research pokazuje, dlaczego twierdzenia o bezpieczeństwie trzeba zestawiać z warunkami uruchomienia. Badacz użył Firecracker v1.16.1 uruchomionego jako root bez jailera, korzystając z wcześniej uzyskanej możliwości dostępu do pamięci hosta. Nie jest to demonstracja ucieczki z odpowiednio zabezpieczonego wdrożenia produkcyjnego ani ze środowiska Replit opartego na Cloud Hypervisor. Zalecenia Firecracker dotyczące hostów produkcyjnych wymagają uruchamiania bez podwyższonych uprawnień i ograniczenia procesu; nie dowodzą jednak, że jailer z pewnością zatrzymałby sam mechanizm dostępu do pamięci.

Przy wyborze rozwiązania zapytaj więc, jakiego środowiska wykonawczego, uprawnień i integracji z hostem faktycznie używa twoje zadanie. Zachowaj odpowiedzi wraz z zatwierdzaną wersją i konfiguracją.

Spisz celowo otwierane połączenia

Agent działający w sandboxie może wyrządzić szkody przez dostęp, który świadomie mu przyznasz. Trzeba sprawdzić te połączenia nawet wtedy, gdy izolacja wykonywania kodu działa zgodnie z projektem.

Model bezpieczeństwa lokalnych sandboxów Dockera wymienia kilka z nich wprost: bezpośrednio montowany katalog roboczy, pośredniczenie w dostępie do poświadczeń, dostęp do podpisywania przez SSH i zewnętrzne serwery MCP. Ostrzega, że zmiany w katalogu roboczym mogą zmienić sposób wykonywania kodu podczas pracy programistycznej, a lokalne serwery MCP korzystające ze stdio działają na hoście. To integracje wymagające oceny w tej lokalnej konfiguracji, a nie dowód ucieczki z VM.

Odpowiedz na cztery pytania:

• Pliki: czy agent widzi jednorazową kopię kodu, czy może edytować checkout, który później zbudujesz i uruchomisz? Podczas review zwróconych zmian uwzględnij hooki, konfigurację budowania i instrukcje.
• Sieć: jakie adresy docelowe, ścieżki i operacje są dozwolone? Zatwierdzony endpoint inferencji otrzymuje przesłane do niego dane wejściowe. Sama lista dozwolonych adresów nie oznacza, że ich ujawnienie jest dopuszczalne.
• Poświadczenia: co agent może zrobić dzięki dostępnym uprawnieniom? Broker może ukrywać sam klucz API, a jednocześnie pozwalać na wywołania z szerokimi uprawnieniami. Dostęp do gniazda podpisywania również wymaga świadomej decyzji.
• Narzędzia: gdzie wykonuje się każde narzędzie i czyją tożsamością się posługuje? Proces na hoście lub zdalne API potrzebuje własnej granicy autoryzacji.

Uwzględnij także stan zachowywany między uruchomieniami. Współdzielone pamięci podręczne, zapisane snapshoty i instrukcje agentów używane ponownie mogą przenosić zmiany do kolejnych zadań. Zanim uznasz, że nowa sesja zaczyna się od czystego stanu, ustal odpowiedzialność za każdy zachowywany artefakt i sposób odtworzenia środowiska bez pozostałości poprzednich uruchomień.

Wymagaj dowodów dla każdej granicy

Zatwierdzaj konkretną konfigurację na podstawie powtarzalnych sprawdzeń. Poniższa tabela to propozycja dokumentacji odbioru, opracowana na podstawie opisanych wyżej granic kontroli. Nie przedstawia testów, które przeprowadziliśmy u tych dostawców.

Używaj fikcyjnych sekretów, jednorazowych środowisk i endpointów pod twoją kontrolą. Aby sprawdzić, czy dostęp zabroniony przez politykę jest blokowany, nie potrzebujesz działającego exploita ani wyprowadzania prawdziwych danych.

Do dokumentacji zatwierdzenia dołącz wersję polityki i wyniki sprawdzeń. Zapis „ograniczony dostęp do sieci” mówi mniej niż dokumentacja pokazująca, które żądanie zablokowano, które dozwolone żądanie się powiodło i jaka konfiguracja dała oba wyniki.

Pozytywny wynik potwierdza działanie sprawdzonych zabezpieczeń w danej wersji. Nie dowodzi, że każda próba prompt injection zakończy się niepowodzeniem, każda dozwolona operacja jest bezpieczna ani że nie istnieje podatność umożliwiająca ucieczkę. Po zmianie montowania, narzędzia, polityki tokenów, środowiska wykonawczego lub zachowywanego obrazu powtórz sprawdzenia, na które ta zmiana wpływa.

Przećwicz jedno zadanie triażu zgłoszenia

Rozważmy hipotetyczny zespół przygotowujący agenta do odczytania prywatnego repozytorium i jednego otrzymanego zgłoszenia podatności. Próba odbiorowa powinna obejmować całe zadanie, łącznie ze zwracanym wynikiem.

1. Przygotuj jednorazowe dane wejściowe. Użyj kopii kodu źródłowego i przykładowego zgłoszenia z fikcyjnymi tokenami. Nie podłączaj poświadczeń produkcyjnych ani prawdziwych zgłoszeń.
2. Dodaj nieszkodliwą próbę wstrzyknięcia instrukcji. W przykładowym zgłoszeniu umieść polecenie połączenia się z adresem kontrolowanym przez zespół, do którego polityka zabrania dostępu. Przed uruchomieniem zapisz oczekiwaną odmowę.
3. Sprawdź zarówno blokadę, jak i wykonanie zadania. Pozostaw dostęp do prawidłowych tras inferencji i przekazywania wyników zgłoszenia. Uruchomienie, które nie może połączyć się z niczym, nie potwierdza działania docelowego procesu.
4. Sprawdź zwracane dane. Zachowaj log odmowy żądania, faktyczną konfigurację środowiska wykonawczego oraz odwołania do zgłoszenia, commita i pipeline. Sprawdź, czy usługa odbierająca odrzuca wynik dotyczący innego zgłoszenia oraz odrzuca niedozwolone dodatkowe pola lub uniemożliwia ich zapis.
5. Z góry ustal reakcję na niepowodzenie. Jeśli zabronione żądanie się powiedzie, zatrzymaj się przed podłączeniem prawdziwych zgłoszeń. Popraw politykę i powtórz próbę. Jeśli dozwolona usługa otrzyma dane, których nie powinna otrzymać, ponownie oceń dane wejściowe i w razie potrzeby ogranicz dozwolone ścieżki lub operacje tej usługi.

Zapis próby wykonania żądania i jego odrzucenia przez politykę potwierdza blokadę na sprawdzonej ścieżce. Jeśli agent zignoruje instrukcję i nie wykona żądania, nie potwierdza to egzekwowania reguł sieciowych. Taki test nie dowodzi też, że wszystkie złośliwe instrukcje zostaną powstrzymane. Podobnie wynik o prawidłowej strukturze może zawierać błędny wniosek, więc odbiór techniczny musi pozostawiać miejsce na ocenę człowieka.

Jeśli już badasz podejrzenie nieuprawnionego dostępu, masz inne zadanie. Zanim wrócisz do sprawdzeń poprzedzających zatwierdzenie, skorzystaj z procedury triażu prób z użyciem agentów, aby zabezpieczyć dowody i ocenić, co się wydarzyło.

Ogranicz zakres wyniku i zachowaj jego doradczy charakter

System odbierający potrzebuje własnej granicy kontroli nawet przy dobrze odizolowanym wykonywaniu kodu. Musi wiedzieć, do którego zasobu należy dane uruchomienie, co może zapisać i kto ocenia jego wnioski.

Triaż z analizą kodu w Kit ilustruje ten podział. Ty obsługujesz środowisko wykonawcze i kontrolę ruchu wychodzącego; Kit ogranicza zakres wymiany danych zgłoszenia i odbiera wyniki o charakterze doradczym. Kit uruchamia skonfigurowany przez ciebie pipeline. Nie tworzy microVM ani nie konfiguruje i nie weryfikuje w sposób ciągły twojego firewalla.

Poradnik izolacji agenta triażu opisuje runner GitLab utrzymywany i obsługiwany przez klienta. Środowisko blokuje w nim domyślnie cały ruch wychodzący, a proxy weryfikuje tokeny i dopuszcza wyłącznie ścieżki inferencji oraz MCP Kit. Traktuj to jako instrukcję wdrożenia, które trzeba skonfigurować i przetestować. Zewnętrzny pipeline CI nie staje się odizolowany od sieci tylko dlatego, że działa poza Kit, a maskowane zmienne pozostają dostępne dla kodu, który otrzymuje je podczas działania.

Po stronie Kit podpisany token identyfikuje jedno uruchomienie triażu, jego zgłoszenie i konto klienta. Token wygasa po godzinie i pozwala odczytywać zgłoszenie, dołączać dowody oraz przesyłać wynik. Zestaw przyjmowanych pól wyniku jest ograniczony, a finalizacja blokuje dalsze zapisy. Ta blokada zapisu nie oznacza, że odczyt zgłoszenia musi ustać natychmiast po finalizacji; wygaśnięcie tokena stanowi osobne ograniczenie.

Zwrócona ocena nadal ma charakter doradczy i wymaga weryfikacji przez człowieka. Skorzystaj z instrukcji konfiguracji agenta triażu, aby połączyć elementy procesu, a następnie zachowaj dokumentację zatwierdzenia własnego środowiska. Efektem powinno być uruchomienie o ograniczonym zakresie, z zachowanymi dowodami, jasnym warunkiem zatrzymania i recenzentem, który decyduje, co dalej.