Jak tajny broker przekazuje agentowi AI dane uwierzytelniające bez ujawniania ich w promptach?

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.

How Does a Secret Broker Give an AI Agent Credentials Without Exposing Them in Prompts? - Zima Store Online

Tajny broker chroni dane uwierzytelniające przed trafieniem do promptów, uwierzytelniając obciążenie agenta i wstrzykując ograniczone uprawnienia dopiero na granicy zewnętrznego żądania.

Domowy agent AI może potrzebować odczytać kalendarz lub przesłać kopię zapasową, jednak umieszczenie kluczy API w jego prompcie, pamięci, środowisku lub wynikach narzędzi sprawia, że mogą one zostać ujawnione w wyniku wstrzyknięcia. Broker weryfikuje tożsamość obciążenia i zatwierdzony kontekst zadania, uzyskuje krótkotrwałe poświadczenie, dołącza je wewnątrz kontrolowanego serwera proxy lub adaptera narzędzia i zwraca wyłącznie wynik usługi.

Tożsamość obciążenia zastępuje posiadanie statycznego klucza

Agent potwierdza, który zatwierdzony proces, kontener, konto usługi lub podpisane obciążenie wykonuje żądanie. Broker mapuje tę tożsamość na zasady zamiast ufać kluczowi okaziciela przechowywanemu w miejscu dostępnym dla wygenerowanego kodu lub kontekstu modelu.

Analiza dotycząca tożsamości obciążenia agentów wyjaśnia atestację i uwierzytelnianie maszyna-maszyna dla agentów, które nie powinny posiadać trwałych danych uwierzytelniających. Dowód tożsamości pozwala uzależnić autoryzację od działającego obciążenia zamiast od twierdzeń zawartych w rozmowie. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Sama tożsamość nie zapewnia dostępu do każdej usługi. Zasady nadal wiążą obciążenie z użytkownikiem, miejscem docelowym, operacją, zakresem zasobu i przedziałem czasowym. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Broker wydaje lub wstrzykuje wąskie, krótkotrwałe poświadczenie

Po zatwierdzeniu przez zasady broker wymienia tożsamość na token o ograniczonym zakresie lub pobiera sekret do chronionej pamięci. Serwer proxy dodaje nagłówek autoryzacji do żądania wychodzącego dopiero po zweryfikowaniu parametrów wygenerowanych przez model.

Wskazówki dotyczące bezpieczeństwa w zakresie krótkotrwałych poświadczeń brokerowanych zalecają rozpoczęcie bez żadnych poświadczeń i używanie brokera do dostarczania krótkotrwałych tokenów przeznaczonych do konkretnego zadania. Ogranicza to zarówno czas ekspozycji, jak i liczbę operacji dostępnych po przejęciu. Tę granicę należy mierzyć oddzielnie w realistycznych warunkach działania.

Model widzi schemat narzędzia i oczyszczoną odpowiedź, a nie token. Dzienniki, błędy, ślady, wiersze poleceń i ponowienia prób również muszą usuwać dane autoryzacyjne, w przeciwnym razie architektura jedynie przenosi wyciek w inne miejsce. Praktyczna konsekwencja staje się widoczna, gdy kilka źródeł konkuruje o ograniczony kontekst.

Zasady i unieważnianie ograniczają nadużycie poświadczeń

Listy dozwolonych miejsc docelowych, ograniczenia metod, identyfikatory zasobów, zgoda użytkownika, limity żądań, deklaracje odbiorcy, wygasanie i tokeny jednorazowe ograniczają sposób wykorzystania wstrzykniętych uprawnień. Broker może unieważnić przyszłe wydawanie poświadczeń bez przebudowy promptów lub obrazów.

Wyjaśnienie dotyczące granicy wstrzykiwania poświadczeń wskazuje, że każdy sekret trafiający do okna kontekstu może zostać ujawniony, dlatego obsługę poświadczeń należy umieścić poza agentem. Wzorzec ten zmniejsza ryzyko ujawnienia, zachowując możliwość kontrolowanych uwierzytelnionych wywołań. Ta zależność powinna pozostać wyraźna w końcowym interfejsie.

Granica awarii pojawia się wtedy, gdy zasady brokera lub serwera proxy są zbyt szerokie i podpisują dowolne żądania wybrane przez agenta. Ukryte poświadczenia nie uniemożliwiają agentowi, któremu wstrzyknięto prompt, niewłaściwego użycia prawidłowych uprawnień, dlatego nadal trzeba weryfikować semantykę żądań i skutki uboczne.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Prześledź jedno poświadczenie od tożsamości do wygaśnięcia

Dla każdego narzędzia agenta udokumentuj tożsamość obciążenia, żądającego użytkownika, miejsce docelowe, dozwoloną operację, zakres zasobu, stan zatwierdzenia, odbiorcę tokenu, czas ważności, punkt wstrzyknięcia, usuwanie danych z odpowiedzi, identyfikator audytu, ścieżkę unieważnienia i zachowanie awaryjne. Wynik należy zatem sprawdzić względem pierwotnych dowodów.

Porównaj to zabezpieczenie z uprawnieniami narzędzi agenta. Testuj żądania promptów dotyczące sekretów, zrzutów środowiska, przekierowanych miejsc docelowych, ponownego użycia po wygaśnięciu, rozszerzonych identyfikatorów zasobów, rejestrowania błędów, ponowień prób narzędzi i przejętego procesu piaskownicy. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Uzyskaj pozytywny wynik tylko wtedy, gdy surowe poświadczenia nigdy nie trafiają do danych widocznych dla modelu, a nieautoryzowane warianty żądań kończą się niepowodzeniem na brokerze lub serwerze proxy. Używaj krótkotrwałych tokenów, zasad właściwych dla zadania i zredagowanych dzienników, a nieodwracalne operacje uzależniaj od niezależnie powiązanej zgody. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.