Piaskownica agenta to przede wszystkim kontrola wyjścia

Coraz więcej agentów w ramach swojej pracy pisze i uruchamia kod. Agent programistyczny uruchamia testy i instaluje pakiety. Agent analityczny pisze skrypt przekształcający arkusz i go wykonuje. Agent przeglądający strony ładuje wszystko, co ładuje strona. W tym momencie agent przestaje być kimś, kto wywołuje kilka otypowanych narzędzi. Staje się komputerem ogólnego przeznaczenia z modelem przy klawiaturze, a granice wyznacza mu już tylko otaczające go środowisko.

Pierwszy odruch to zamknąć proces w kontenerze i uznać sprawę za załatwioną. Izolacja procesu to łatwa połowa. O tym, jak zły będzie zły dzień, decyduje druga: co jest w piaskownicy razem z agentem i co może się z niej wydostać.

Jak agenci wychodzą, niczego nie łamiąc

Ucieczka z kontenera jest rzadka i trudna. Większość szkód wyrządza agent, który robi coś całkowicie dozwolonego wewnątrz piaskownicy, ze skutkami na zewnątrz.

Klucze leżące na wierzchu. Poświadczenia chmurowe w zmiennych środowiskowych, token programisty w pliku konfiguracyjnym, usługa metadanych w chmurze, która wydaje rolę maszyny każdemu procesowi, który o nią poprosi. Agent nie uciekł — znalazł klucze.

Otwarta sieć. Kod, który może połączyć się z dowolnym adresem, może wysłać cokolwiek dokądkolwiek: żądanie do serwera napastnika, dane zakodowane w zapytaniach DNS, plik wypchnięty do publicznego repozytorium albo rejestru pakietów.

Zależności, których nikt nie wybrał. Agent instaluje pakiet wspomniany w pliku README, który właśnie przeczytał, albo pakiet o wiarygodnie brzmiącej nazwie, zasugerowany przez model i przez nikogo niesprawdzony. Instalacja pakietu to uruchomienie cudzego kodu.

Stan, który przeżywa zadanie. Piaskownica używana przez kolejne zadania przenosi zmodyfikowaną konfigurację albo podrzucony skrypt z zatrutego zadania do następnego, czystego.

Warstwy, które mają znaczenie

Infografika

Warstwy piaskownicy agenta

  1. 01Jednorazowe środowiskoŚwieże dla każdego zadania, potem niszczone. Nic nie przechodzi dalej.
  2. 02Żadnych sekretów w środkuPoświadczenia trzymają narzędzia na zewnątrz, sprawdzające każde żądanie.
  3. 03Zawężony system plikówTylko pliki potrzebne do zadania, tylko do odczytu, gdzie się da.
  4. 04Wyjście domyślnie zamknięteTylko nazwane adresy, przez proxy logujące każde żądanie.
  5. 05Limity zasobówLimity czasu, pamięci i procesów, żeby zapętlona praca kończyła się sama.
Granica procesu to łatwa część. Wartość leży w tym, co ją przekracza.

Jednorazowa z założenia. Świeże środowisko dla każdego zadania, niszczone po jego zakończeniu. Cokolwiek zmieniło zmanipulowane zadanie, znika razem z nim, a każde zadanie startuje ze znanego stanu.

W środku nic wartego kradzieży. Żadnych poświadczeń w piaskownicy. Gdy agent musi zadziałać na czymś na zewnątrz — wypchnąć gałąź, otworzyć pull request, wywołać wewnętrzne API — prosi o to narzędzie działające poza piaskownicą, które trzyma poświadczenie i sprawdza żądanie. Kod w środku prosi; kod na zewnątrz decyduje.

Tylko pliki potrzebne do zadania. Montowane tylko do odczytu, gdzie się da, z osobnym miejscem na wyniki, które coś innego sprawdza, zanim gdziekolwiek trafią.

Limity czasu i zasobów. Zapętlony proces albo kosztowna pomyłka kończy się sama, a nie na koniec miesiąca na fakturze.

Przeglądarka w osobnej piaskownicy. Agent przeglądający internet z każdą stroną otwiera naraz niezaufany kod i niezaufany tekst, więc należy mu się najbardziej ograniczone środowisko, jakie macie, oddzielone od wszystkiego, co trzyma dane.

Ruch wychodzący to kontrola, która robi najwięcej

Bez poświadczeń w środku i z siecią domyślnie zamkniętą większość tego, co może zrobić zmanipulowany albo zdezorientowany agent, zostaje w piaskownicy usuwanej w ciągu godziny. Dlatego kontrola ruchu wychodzącego jest najcenniejszym zabezpieczeniem — i zarazem tym, które najczęściej zostaje otwarte, bo coś kiedyś potrzebowało internetu.

Domyślnie wszystko zablokowane, a nazwane adresy docelowe osiągane przez proxy, które loguje każde żądanie. Pakiety z wewnętrznego lustra z zatwierdzonym zestawem, a nie prosto z publicznych rejestrów. DNS rozwiązywany przez resolver, który kontrolujecie, bo zapytania DNS potrafią wynieść dane nawet wtedy, gdy każda inna droga jest zamknięta. Każdy wyjątek traktujcie jak to, czym jest: regułę zapory z właścicielem i uzasadnieniem.

Tarcie jest informacją

Taki układ generuje tarcie. Zadania padają, bo adresu nie ma na liście, a zespoły proszą o wyjątki. To tarcie jest użyteczne. Lista wyjątków staje się pierwszą dokładną mapą tego, do czego Wasi agenci naprawdę sięgają — mapą, której wcześniej nikt nie miał. Przeglądajcie ją regularnie: wyjątek, którego od miesięcy nikt nie użył, znika, a taki, z którego korzysta się bez przerwy, sygnalizuje, że zadanie urosło ponad to, co zaprojektowano.

Agenci programistyczni to ci, którym najczęściej daje się powłokę, a w potoku zbudowanym pod agentów AI sterowanych specyfikacją działają w Waszym CI, blisko repozytoriów i poświadczeń wdrożeniowych. Gdzie stoi ich piaskownica i co może z niej wyjść, to jedno z zabezpieczeń, które warto uzgodnić, zanim uruchomi się pierwszą wygenerowaną zmianę.