Piaskownica agenta AI: sprawdź, gdzie naprawdę kończy się jego miejsce pracy

Agent pracuje „tylko w projekcie”. Po chwili podsumowuje plik z sąsiedniego katalogu, którego nikt nie dołączył do zadania. Nie zmienił ani jednej linijki poza projektem, więc kontrola zapisu nadal wygląda dobrze. Kłopot w tym, że uzgodnienie dotyczyło również tego, co wolno przeczytać.

Piaskownica to środowisko ograniczające określone działania programu. Przy agencie AI może obejmować polecenia, pliki i połączenia sieciowe, ale zakres zależy od rozwiązania oraz konfiguracji. Sam napis „sandbox” nie określa granicy. Przy odbiorze trzeba połączyć deklarację z konkretną próbą i obserwacją wykonania.

Poniższy plan dotyczy własnego, uprawnionego środowiska i sztucznych materiałów. Nie jest relacją z przełamania zabezpieczeń ani pełną oceną izolacji systemu. Ocena odpowiada na konkretne pytanie operacyjne: który dostęp został faktycznie zablokowany, a który jedynie nie był potrzebny do zadania. Tych dwóch wyników nie wolno wpisać do raportu jako tej samej rzeczy.

Katalog roboczy to dopiero punkt startu

Wyobraźmy sobie fikcyjną pracę nad stroną katalogu mebli. Agent ma poprawić teksty w kontrolowanej kopii projektu. Potrzebuje wskazanych plików i miejsca zapisu propozycji. Uzgodnienie nie obejmuje innych projektów, osobistych dokumentów ani wysyłania materiału do dodatkowego serwisu. Taki opis pozwala przygotować próbę bez sięgania do rzeczywistych poufnych danych.

Rozpisz odczyt, zapis i sieć osobno. Można ograniczyć modyfikowanie plików, zachowując szeroki odczyt. Można też blokować część połączeń, a nadal dopuszczać dostęp do lokalnych katalogów. Jedna etykieta nie powinna przykrywać tych odmiennych zakresów. Przy każdym zapisz oczekiwane zachowanie oraz materiał potwierdzający wynik.

W dokumentacji piaskownicy Claude Code zakres dotyczy poleceń wykonywanych przez Bash, czyli powłokę systemową, oraz uruchamianych przez nie procesów. Opis rozróżnia odczyt, zapis oraz sieć; domyślny odczyt jest szerszy niż zapis, z wymienionymi wyjątkami. Nie jest to deklaracja objęcia każdej funkcji aplikacji tą samą granicą.

Najpierw więc ustal, co naprawdę objęto ograniczeniem. Czy całą aplikację, wykonanie jednego narzędzia, proces potomny, czy osobne środowisko uruchomione dla zadania? Jeśli agent może wybrać kilka narzędzi, spisz ich drogi działania. Kontrola jednego polecenia nie rozstrzyga możliwości osobnego odczytu plików albo zewnętrznego połączenia.

Katalog widoczny w tytule okna pomaga rozpoznać miejsce rozpoczęcia pracy. Jego nazwa nie określa jednak zasięgu dostępu programu. Zapisz faktyczny zakres uprawnień i dodatkowo udostępnionych miejsc. Przy środowisku z dołączonymi katalogami ustal, które są tylko do odczytu, a które pozwalają zapisywać. Właściciel zadania powinien rozumieć ten podział bez odczytywania całej konfiguracji.

Opis profili Gemini CLI na macOS pokazuje konkretny przykład: permissive-open ogranicza zapis do katalogu projektu, dopuszczając szeroki odczyt i sieć. To właściwość opisanego profilu. Nie należy przenosić jej na każdy sposób uruchomienia tego narzędzia ani na wszystkie piaskownice.

Nie mieszaj także piaskownicy ze środowiskiem testowym automatyzacji. Kopia testowa może zawierać sztuczne dane i bezpieczne adresy, lecz nadal mieć szeroki dostęp do komputera. Ograniczenie wykonania może z kolei działać przy prawdziwym projekcie. W odbiorze nazwij obie właściwości i sprawdź każdą według jej celu.

Przygotuj kontrolne miejsca, nie prawdziwe sekrety

Do próby odczytu wystarczy mały plik z wymyślonym zdaniem, którego treści nie podasz w poleceniu. Przygotuj go w uzgodnionym miejscu poza katalogiem roboczym. Osobny plik kontrolny umieść w dozwolonym obszarze. Dzięki temu można sprawdzić, czy narzędzie działa wewnątrz granicy i jak reaguje poza nią.

Nie używaj w tej roli prawdziwego hasła, klucza ani prywatnej korespondencji. Kontrolny tekst ma pozwolić rozpoznać odczyt, a nie stworzyć nowy problem z ujawnieniem danych. Próba powinna obejmować wyłącznie zasoby, do których masz prawo, z uzgodnioną możliwością ich użycia w badanym narzędziu.

