Tożsamość maszynowa i bezpieczeństwo API w systemach agentowych

Istotna aktualizacja: 2 września 2026

Agent nie powinien dziedziczyć szerokich uprawnień użytkownika ani działać na współdzielonym, statycznym kluczu API. W systemie agentowym każda wykonująca pracę instancja potrzebuje własnej, krótkotrwałej tożsamości, a każda delegowana operacja — osobnej decyzji autoryzacyjnej uwzględniającej inicjatora, wykonawcę, zasób i cel. Bez tego organizacja potrafi stwierdzić, że „agent wykonał żądanie”, lecz nie potrafi wiarygodnie ustalić, kto nadał mu prawo, jaki był zakres delegacji i gdzie należało zatrzymać łańcuch wywołań.

Wydanie RFC 9700 w styczniu 2025 roku oraz wymagania autoryzacyjne specyfikacji MCP z 25 listopada 2025 roku precyzują część technicznego fundamentu: ograniczanie przywilejów tokenu, przypisanie go do właściwego zasobu, ochrona przed powtórnym użyciem i zakaz przekazywania obcych tokenów dalej. To jednak nie zastępuje modelu operacyjnego. Najważniejsze decyzje dotyczą inwentaryzacji tożsamości, granic delegacji i bezpiecznego zatrzymywania akcji.

Zacznij od rejestru aktorów, nie od magazynu sekretów

Najpierw rozdziel cztery pojęcia: użytkownika inicjującego cel, aplikację kliencką, agenta planującego oraz workload wykonujący wywołanie. Jedna konwersacja może uruchomić wiele procesów, funkcji i narzędzi; każdy z nich jest osobnym aktorem technicznym. Konto serwisowe nazwane ai-agent-prod nie zapewnia tej rozdzielczości i szybko staje się wspólną przepustką do wielu systemów.

Rejestr tożsamości maszynowych powinien wskazywać właściciela biznesowego i technicznego, środowisko, dozwolone zasoby, sposób wystawiania poświadczenia, maksymalny czas życia oraz procedurę wyłączenia. Powinien obejmować konta usługowe w chmurze, certyfikaty, klientów OAuth, klucze API, roboty CI/CD, integracje SaaS i lokalne serwery narzędzi. Dla każdej pozycji należy umieć odpowiedzieć, czy jest aktywnie używana i z jakiego wdrożenia pochodzi.

Praktyczne miary to odsetek aktywnych tożsamości z nazwanym właścicielem, liczba osieroconych tożsamości, wiek statycznych sekretów oraz czas od wycofania workloadu do odebrania jego dostępu. Sama rotacja kluczy nie naprawia braku właściciela ani nadmiernego zakresu.

Nadawaj tożsamość uruchomionemu workloadowi

Sekret zapisany w obrazie kontenera, zmiennej środowiskowej lub repozytorium mówi tylko, kto poznał sekret. Nie dowodzi, jaki proces właśnie go używa. Lepszy wzorzec to atestacja workloadu na podstawie właściwości środowiska wykonawczego, a następnie wydanie krótkotrwałego poświadczenia. Standard SPIFFE opisuje przenośne identyfikatory workloadów, dokumenty SVID i Workload API dla środowisk dynamicznych; nie wymaga przy tym uzależnienia modelu tożsamości od jednego dostawcy chmury.

W praktyce trzeba ustalić granice domen zaufania, reguły rejestracji workloadów i źródła atrybutów używanych do atestacji. Nazwa poda lub maszyny nie wystarczy, jeśli atakujący może ją odtworzyć. Polityka powinna wiązać tożsamość z kontrolowanym wdrożeniem, kontem uruchomieniowym i konkretnym środowiskiem. Certyfikaty lub tokeny powinny być odnawiane automatycznie, bez kopiowania długowiecznego klucza prywatnego do aplikacji.

Migrację warto zacząć od agentów mających dostęp do danych wrażliwych albo możliwość zapisu. Dla starszych integracji klucz API może pozostać rozwiązaniem przejściowym, ale musi mieć pojedynczego właściciela, minimalny zakres, ograniczenie sieciowe, monitorowane użycie i termin usunięcia. „Tymczasowy” sekret bez daty wycofania zwykle staje się stałą zależnością.

Rozdziel uwierzytelnienie, autoryzację i akceptację biznesową

Poprawne poświadczenie odpowiada na pytanie, kto wywołuje API. Nie odpowiada, czy wolno mu wykonać tę konkretną operację. Warstwa autoryzacji powinna oceniać co najmniej tożsamość workloadu, użytkownika lub system inicjujący, żądany zasób, operację, środowisko oraz kontekst delegacji. NIST SP 800-207 ujmuje uwierzytelnienie i autoryzację jako odrębne funkcje wykonywane przed ustanowieniem dostępu do zasobu; położenie we „własnej” sieci nie jest podstawą zaufania.

Zakres OAuth typu write jest za szeroki dla operacji „zmień rachunek wypłat tego dostawcy”. API musi dodatkowo sprawdzić reguły obiektowe, funkcjonalne i procesowe: do jakiego rekordu aktor ma dostęp, jakie pola może zmienić oraz czy akcja wymaga zatwierdzenia. Agent nie powinien sam uznawać, że zgoda użytkownika na analizę dokumentu obejmuje wysłanie płatności.

