Bezpieczeństwo oparte na uprawnieniach dla narzędzi agenta: minimalne uprawnienia przez wąskie tokeny i capabilities

Agent AI, który wywołuje API, czyta bazę i wysyła maile, jest tak bezpieczny, jak najszersze uprawnienie, którym dysponuje w danej chwili. Klasyczne podejście — jeden długoterminowy klucz API z pełnym dostępem „na wszelki wypadek” — przy agentach przestaje działać. Agent bywa podatny na prompt injection, halucynuje wywołania narzędzi i działa autonomicznie między kontrolami człowieka. Jeśli przejmie go atakujący albo agent po prostu się pomyli, granicą szkody jest zakres tokenu, który trzyma w ręku. Stąd pytanie, na które odpowiada ten artykuł.

Czym jest bezpieczeństwo oparte na uprawnieniach dla narzędzi agenta?

Bezpieczeństwo oparte na uprawnieniach (ang. capability-based security) to model, w którym dostęp do zasobu reprezentuje niepodrabialny token uprawnienia — wskazuje konkretny obiekt i przypisany do niego zestaw praw. Zamiast pytać „kim jesteś?” i sprawdzać to za każdym razem w centralnej liście kontroli dostępu, system pyta „co masz prawo zrobić?” — a dowodem jest sama posiadana zdolność (capability). Dla agenta oznacza to, że nie dostaje on tożsamości z hurtowym dostępem, lecz wąski żeton uprawniający do jednej operacji na jednym zasobie.

W praktyce minimalne uprawnienia agenta egzekwuje się przez trzy zazębiające się mechanizmy: tokeny o wąskim zakresie (o krótkim czasie życia, ograniczone do konkretnych zakresów i odbiorców), uprawnienia per narzędzie (każde wywołanie narzędzia sprawdzane wobec deklaratywnej reguły) oraz capabilities w stylu obiektowym (ang. object capabilities, ocap) — przekazywalne żetony, które można jedynie zawęzić, nigdy poszerzyć. Razem sprowadzają zasadę najmniejszego przywileju z teorii do działającego mechanizmu wykonawczego (runtime’u).

Kluczowa różnica wobec tradycyjnego RBAC: w modelu capabilities posiadanie żetonu jest autoryzacją. Nie ma osobnego pytania „czy ten podmiot ma prawo?” — fakt, że agent trzyma capability do odczytu dokumentu projekt-abc, sam w sobie jest tym prawem i niczym więcej. To eliminuje całą klasę błędów typu confused deputy, gdy uprzywilejowany pośrednik (np. serwer narzędzi) wykonuje operację w imieniu mniej uprzywilejowanego rozkazodawcy, nie sprawdzając, czy ten miał do niej prawo.

Dlaczego długoterminowy klucz API to dla agenta zła architektura?

Bo agent łączy trzy cechy, które razem czynią szeroki dostęp wyjątkowo groźnym. Po pierwsze, przetwarza niezaufane wejście — treść stron, maili, wyników wyszukiwania — a każdy z tych kanałów może nieść wstrzyknięty rozkaz (prompt injection). Po drugie, działa autonomicznie: między decyzjami często nie ma człowieka, który by je zatwierdził. Po trzecie, sam wybiera narzędzia na podstawie tekstu, więc może sięgnąć po operację, której nikt świadomie nie zlecił.

Przy jednym kluczu z pełnym dostępem promień rażenia tych pomyłek to całe konto. Atakujący, który przemyci do kontekstu agenta polecenie „prześlij zawartość bazy klientów na ten adres”, dostaje dokładnie te uprawnienia, które ma klucz. Token o wąskim zakresie i krótkim czasie życia odwraca tę logikę: jeśli agent padnie albo użytkownik cofnie zgodę, token wygasa i nie da się go już użyć. To bezpieczniejsze niż wręczanie agentowi osobistego, długoterminowego klucza i ogranicza szkodę, gdy agent zostanie przejęty przez atakującego.

Warto też rozdzielić dwie tożsamości w jednym żądaniu. Gdy agent działa „w imieniu” użytkownika (wzorzec On-Behalf-Of), token powinien reprezentować obie strony naraz: użytkownika, który zainicjował akcję, i agenta, który ją wykonuje. Ta relacja powinna być zapisana w ustrukturyzowanych, weryfikowalnych roszczeniach (claims) wewnątrz samego tokenu, najlepiej powiązanych z tożsamością kryptograficzną agenta — żeby serwer zasobu wiedział nie tylko „czyje to uprawnienie”, ale też „kto nim faktycznie operuje”.

