Czym jest token uprawnień i jak ogranicza domowego agenta AI?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

What Is a Capability Token, and How Does It Limit a Home AI Agent? - Zima Store Online

Token możliwości przyznaje uprawnienia oparte na posiadaniu do określonego zasobu i operacji, ograniczając agenta przez nieudzielanie mu żadnych możliwości, których mu nie przyznano.

Agent domowy może potrzebować odczytać jeden kalendarz, przełączyć światła w jednym pomieszczeniu lub przesłać wybraną kopię zapasową bez otrzymywania stałych poświadczeń administratora. Token możliwości może powiązać zasób, działanie, wygaśnięcie, budżet i kontekst w możliwe do zweryfikowania uprawnienie. Brama narzędzi sprawdza to uprawnienie przy każdym wywołaniu, więc sam tekst promptu nie może rozszerzyć uprawnień agenta.

Token łączy odwołanie do obiektu z uprawnieniami

Możliwość wskazuje chroniony obiekt lub rozwiązuje odwołanie do niego, a także przekazuje dozwolone operacje każdemu, kto prawidłowo ją posiada. W przeciwieństwie do szerokiego klucza API połączonego z wewnętrznym sprawdzaniem ACL samo uprawnienie jest celowo wąskie i niemożliwe do sfałszowania.

Badania nad możliwościami obiektowymi opisują model możliwości obiektowych jako sposób kodowania praw dostępu w poszczególnych obiektach w celu ograniczenia interakcji. Deskryptory plików są znanym lokalnym przykładem: umożliwiają dostęp do już otwartego obiektu, nie przyznając dowolnych uprawnień do wskazywania nazw w systemie plików.

Możliwość może współistnieć z tożsamością i polityką. Tożsamość odpowiada na pytanie, kto uczestniczy w operacji; możliwość wskazuje, jakie konkretne uprawnienia przekazano na potrzeby tego działania. Rozróżnienie to pozostaje widoczne podczas późniejszych testów domowych.

Ograniczanie zawęża delegowanie, nie rozszerzając go

Usługa nadrzędna może utworzyć token podrzędny ograniczony do mniejszej ścieżki, metody tylko do odczytu, krótszego czasu ważności, niższego budżetu lub określonego kontekstu żądania. Token podrzędny może delegować mniej uprawnień, ale nie może usunąć ograniczeń ani wygenerować szerszych praw.

Macaroons wprowadzają ogranizowane upoważnianie, które obsługuje ograniczenia zależne od kontekstu i zdecentralizowane delegowanie. Weryfikacja sprawdza łańcuch podpisów oraz każde ograniczenie, zanim serwer zasobu zaakceptuje żądanie. Wynik pośredni musi pozostać możliwy do skontrolowania, zanim automatyzacja będzie kontynuowana.

Jest to przydatne w przypadku agentów, ponieważ planista może otrzymać możliwość sesji i przekazać jej pochodną, specyficzną dla zadania, jednemu podprocesowi narzędzia. Podproces nigdy nie potrzebuje poświadczenia głównego w swoim promptcie ani środowisku. Granicę tę należy mierzyć osobno w realistycznych warunkach działania.

Posiadanie, delegowanie i unieważnianie nadal wyznaczają granice bezpieczeństwa

Każdy, kto ukradnie możliwość typu bearer, może z niej korzystać do czasu jej wygaśnięcia lub unieważnienia. Tokeny wymagają chronionego przesyłania i przechowywania, wiązania z odbiorcą lub kanałem tam, gdzie jest to właściwe, krótkiego czasu ważności oraz identyfikatorów audytowych. Praktyczna konsekwencja pojawia się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Analiza bezpieczeństwa opartego na możliwościach wyjaśnia różnicę między uprawnieniami możliwości a mechanizmami skoncentrowanymi na tożsamości. Model ogranicza uprawnienia środowiskowe, ale nie ocenia, czy żądane przez agenta działanie odzwierciedla rzeczywistą intencję użytkownika. Ta zależność powinna pozostać wyraźnie zaznaczona w końcowym interfejsie.

Granica awarii przebiega przy zbyt szerokim, możliwym do ponownego użycia lub wyciekłym tokenie. Sprawdzanie możliwości nie może zapobiec szkodliwemu użyciu mieszczącemu się w zakresie uprawnienia, dlatego działania o istotnych skutkach nadal wymagają weryfikacji celu, zatwierdzenia, limitów częstotliwości i możliwego do zaobserwowania unieważniania. Wynik należy zatem sprawdzić względem pierwotnych dowodów.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Twórz wykaz uprawnień według tokenu, narzędzia i żądania

Dla każdego wywołania narzędzia rejestruj wystawcę, podmiot lub posiadacza, odbiorcę, zasób, operację, zakres ścieżki, budżet, termin wygaśnięcia, łańcuch delegowania, ograniczenia, uchwyt unieważniania, wymóg zatwierdzenia oraz identyfikator audytowy. Rozróżnienie to pozostaje widoczne podczas późniejszych testów domowych.

Porównaj uprawnienie z bezpieczeństwem opartym na możliwościach. Przetestuj przechodzenie poza dozwoloną ścieżkę, zmieniony identyfikator urządzenia, podmianę metody, ponowne użycie, wygasły token, skradziony token podrzędny, weryfikator offline, unieważniony token nadrzędny oraz dozwolone, ale wysoce ryzykowne żądanie. Wynik pośredni musi pozostać możliwy do skontrolowania, zanim automatyzacja będzie kontynuowana.

Przejdź dalej tylko wtedy, gdy każde narzędzie otrzymuje minimalne uprawnienie i nie może go rozszerzyć. Traktuj powodzenie sprawdzenia możliwości jako autoryzację, a nie dowód intencji użytkownika, bezpieczeństwa semantycznego ani poprawności wyniku narzędzia. Granicę tę należy mierzyć osobno w realistycznych warunkach działania.