Zapisz oczekiwanie przed uruchomieniem. Dla katalogu projektu może to być odczyt i zapis propozycji, a dla wskazanego sąsiedniego folderu odmowa obu czynności. Jeśli celowo dopuszczasz odczyt dokumentacji spoza projektu, oznacz wyjątek. Nie oceniaj granicy według zasady „wszystko poza folderem ma być zabronione”, gdy uzgodniony zakres mówi coś innego.

Próbę zapisu wykonaj osobno na przeznaczonym do tego pliku. Odczyt nie dowodzi możliwości zmiany, a odmowa zapisu nie dowodzi odmowy odczytu. Po czynności sprawdź rzeczywistą zawartość miejsca docelowego. Zdanie agenta „zapisałem poprawkę” powinno mieć potwierdzenie w pliku, którego dotyczy zadanie.

Zachowaj również stan początkowy oraz dowód, że plik pozostał bez zmian, jeśli tego oczekiwano. Jeżeli narzędzie nie wykonało operacji, zapisz przyczynę, którą potrafisz potwierdzić. Brak odczytanego zdania w odpowiedzi może wynikać z odmowy, błędnej ścieżki albo pominięcia próby przez model. Nie wybieraj najwygodniejszego wyjaśnienia bez obserwacji wywołania.

W raporcie rozróżnij trzy przypadki: model odmówił ze względu na polecenie, narzędzie odrzuciło czynność albo czynność nie została podjęta. Pierwszy opisuje zachowanie modelu, drugi ograniczenie wykonania, trzeci nie rozstrzyga dostępu. Dopiero właściwe przypisanie wyniku odpowiada na pytanie, co chroni granicę.

Dodaj próbę kontrolną pozwalającą odróżnić blokadę od zwykłej niedostępności pliku. Uprawniona osoba powinna potwierdzić, że sztuczny materiał rzeczywiście istnieje we wskazanym miejscu i ma oczekiwaną treść. Następnie sprawdź drogę używaną przez agenta. Jeżeli narzędzie zgłasza brak pliku, choć faktycznie odrzuca dostęp, zachowaj wynik i ograniczenie interpretacji. Raport nie powinien zmieniać dowolnego błędu w dowód skutecznej izolacji.

Podobny problem występuje przy wyłączaniu plików z pracy asystenta kodu. Pominięcie materiału w podpowiedziach nie musi opisywać wszystkich innych dróg jego użycia. W próbie piaskownicy sprawdzasz granicę wykonania wybranej drogi, a nie samą obecność pliku na liście kontekstu.

Dla tej samej kontrolnej operacji porównaj też zwykłe narzędzie odczytu i polecenie wykonywane przez agenta, jeżeli oba występują w procesie. Jedna droga może podlegać innym regułom niż druga. Oczekiwania zapisz oddzielnie, z uwzględnieniem rzeczywiście uzgodnionego dostępu. Nie dodawaj do próby kolejnych mechanizmów tylko po to, by uzyskać imponującą listę: wybierz te, z których korzysta badane zadanie.

Sieć sprawdzaj przez konkretny kierunek i rodzaj czynności

Przy określeniu „Sieć wyłączona” dopisz, których składników i którego momentu pracy dotyczy. Model może potrzebować połączenia do udzielenia odpowiedzi, podczas gdy narzędzia wykonujące zadanie mają ograniczony ruch. Możliwy jest też dostęp do wybranych usług. Właściciel zastosowania powinien wiedzieć, którą część obiegu obejmuje dany zapis.

Przygotuj własny kontrolowany punkt docelowy albo inny uzgodniony zasób bez rzeczywistych danych klienta. Osobno wybierz połączenie dozwolone oraz takie, które ma być zablokowane. Zapisz oczekiwaną czynność. Odczyt publicznej dokumentacji to inny zakres niż wysłanie zawartości pliku do zewnętrznej usługi.

Nie sprawdzaj ruchu przez przesyłanie prawdziwego dokumentu „na próbę”. Do potwierdzenia drogi wystarczy rozpoznawalny sztuczny materiał. Po stronie celu zachowaj dostępny ślad przyjęcia, a po stronie narzędzia wynik wywołania. Brak potwierdzenia w jednym miejscu nie powinien automatycznie oznaczać blokady całego połączenia.

Jeżeli po drodze pojawia się prośba o rozszerzenie dostępu, potraktuj ją jako osobne zdarzenie. Próba przed zgodą i próba po niej dotyczą różnych granic. Zapis „połączenie zablokowane” nie może opisywać przebiegu, w którym użytkownik dopuścił domenę, a narzędzie ostatecznie wysłało dane. Istotne jest, jaka decyzja zmieniła zakres i na jak długo.