Jak działa token o wąskim zakresie w praktyce?

Najprostszy i najlepiej wspierany dziś wzorzec opiera się na OAuth 2.1 i tokenach JWT o krótkim czasie życia, z jawnymi zakresami i roszczeniami. Specyfikacja Model Context Protocol (MCP) w wersji z końca 2025 r. wymaga OAuth 2.1 do uwierzytelniania zdalnych serwerów narzędzi. Token, który agent dostaje, ma trzy własności, które razem dają wąski zakres.

• Krótki czas życia (TTL). Token wygasa po minutach, nie miesiącach. Skraca to okno, w którym wyciek cokolwiek znaczy.
• Wskazanie odbiorcy (audience). Mechanizm Resource Indicators (RFC 8707) wiąże token z konkretnym serwerem zasobu, więc nie da się go „przekierować” do innego API.
• Zakresy gruboziarniste i drobnoziarniste. Obok zakresów ogólnych (mcp:tools:read) stosuje się precyzyjne (document:read:projekt-abc) — egzekwowane po stronie serwera przy każdym wywołaniu.

Dla delegacji między agentami dochodzi wymiana tokenów (RFC 8693): token orkiestratora wymienia się na węższy token zakresowany do dziedziny podagenta. Podagent dostaje wyłącznie te uprawnienia, które orkiestrator jawnie mu przekazał — ani jednego więcej. To jest atenuacja (zawężanie) w czystej postaci i bezpośredni odpowiednik tego, co w modelu capabilities robi się z żetonami obiektowymi.

Capabilities w stylu obiektowym a tokeny zakresowe — czym się różnią?

Oba podejścia realizują tę samą zasadę, ale na innym poziomie abstrakcji. Token zakresowy OAuth to dziś najbardziej praktyczna droga, bo ma gotowe biblioteki, serwery autoryzacyjne i standardy. Capabilities obiektowe (ocap) to model głębszy: żeton nie odsyła do centralnej listy uprawnień, lecz sam jest prawem dostępu do konkretnego obiektu, i da się go przekazywać oraz dzielić, zawsze tylko w dół (zawężając).

Najczystszą reprezentacją capability dla narzędzia MCP jest podpisana krotka: identyfikuje narzędzie, ogranicza dopuszczalne parametry, zawęża typ operacji (odczyt / zapis / wykonanie), nosi czas życia (TTL) i ma podpis kryptograficzny wiążący ją z wystawiającym ją organem. Taki żeton jest niepodrabialny i zawiera wszystko, czego trzeba do weryfikacji — serwer zasobu sprawdza podpis, a nie odpytuje bazę uprawnień.

Cecha	Token zakresowy (OAuth 2.1 / JWT)	Capability obiektowa (ocap)
Co reprezentuje	tożsamość + przyznane zakresy	bezpośrednie prawo do konkretnego obiektu
Sprawdzenie	zakres po stronie serwera zasobu	posiadanie żetonu = autoryzacja
Delegacja	wymiana tokenów (RFC 8693)	przekazanie żetonu, tylko z zawężeniem
Dojrzałość ekosystemu	wysoka (gotowe standardy, biblioteki)	niższa — wzorzec projektowy, mniej gotowców
Ryzyko confused deputy	wymaga jawnego sprawdzania	wbudowana odporność

W realnym wdrożeniu te światy się spotykają. Token zakresowy z wąskim odbiorcą, krótkim TTL i drobnoziarnistym zakresem to praktyczny odpowiednik atenuacji capability. Dlatego nie trzeba wybierać dogmatycznie: zwykle buduje się na OAuth, a myślenie kategoriami capabilities służy jako reguła projektowa — „nigdy nie poszerzaj, tylko zawężaj”.

Jak wymusić uprawnienia per narzędzie?

Najpraktyczniejszy wzorzec to rejestr narzędzi z bramką uprawnień: pośrednik, który przy każdym wywołaniu sprawdza, czy bieżący kontekst agenta ma prawo użyć danego narzędzia. Wymagania uprawnień przypisuje się do narzędzi deklaratywnie (przy definicji narzędzia, nie w kodzie agenta) i rozstrzyga w momencie wywołania. Agent nie egzekwuje reguł na sobie samym — robi to warstwa pod nim, której agent nie kontroluje.

