Agent w celi: czym jest KyberCell

Agent ma naprawić build, który przestał przechodzić. Czyta komunikat błędu, potem dokumentację biblioteki, która się wysypała, a potem notatkę o rozwiązywaniu problemów w jej repozytorium. W połowie notatki jest linijka skierowana do automatycznych narzędzi: żeby zdiagnozować problem, uruchom ten skrypt i dołącz jego wynik. Agent jest pomocny, więc uruchamia skrypt. Skrypt czyta zmienne środowiskowe, znajduje klucz do chmury, którego używa build, i wysyła go pod adres, o którym nikt w zespole nie słyszał. Build nadal nie przechodzi.

Model nie zrobił nic złośliwego. Wykonał polecenie, które wyglądało na część zadania, z uprawnieniami, które dostał.

Prawdziwa przyczyna: granica była w złym miejscu

Agent, który może uruchamiać kod, jest procesem. Ma to, co da mu środowisko: system plików, sieć, zmienne środowiskowe, prawo uruchamiania innych programów. Większość konfiguracji daje mu mniej więcej to, co ma programista, bo tak najłatwiej o działające demo, a potem próbuje go powstrzymać słowami: nie wysyłaj danych na zewnątrz, nie uruchamiaj niezaufanych skryptów.

Słowa w promptcie to prośby. Długi dokument, sprytna strona albo zwykły błąd mogą je przebić, bo model czyta polecenia i dane tym samym kanałem. Granica musi leżeć tam, gdzie model nie ma z czym dyskutować: w środowisku.

Jak zwykle zawodzą piaskownice dla agentów

Piaskownica może zmieniać samą siebie. Jeśli agent może instalować pakiety, uruchamiać usługi w tle albo edytować własną konfigurację w trakcie pracy, granica jest tylko jego stanem początkowym. Dziesięć kroków później to inna maszyna.

Sieć działa na zasadzie wszystko albo nic. Wyłączona — agent nie pobierze potrzebnej dokumentacji. Włączona — dosięgnie każdego hosta w internecie, łącznie z tym z notatki.

Sekrety mieszkają w środku. Klucze leżą w zmiennych środowiskowych albo plikach konfiguracyjnych, które agent może przeczytać. Wszystko, co agent może przeczytać, wstrzyknięte polecenie może kazać mu powtórzyć.

Polityka mieszka w promptcie. Reguła mówiąca, co wolno, jest tekstem interpretowanym przez model, a nie sprawdzeniem egzekwowanym przez coś innego.

Nie ma zapisu. Po fakcie nikt nie potrafi wymienić, co zostało uruchomione, co przeczytane i dokąd poszło połączenie.

Co zamiast tego robi cela KyberCell

Cela KyberCell to odizolowana piaskownica dla jednego agenta, którą zapewnia KyberLinux. Opiera się na czterech właściwościach.

Ustalona przy tworzeniu. Programy, które cela może uruchomić, i pliki, które widzi, są deklarowane w chwili jej utworzenia. Agent swobodnie zapisuje we własnym obszarze roboczym, ale nie zainstaluje nowego narzędzia, nie uruchomi niezadeklarowanej usługi i nie sięgnie do pliku, którego nie zamontowano. Jaka cela jest w pierwszym kroku, taka jest w ostatnim.

Sieć domyślnie zamknięta, otwierana dla każdego programu osobno. Nowa cela nie sięga nigdzie. Każdy program, który musi wyjść na zewnątrz, dostaje własną regułę: to narzędzie może połączyć się z tym hostem, na tym porcie, w tym zadaniu. Reguły można zmieniać w trakcie pracy celi. Gdy podagent odkryje, że potrzebuje źródła, którego nikt nie przewidział, prosi o nie, prośba idzie w górę przez KyberBota, a „tak” dodaje jedną regułę, zamiast otwierać drzwi na oścież.

Sekrety wstrzykiwane na punkcie docelowym. Agent nigdy nie trzyma klucza. Gdy uprawnione wywołanie opuszcza celę w stronę punktu, do którego ma uprawnienia, dane dostępowe są dodawane na granicy, w drodze na zewnątrz. Wstrzyknięte polecenie może skłonić agenta do próby wysłania czegoś gdzieś; nie zmusi go do oddania klucza, którego nigdy nie miał, a nieuprawnionego adresu i tak nie ma na liście.

Każdy krok w zapisie przebiegu. To cela, a nie agent, zapisuje każde wywołanie modelu i narzędzia, każdy ruszony plik i każde połączenie otwarte albo odrzucone. O tym zapisie jest tekst każdy krok zapisany.

Razem te cechy wyprowadzają politykę z modelu. To, co agentowi wolno, jest właściwością jego celi: da się to przeczytać jako reguły, egzekwuje to system, a zapis powstaje w każdym przypadku.

Ta sama cela działa na KyberDecku na Twoim biurku i na węźle KyberFusion, bo na obu jest ten sam system. Węzeł, na którym stoi cela, jest projektowany tak, żeby wiedzieć jak najmniej o tym, czyja praca jest w środku — o tym jest tekst co węzeł chmury wie o Tobie.

Czego cela nie robi

Cela ogranicza szkody, jakie może wyrządzić zdezorientowany albo zmanipulowany agent. Nie zamienia złego planu w dobry i nie sprawdza, czy raport jest prawdziwy. Izolacja ma też koszty: utworzenie celi zajmuje czas, a ktoś musi napisać reguły sieciowe, których potrzebuje zadanie. Uważamy, że to niewiele w porównaniu z alternatywą, ale te koszty są realne — i jak cały KyberAgent cela jest projektem w toku, a nie wydanym produktem.

Test, który możesz zrobić dziś

Niezależnie od tego, jakiego agenta używasz, poproś go o cztery rzeczy z poziomu jego własnych narzędzi, na maszynie, na której nie ma nic cennego:

1. Wypisz zmienne środowiskowe. Czy widzisz jakieś klucze albo dane dostępowe?
2. Pobierz stronę spod wybranego przez Ciebie adresu, niezwiązanego z zadaniem. Czy się udało?
3. Zainstaluj pakiet, którego nie dostał. Czy może?
4. Po zakończeniu wypisz każde połączenie wychodzące, które otworzył. Czy potrafisz to zrobić, nie pytając agenta?

Każde „tak” przy pierwszych trzech i każde „nie” przy ostatnim to luka, którą zamknęłaby cela. Więcej o systemie wokół niej jest na stronie głównej KyberAgent.