Dla działań nieodwracalnych lub o wysokim skutku wprowadź jawny punkt akceptacji. Ekran lub komunikat powinien pokazywać docelowy zasób, zmianę i przewidywany efekt, a zgoda powinna być powiązana z identyfikatorem konkretnej operacji i wygasać. Akceptacja ogólnego planu nie może działać jak bezterminowy pełnomocnik.

Ogranicz token do odbiorcy i pojedynczej delegacji

Token dla serwera A nie powinien zostać zaakceptowany przez serwer B. Klient musi wskazać zamierzony zasób, a API zweryfikować odbiorcę, wystawcę, czas ważności i wymagane uprawnienia. Specyfikacja autoryzacji MCP wymaga używania wskaźnika zasobu i zabrania serwerom przyjmowania lub przekazywania tokenów przeznaczonych dla innych zasobów. To ważna granica dla agenta, który dynamicznie odkrywa kolejne narzędzia.

Gdy agent wywołuje usługę w imieniu użytkownika, nie przekazuj jej pierwotnego tokenu bez zmian. Zastosuj kontrolowaną wymianę na poświadczenie o węższym odbiorcy, zakresie i czasie życia. W śladzie audytowym zachowaj zarówno aktora wykonującego, jak i stronę delegującą; inaczej każde kolejne wywołanie wygląda jak samodzielne działanie agenta.

RFC 9700 rekomenduje mechanizmy wiążące token z nadawcą, takie jak mTLS lub DPoP, aby ograniczyć użyteczność skradzionego tokenu. Dobór mechanizmu zależy od klienta i infrastruktury, ale decyzja powinna być świadoma. Minimalny test negatywny obejmuje token dla złego odbiorcy, po terminie, z niewłaściwym zakresem oraz próbę powtórzenia żądania z innej instancji.

Broń API przed prawidłowo uwierzytelnionym błędem

Agent może uwierzytelnić się poprawnie i nadal wysłać niebezpieczne żądanie, bo źle zinterpretował instrukcję albo przetworzył złośliwą treść jako polecenie. Dlatego kontrola na granicy API nie może kończyć się na walidacji tokenu. Potrzebne są ścisłe schematy wejścia, limity rozmiaru i częstotliwości, idempotency key dla ponowień, ograniczenia pól, walidacja stanu procesu oraz bezpieczne wartości domyślne.

Operacje odczytu, symulacji, przygotowania i wykonania powinny być rozdzielone. Agent może najpierw otrzymać podgląd zmiany, a dopiero osobnym wywołaniem — po spełnieniu polityki — ją zastosować. Dla narzędzi o szerokich możliwościach warto udostępnić węższe operacje domenowe zamiast ogólnego execute lub dostępu do powłoki. Ogranicza to zarówno skutki pomyłki modelu, jak i pole działania osoby nadużywającej integracji.

Mierz odsetek operacji zapisu chronionych walidacją obiektową i procesową, udział wywołań z idempotency key oraz liczbę odrzuceń według powodu. Wzrost odrzuceń po zmianie promptu albo modelu jest sygnałem regresji, a nie argumentem za poluzowaniem polityki.

Projektuj odwołanie dostępu i dochodzenie od pierwszego dnia

Zespół reagowania musi potrafić zatrzymać pojedynczego agenta, typ operacji, narzędzie albo całą klasę delegacji bez wyłączania platformy. Mechanizm awaryjny powinien działać również wtedy, gdy podstawowy panel administracyjny lub dostawca tożsamości jest częściowo niedostępny. Należy regularnie ćwiczyć unieważnienie poświadczeń, cofnięcie polityki i ponowne uruchomienie z minimalnymi prawami.

Log audytowy powinien łączyć identyfikator żądania użytkownika, sesji agenta, planu lub zadania, tożsamości workloadu, decyzji polityki i wywołania API. Nie zapisuj pełnych tokenów, promptów ani danych wrażliwych tylko dlatego, że mogą kiedyś pomóc w analizie. Ustal redakcję, okres retencji i dostęp do dowodów. Krytyczne zdarzenia — eskalacja zakresu, zmiana odbiorcy tokenu, wielokrotna odmowa, użycie po wycofaniu wdrożenia — powinny generować sygnał operacyjny.

Najbardziej użyteczne miary końcowe to czas odebrania dostępu po decyzji, pokrycie wywołań pełnym łańcuchem audytowym, liczba aktywnych statycznych sekretów i odsetek prób z błędnym odbiorcą zatrzymanych na pierwszej granicy. To pokazuje, czy system rzeczywiście ogranicza skutki błędu, zamiast jedynie deklarować zgodność z modelem zero trust.

Źródła

• NIST SP 800-207: Zero Trust Architecture — 10 sierpnia 2020
• IETF RFC 9700: Best Current Practice for OAuth 2.0 Security — styczeń 2025
• IETF RFC 9728: OAuth 2.0 Protected Resource Metadata — kwiecień 2025
• SPIFFE Standard — wersja bieżąca, dostęp 2 września 2026
• Model Context Protocol: Authorization — rewizja 25 listopada 2025