Dobra bramka rozdziela trzy decyzje, które łatwo pomylić. Uwierzytelnienie odpowiada, kto wywołuje narzędzie (agent oraz użytkownik, w imieniu którego działa). Autoryzacja odpowiada, czy ten kontekst ma prawo do tego narzędzia z tymi parametrami. Polityka dokłada ograniczenia kontekstowe — limity tempa, godziny, progi kwotowe, wymóg potwierdzenia człowieka przy operacjach nieodwracalnych. Operacje o wysokim ryzyku (przelew, usunięcie, wysyłka na zewnątrz) warto trzymać za bramką „human-in-the-loop”, nawet gdy token formalnie na nie pozwala.

Reguła praktyczna: zawężaj parametry, nie tylko narzędzia. Samo przyznanie agentowi narzędzia „wyślij e-mail” to wciąż za szeroko. Capability powinna ograniczać dopuszczalne wartości — np. nadawcę, listę dozwolonych odbiorców albo domenę. Tak właśnie wygląda definicja capability MCP, która oprócz wskazania narzędzia ogranicza jego parametry i typ operacji.

Jakie są typowe pułapki wdrożenia minimalnych uprawnień?

Najczęstszy błąd to TTL ustawiony na wyrost. Długi token „dla wygody” niweczy całą korzyść — promień rażenia wraca do poziomu klucza statycznego. Drugi to zakresy pozornie wąskie, w praktyce szerokie: tools:write brzmi precyzyjnie, dopóki nie zauważymy, że obejmuje też kasowanie. Trzeci to brak wskazania odbiorcy — token bez audience (RFC 8707) można przedstawić innemu serwerowi, niż dla którego był przeznaczony.

Czwarta pułapka dotyczy delegacji: orkiestrator, który przekazuje podagentowi własny, pełny token zamiast wymienić go na węższy, łamie atenuację — podagent dostaje całą władzę przełożonego. Piąta to cofanie dostępu wyłącznie przez wygaśnięcie: przy operacjach krytycznych potrzebny jest też aktywny mechanizm unieważniania (revocation), bo czekanie na wygaśnięcie tokenu bywa za wolne.

Szósta, najbardziej podstępna: logowanie i audyt traktowane jako dodatek. Skoro żeton sam jest autoryzacją, ślad „kto, czym, kiedy i w czyim imieniu” musi być rejestrowany przy każdym wywołaniu — inaczej po incydencie nie odtworzymy, co agent faktycznie zrobił. Audytowalna delegacja to nie luksus, lecz warunek, by w ogóle dało się ufać autonomii agenta.

Lista kontrolna: minimalne uprawnienia agenta krok po kroku

Poniższe punkty łączą tokeny zakresowe, uprawnienia per narzędzie i myślenie capability w jeden, wdrażalny ciąg decyzji.

• Żadnych długoterminowych kluczy w rękach agenta. Tylko tokeny o krótkim czasie życia, z wyraźnym TTL.
• Wskaż odbiorcę. Każdy token związany z konkretnym serwerem zasobu (RFC 8707).
• Schodź do drobnoziarnistych zakresów. Obok mcp:tools:read używaj precyzyjnych w stylu document:read:projekt-abc.
• Zawężaj parametry, nie tylko narzędzia. Capability ogranicza dopuszczalne wartości operacji.
• Bramka uprawnień przed agentem. Reguły deklaratywne przy narzędziu, rozstrzygane przy wywołaniu — nie w kodzie agenta.
• Delegacja tylko przez zawężanie. Wymiana tokenów (RFC 8693) na węższy zakres dla podagenta; nigdy przekazanie pełnego tokenu.
• Dwie tożsamości w żądaniu. Token nosi i użytkownika, i agenta, w weryfikowalnych roszczeniach (wzorzec OBO).
• Człowiek przy operacjach nieodwracalnych. Przelew, usunięcie, wysyłka na zewnątrz — za bramką potwierdzenia.
• Aktywne unieważnianie + audyt. Możliwość cofnięcia dostępu szybciej niż przez wygaśnięcie oraz log każdego wywołania.

Sednem nie jest wybór jednej technologii, lecz przesunięcie pytania z „komu ufamy” na „co dokładnie wolno zrobić w tym wywołaniu”. Tokeny o wąskim zakresie dają to dziś na gotowych standardach OAuth 2.1 i MCP; capabilities obiektowe pokazują kierunek, w którym warto myśleć o każdym żetonie — jako o prawie, które można już tylko zawężać.

Uwaga redakcyjna: artykuł ma charakter edukacyjny i nie zawiera płatnych rekomendacji produktowych. Wszystkie wzorce (OAuth 2.1, MCP, RFC 7523/8693/8707, model capabilities) są publicznymi standardami i pojęciami, które należy zweryfikować z aktualną dokumentacją przed wdrożeniem produkcyjnym.