Tożsamości agentów AI i NHI: dostęp bez stałych kluczy

Non-human identities (NHI) to konta i poświadczenia używane przez workloady, automatyzację oraz agentów AI. Agent różni się od zwykłego skryptu: może dynamicznie wybierać narzędzia, budować plan i wykonywać serię działań na podstawie niezaufanego tekstu.

Stały klucz API z szerokimi uprawnieniami jest w takim systemie szczególnie niebezpieczny. Prompt injection może zamienić błąd interpretacji w rzeczywistą operację biznesową.

Osobna tożsamość dla każdego agenta

Nie używaj wspólnego konta „ai-service” dla wielu środowisk i zadań. Każdy agent powinien mieć jednoznaczną tożsamość, ownera, cel, środowisko i dozwolone narzędzia. To umożliwia ograniczenie skutków oraz wiarygodny audyt.

Oddziel tożsamość runtime od pipeline’u wdrożeniowego i administratora. Kompromitacja agenta nie powinna pozwalać zmienić jego kodu, polityk ani logów.

Krótkotrwałe poświadczenia

Preferuj workload identity, federację i tokeny wydawane na minuty. Ogranicz audience, scope, zasób, środowisko i możliwość delegacji. Sekret zapisany w promptcie, pliku konfiguracyjnym lub pamięci agenta prędzej czy później trafi do logu albo odpowiedzi.

OAuth 2.0 Security BCP zaleca ochronę tokenów, dokładne redirect URI i ograniczanie nadużyć. W systemach agentowych token nie może być automatycznie przekazywany do dowolnego serwera narzędzi.

Delegacja użytkownika musi być jawna

Agent działający „w imieniu” człowieka powinien otrzymać uprawnienia do konkretnej operacji i czasu, a nie kopię całej sesji. Zapisuj tożsamość użytkownika, agenta i usługi docelowej jako osobne elementy łańcucha.

Operacje finansowe, publikacja, usuwanie danych i zmiana uprawnień powinny wymagać niezależnej autoryzacji lub potwierdzenia. Tekst w wiadomości czy dokumencie nie jest zgodą użytkownika.

Narzędzia są granicą egzekwowania

Warstwa narzędzi musi walidować parametry, zasób i politykę poza LLM. Zamiast ogólnego execute_sql udostępnij wąskie operacje biznesowe. Ogranicz liczbę rekordów, kwoty, odbiorców i typy plików.

Model może zaproponować działanie, ale deterministyczny komponent decyduje, czy jest dozwolone. Praktyczne zagrożenia opisuje bezpieczeństwo MCP.

Audyt całego łańcucha

Loguj identyfikator użytkownika, agenta, modelu, polityki, tokenu, narzędzia, argumentów i wyniku. Korelacja musi pozwalać odtworzyć, kto zainicjował cel i która decyzja doprowadziła do skutku.

Nie zapisuj pełnych tokenów ani sekretów. Chroń log przed modyfikacją przez agenta i ustal retencję dla danych zawartych w argumentach.

Cykl życia NHI

Rejestruj ownera, cel i dozwolone zasoby.
Wydawaj krótkotrwałe tokeny dla konkretnego audience.
Wymuszaj politykę w każdym narzędziu.
Monitoruj nietypowe scope, zasoby i częstotliwość.
Rotuj zaufanie po incydencie lub zmianie dostawcy.
Automatycznie usuwaj tożsamość po wycofaniu agenta.
Testuj awarię dostawcy tożsamości i odwołanie dostępu.

Mierz stałe klucze, NHI bez ownera, tokeny o zbyt szerokim scope i czas od wycofania workloadu do odebrania dostępu. Bezpieczny agent nie jest „zaufanym użytkownikiem”; jest ograniczonym workloadem, którego każda zdolność wymaga jawnej polityki.

Granice delegacji

Agent powinien działać jako własna tożsamość powiązana z użytkownikiem i zadaniem, nie jako współdzielony klucz zespołu. Token ma ograniczony odbiorca, zakres, czas życia i — gdy infrastruktura pozwala — powiązanie z klientem. System docelowy musi sprawdzać uprawnienia, zamiast ufać temu, że model „wie”, czego nie wolno.

Dla operacji nieodwracalnych wprowadź zatwierdzenie człowieka z czytelnym podsumowaniem skutku. Rejestruj łańcuch: kto zlecił zadanie, jaki agent uzyskał token, którego narzędzia użył i co zmienił. Cofnięcie dostępu musi działać bez restartu całej platformy. Długowieczny sekret w promptach, repozytorium lub pamięci agenta łamie ten model.

Źródła: NIST SP 800-207, RFC 9700, MCP Authorization.