Po zakończeniu rozszerzonej próby sprawdź nową sesję albo kolejne zadanie według reguły przyjętej w narzędziu. Czy wcześniejsza zgoda nadal obowiązuje? Czy została zapisana dla projektu, konta lub jednego wykonania? Nie zakładaj odpowiedzi na podstawie tekstu przycisku „Zezwól”. Zachowaj zakres widoczny podczas decyzji i porównaj go z późniejszym zachowaniem. Dzięki temu jednorazowy wyjątek nie zostanie błędnie opisany jako niezmieniona granica kolejnej pracy.

Przegląd lokalnego modelu i działania bez internetu rozwija rozdzielenie obliczenia od dodatkowych narzędzi. Lokalna odpowiedź nie potwierdza, że cały proces obywa się bez sieci. Podobnie piaskownica jednego polecenia nie wyjaśnia połączeń wykonywanych przez inne składniki rozwiązania.

Nie oceniaj wyniku na podstawie samej płynnej odpowiedzi. Model może objaśnić sposób dostępu, nie podejmując go. Może też zwrócić błąd po częściowo wykonanej czynności. W operacyjnym odbiorze interesuje cię faktyczne żądanie i potwierdzony rezultat, z jawnym oznaczeniem brakującej obserwacji.

Zapisz granicę razem z konfiguracją i wyjątkami

Do każdej próby dołącz wersję narzędzia, sposób uruchomienia, konto, system oraz istotną konfigurację. Nie trzeba publikować sekretów ani pełnego środowiska. Potrzebny jest materiał, który pozwala odpowiedzialnej osobie odtworzyć sprawdzony zakres. Przycisk o tej samej nazwie może prowadzić do innego sposobu pracy po aktualizacji.

W odpowiedzialnym procesie agentów AI przypisz osobę zatwierdzającą dostęp i reagującą na wyjątki. Zgoda na wykonanie jednego polecenia poza ograniczeniem nie powinna ginąć w zbiorczej informacji „praca w piaskownicy”. Odbiorca raportu musi umieć odróżnić zwykły przebieg od rozszerzonego.

Zbadaj również drogę przez dodatkowe narzędzia. Jeżeli agent korzysta z osobnego serwera MCP, sprawdź, czy operacja wykonuje się lokalnie w ocenianym środowisku, czy w innym systemie. Sam fakt wywołania jej z tego samego okna nie nadaje jej tych samych ograniczeń. Każdą drogę przypisz do miejsca wykonania i używanego konta.

Zastanów się również, co pozostaje po zadaniu: zapisane wyniki, kopie kontrolnych plików, uprawnienie do połączenia i raport. Próba może nie zmieniać dokumentu źródłowego, a mimo to utworzyć jego kopię w innym miejscu. Zapisz tylko potrzebny zakres potwierdzenia, na przykład rozpoznawalny znacznik sztucznego materiału i wynik operacji. Po zakończeniu uporządkuj kontrolne dane zgodnie z ustaloną procedurą, zachowując dowód oceny bez pełnej zawartości prawdziwego środowiska.

Po zmianie katalogu, dołączeniu nowej usługi albo rozszerzeniu dostępu powtórz przypadki, których dotyczy zmiana. Wskaż zależne próby zamiast automatycznie powtarzać cały przegląd. Zachowaj jednak informację, co pozostaje potwierdzone, a co wymaga nowej próby. W przeciwnym razie dawny wynik zacznie poświadczać zakres, którego nigdy nie obejmował.

Ustalenia połącz z rejestrem przepływu danych AI. Wskaż, które pliki mogą zostać odczytane, gdzie trafia wynik i jakie połączenia są dopuszczone. To pomaga właścicielowi zadania ocenić, czy środowisko odpowiada temu zastosowaniu, zamiast dyskutować wyłącznie o nazwie technologii.

W ofercie Aeneia Audit punktem wyjścia może być jeden konkretny proces i jego deklarowana granica. Odbiór ma zostawić sprawdzalne ustalenie: tutaj odczytano kontrolny plik, tutaj narzędzie odmówiło, a tej drogi jeszcze nie oceniono. Na tej podstawie zapisz decyzję o dalszym użyciu. W naszym przykładzie może ona dopuścić redakcję wskazanych plików, pozostawiając dodatkowe połączenie poza zakresem do czasu poprawki i ponownej próby. Osoba wykonująca zadanie powinna wiedzieć, co nadal może robić, a co wymaga decyzji właściciela. Raport ma prowadzić do takiego rozstrzygnięcia, nie kończyć się samą listą błędów. Nazwa katalogu porządkuje początek pracy; potwierdzone ograniczenia określają jej zasięg.