Co to są uprawnienia agentów AI? Poradnik dla firm

Uprawnienia agenta AI to odpowiedź na pytanie: jako kto agent działa, co może zobaczyć i co może zrobić — w którym systemie, na którym rekordzie i z czyją zgodą. Agent nie powinien pracować na koncie pracownika ani na wspólnym koncie administratora. Potrzebuje własnej tożsamości z właścicielem, najmniejszego zakresu uprawnień, który wystarcza do zadania, kontroli w systemie docelowym przy każdym działaniu i śladu w logu. Zaczyna się od mapy uprawnień jednego agenta, a nie od zakupu platformy.

Poradnik jest dla zarządu i lidera IT firmy od 50 osób, która uruchamia pierwszego agenta albo porządkuje kilka już działających. Wyjaśnia, dlaczego agent potrzebuje własnej tożsamości, jak działają modele RBAC, ABAC i ReBAC, kiedy zatwierdza człowiek i od czego zacząć. Na końcu jest mapa wszystkich wpisów o uprawnieniach i tożsamości agentów na blogu. Szerszy kontekst odpowiedzialności za działający system daje przewodnik bezpieczeństwo i utrzymanie AI. Czym jest sam agent i dlaczego jego uprawnienia rosną razem z autonomią, wyjaśnia poradnik o agentach AI.

Dlaczego agent potrzebuje własnej tożsamości, a nie konta pracownika

Najprostsza droga wygląda tak: agent dostaje login handlowca albo konto techniczne z hasłem w pliku konfiguracyjnym. Działa od razu. Problemy przychodzą później, i są trzy.

Nie widać, kto działał. W logu CRM stoi „Anna Nowak zmieniła rabat”. Nie wiadomo, czy zrobiła to Anna, czy agent na jej koncie. Przy reklamacji klienta albo kontroli nie da się odtworzyć przebiegu.

Agent dostaje za dużo. Konto pracownika ma wszystkie jego uprawnienia: pocztę, kalendarz, dokumenty kadrowe, dostęp do faktur. Agent do streszczania notatek ze spotkań nie potrzebuje żadnej z tych rzeczy, ale technicznie ma je wszystkie. Wspólne konto administratora jest jeszcze gorsze.

Nie ma kogo zapytać. Pracownik odchodzi, konto jest wyłączane, a agent nagle przestaje działać — albo, co gorsze, konto zostaje aktywne „bo agent musi działać”. Nikt nie wie, kto odpowiada za zakres dostępu.

Dlatego agent potrzebuje własnej tożsamości. Dokumentacja Microsoft Entra opisuje to rozróżnienie wprost: tożsamość agenta reprezentuje oprogramowanie, a nie człowieka, i nie używa haseł ani uwierzytelniania wieloskładnikowego przeznaczonego dla ludzi. Różni się też od zwykłej tożsamości aplikacji, bo agenci powstają i znikają szybciej niż klasyczne usługi.

Ta sama dokumentacja rozróżnia dwa tryby pracy, które warto znać niezależnie od vendora:

• agent działa samodzielnie — korzysta z uprawnień nadanych jego własnej tożsamości; dobre dla zadań w tle, na przykład porządkowania zgłoszeń,
• agent działa w imieniu użytkownika — korzysta z uprawnień delegowanych przez konkretną osobę i nigdy nie widzi więcej niż ona; dobre dla asystenta, który pracuje na dokumentach pytającego.

Każda tożsamość agenta ma właściciela, czyli osobę, która odpowiada za jej zakres i wyłączenie. W Copilot Studio twórca agenta jest zapisywany jako jego sponsor (stan na 6.10.2026). W innych narzędziach trzeba to ustalić samodzielnie.

Zasada najmniejszych uprawnień w praktyce

NIST definiuje zasadę najmniejszych uprawnień prosto: każdy podmiot dostaje tylko te zasoby i autoryzacje, które są potrzebne do jego funkcji. Dotyczy to także procesów działających w imieniu użytkowników — czyli agentów.

OWASP w opisie ryzyka Excessive Agency (nadmierna sprawczość) wskazuje trzy przyczyny, przez które agent wyrządza szkodę. Dobrze nadają się na listę kontrolną dla zarządu.

Nadmiar	Przykład z opisu OWASP	Pytanie kontrolne
Funkcjonalność	narzędzie do czytania dokumentów potrafi też je zmieniać i usuwać; narzędzie z testów zostało podłączone	Czy agent ma tylko te narzędzia i funkcje, których używa?
Uprawnienia	narzędzie do odczytu łączy się z bazą kontem, które może też zapisywać i usuwać; asystent jednej osoby używa konta z dostępem do plików wszystkich	Czy konto agenta w systemie docelowym ma tylko potrzebne prawa?
Autonomia	narzędzie usuwa dokumenty bez potwierdzenia użytkownika	Czy działania o dużym skutku czekają na człowieka?

W praktyce oznacza to osobne konto agenta w każdym systemie, z prawami „tylko odczyt” tam, gdzie wystarczy odczyt. Zamiast narzędzia „uruchom dowolne polecenie” — wąskie narzędzie „zapisz notatkę w sprawie”. Zamiast dostępu do całego CRM — dostęp do spraw, w których pytający jest opiekunem. Szczegółowo, jak ustalić ten zakres w procesie, opisuje wpis do jakich danych agent AI naprawdę potrzebuje dostępu.

Jak agent dostaje dostęp: cztery kroki

Każde działanie agenta w systemie firmy przechodzi przez cztery kroki. Jeśli któregoś brakuje, w tym miejscu jest luka.

1. Tożsamość. Agent uwierzytelnia się własną tożsamością (albo z uprawnieniami delegowanymi przez użytkownika) i dostaje token z określonym zakresem. Na tym etapie wiadomo, kto pyta.

2. Polityka. Punkt decyzji sprawdza regułę: czy ten podmiot może wykonać tę akcję na tym zasobie w tym kontekście. Wynik to „zezwól”, „odmów” albo „zezwól po zatwierdzeniu człowieka”.

3. System docelowy. CRM, ERP albo serwer narzędzia wykonuje działanie tylko po pozytywnej decyzji i sam sprawdza, czy token był wydany dla niego. Model nie ma tu głosu.

4. Audyt. Zapis: która tożsamość, w czyim imieniu, jaka akcja, jaki zasób, jaka wersja polityki, jaki wynik i kto zatwierdził.

W agentach korzystających z Model Context Protocol część tych kroków opisuje sama specyfikacja. W wersji 2026-07-28 autoryzacja MCP jest opcjonalna, a przy transporcie HTTP opiera się na OAuth 2.1. Serwer MCP nie może przyjmować ani przekazywać dalej tokenów wydanych dla innych zasobów, a klient powinien prosić o minimalne zakresy. „Opcjonalna” znaczy, że trzeba sprawdzić, czy konkretny serwer ją w ogóle ma. Rolę MCP w architekturze agenta opisuje poradnik o MCP.

RBAC, ABAC i ReBAC prostym językiem

Polityka z kroku 2 musi być zapisana w jakimś modelu. Są trzy główne. Najprościej pokazać je na jednym przykładzie: agent przygotowuje odpowiedź na reklamację i chce przeczytać umowę klienta A.

Model	Na czym opiera decyzję	Reguła w przykładzie	Kiedy wystarcza
RBAC — role	rola podmiotu	rola „obsługa reklamacji” może czytać umowy	kilka ról, dostęp wynika ze stanowiska
ABAC — atrybuty	cechy podmiotu, zasobu, akcji i kontekstu	czytać można umowy bez klauzuli „poufne”, z działu pytającego, w godzinach pracy	potrzebne warunki: klasyfikacja, kwota, dział, czas
ReBAC — relacje	powiązania w grafie osób i zasobów	czytać może tylko opiekun klienta A albo członek jego zespołu	dostęp wynika z członkostwa, własności i delegacji

RBAC jest najstarszy i najłatwiejszy do audytu. NIST opisuje go jako model, w którym użytkownicy dostają role, a role uprawnienia; standard ANSI/INCITS 359 powstał w 2004 r. Kłopot zaczyna się, gdy firma tworzy osobną rolę dla każdego klienta i wyjątku. Po roku nikt nie wie, czym różni się „handlowiec_B2B_2” od „handlowiec_B2B_nowy”.

ABAC dokłada warunki. NIST SP 800-162 definiuje go jako ocenę atrybutów podmiotu, obiektu, operacji i warunków środowiska względem polityki. Działa dobrze, gdy atrybuty są wiarygodne. Jeśli połowa umów nie ma oznaczenia poufności, reguła musi wtedy odmówić, a nie zgadywać.

ReBAC opiera dostęp na relacjach: kto jest opiekunem klienta, kto należy do projektu, kto jest właścicielem folderu. Ten model spopularyzował artykuł Google o systemie Zanzibar (USENIX ATC 2019), który opisuje wspólny system autoryzacji m.in. dla Kalendarza, Dysku i YouTube. Pasuje do agentów, bo „agent widzi to, co widzi jego zleceniodawca” jest właśnie relacją.

Nie trzeba wybierać jednego. Typowy układ: role wyznaczają ogólny zakres („obsługa reklamacji czyta umowy”), atrybut wyklucza dokumenty poufne, a relacja ogranicza odczyt do klientów, których pytający obsługuje. Ważne, żeby decyzja przechodziła jedną ścieżką i dawała jeden zapis w logu. Szczegółowe porównanie z przykładem polityki opisuje wpis RBAC, ABAC i ReBAC: uprawnienia agentów AI.

Autoryzacja w systemie docelowym, nie w prompcie

Najczęstszy błąd w pilotach: zabezpieczenie zapisane w instrukcji agenta. „Nie wysyłaj ofert powyżej 50 tys. zł bez zgody kierownika.” Model zwykle się zastosuje. Zwykle.

OWASP w kategorii Excessive Agency — w wydaniu 2026 oznaczonej jako LLM03:2026, w wydaniu 2025 jako LLM06 — opisuje to jako problem, który nie zależy od przyczyny błędu modelu. Agent może zrobić szkodę przez halucynację, przez prompt injection w mailu od klienta albo przez zmanipulowanego innego agenta. Dlatego OWASP zaleca między innymi:

• autoryzację w logice, nie w modelu — każde żądanie do systemu docelowego jest sprawdzane przez narzędzie, niezależny punkt decyzji polityki albo sam system docelowy (zasada pełnej mediacji, complete mediation),
• minimalne uprawnienia egzekwowane w systemie docelowym — na przykład uprawnienia bazy danych dla konta, którym łączy się narzędzie agenta,
• wykonywanie w kontekście użytkownika — także w łańcuchu kilku agentów zachowuje się zakres pierwotnego zleceniodawcy, a nie szersze prawa agenta pośredniczącego.

Model językowy zapytany, czy wolno mu wykonać przelew, odpowie uprzejmie i z dużym przekonaniem. To nie jest autoryzacja, tylko opinia. Decyzję podejmuje reguła w kodzie, a model może najwyżej zaproponować działanie.

OWASP zastrzega też, że monitorowanie i limity wywołań nie zapobiegają nadmiernej sprawczości. Ograniczają tylko szkody, gdy coś już poszło źle. Potrzebne są oba poziomy: blokada w systemie docelowym i widoczność w logach.

Kiedy działanie agenta zatwierdza człowiek

Zatwierdzanie wszystkiego zabija sens agenta. Brak zatwierdzania zostawia firmę z ryzykiem, którego nikt nie wycenił. OWASP proponuje stopniowanie: audyt, ostrzeżenie, blokada, eskalacja do człowieka. Działania odwracalne i o małym skutku przechodzą automatycznie, nieodwracalne i o dużym skutku czekają na człowieka. Przykład z opisu OWASP: zwrot w formie bonu na zakupy może przejść automatycznie, bo da się go cofnąć, a wypłata na zewnętrzne konto trafia do zatwierdzenia.

Proponuję prosty podział na trzy poziomy (podział autora). Granice ustala właściciel procesu.

Poziom	Przykłady działań	Co robi system
Automatycznie, z zapisem	odczyt sprawy, szkic odpowiedzi, notatka w CRM, kategoria zgłoszenia	wykonuje i zapisuje w logu
Automatycznie w limicie	rabat do progu, bon zamiast zwrotu, przesunięcie terminu o kilka dni	wykonuje w granicy, powyżej przekazuje człowiekowi
Zawsze człowiek	wypłata pieniędzy, wysyłka umowy, zmiana warunków handlowych, usunięcie danych	przygotowuje, czeka na zatwierdzenie, zapisuje, kto zatwierdził

Zatwierdzenie musi być egzekwowane w systemie, nie w instrukcji. Przycisk „zatwierdź” w panelu niewiele daje, jeśli agent ma też techniczną możliwość wysłania przelewu bez niego. Kto odpowiada za decyzję przygotowaną przez agenta, rozwija wpis agent przygotował decyzję — kto za nią odpowiada.

Audyt: co musi zostać w logu

Audyt odpowiada na pytanie, które padnie przy pierwszym incydencie: kto to zrobił i dlaczego system na to pozwolił. Dla każdego działania agenta w logu powinno być:

• tożsamość agenta i, jeśli działał w imieniu użytkownika, tożsamość tej osoby,
• akcja i zasób, czyli co agent zrobił i na którym rekordzie,
• decyzja polityki z jej wersją, także odmowy,
• osoba zatwierdzająca przy działaniach z zatwierdzeniem,
• identyfikator sprawy, który łączy ten zapis ze śladem całej rozmowy.

Odmowy są równie ważne jak zgody. Seria odmów to sygnał, że agent próbuje robić coś poza zakresem — przez błąd w instrukcji albo przez atak. Dokumentacja Entra podaje, że uwierzytelnienia i aktywność tożsamości agentów są logowane do celów zgodności i audytu (stan na 6.10.2026). W otwartym stosie trzeba to zbudować samodzielnie.

Log uprawnień to część szerszej obserwowalności systemu AI. Jak połączyć go ze śladami wywołań, kosztami i oceną jakości, opisuje poradnik o obserwowalności AI. Okresowo, na przykład co kwartał, właściciel agenta przegląda też jego uprawnienia i usuwa nieużywane.

Narzędzia: jaka jest ich rola

Zamiast rankingu — role. Licencje i wersje sprawdzone w repozytoriach projektów i dokumentacji vendorów, stan na 6.10.2026.

Rola	Przykłady	Licencja / forma	Uwagi
Tożsamość agentów w ekosystemie Microsoft	Microsoft Entra Agent ID	usługa Microsoft Entra	dokumentacja: dostępny dla wszystkich klientów Entra; funkcje bezpieczeństwa dla agentów wymagają Agent 365
Rejestr i nadzór agentów	Microsoft Agent 365	usługa Microsoft, licencja per użytkownik	ogólnie dostępny od 1.05.2026 (Commercial)
Tożsamość i logowanie (IAM) w otwartym stosie	Keycloak 26.8.0	Apache-2.0	konta, logowanie, tokeny; nie rozstrzyga o konkretnym rekordzie
Polityki ogólnego przeznaczenia	Open Policy Agent v1.21.1	Apache-2.0	decyzje polityk dla usług, API i infrastruktury
Język polityk	Cedar (CLI v4.13.0)	Apache-2.0	polityki zapisane jako reguły, analizowalne przed wdrożeniem
Punkt decyzji dla aplikacji	Cerbos v0.56.0	Apache-2.0, model open-core	aplikacja pyta przed działaniem, czy wolno
Uprawnienia oparte na relacjach	OpenFGA v1.21.0, SpiceDB v1.56.2	Apache-2.0	oba inspirowane Zanzibarem

Trzy uwagi przy wyborze.

Tożsamość i autoryzacja to dwie różne rzeczy. Keycloak albo Entra odpowiadają, kto pyta. Silnik polityk odpowiada, czy wolno. Firma, która ma tylko pierwsze, ma dobrze zalogowanego agenta z za szerokim dostępem.

Najpierw sprawdźcie, co już macie. Jeśli firma pracuje na Microsoft 365 i Entra, tożsamości agentów z Copilot Studio i tak powstaną w tenancie. Warto je objąć tymi samymi zasadami co resztę. Warunki licencji Agent 365 trzeba sprawdzić w warunkach produktu przed zakupem.

Licencja to nie utrzymanie. Projekty otwarte mają licencję Apache-2.0, ale ktoś musi pisać polityki, testować je i reagować na błędy. Miejsce tych narzędzi w otwartym stosie pokazuje poradnik o AI OS.

Jak zacząć: mapa uprawnień jednego agenta

Nie zaczynajcie od silnika polityk. Zacznijcie od jednego agenta, który już działa albo zaraz ruszy w pilocie, i rozpiszcie go na kartce.

Krok 1. Właściciel i tożsamość. Kto odpowiada za tego agenta? Czy działa samodzielnie, czy w imieniu użytkownika? Jakie konto ma w każdym systemie — i czy na pewno nie jest to konto pracownika?

Krok 2. Systemy i dane. Lista systemów, do których agent sięga, i dla każdego: odczyt czy zapis, które obiekty, które pola. Wszystko, czego agent nie używa, usuwacie.

Krok 3. Działania i poziomy. Lista działań agenta przypisana do trzech poziomów: automatycznie, automatycznie w limicie, zawsze człowiek. Dla drugiego poziomu — konkretny próg.

Krok 4. Gdzie jest kontrola. Dla każdego działania: w którym miejscu system sprawdza uprawnienie? Jeśli odpowiedź brzmi „w prompcie”, to znaczy, że kontroli nie ma.

Krok 5. Log i przegląd. Czy log pokazuje tożsamość, akcję, zasób, decyzję i osobę zatwierdzającą? Kiedy właściciel przegląda uprawnienia następnym razem?

Jeśli w kroku 1 nikt nie zgłosi się na właściciela, problem nie leży w technologii. Wtedy potrzebna jest rozmowa zarządu o tym, co agent ma robić i kto za to odpowiada. Na tym polega prezentacja dla zarządu: rozpiszemy tożsamość, dane, działania i miejsca zatwierdzenia jednego agenta, niezależnie od vendora i partnera.

Mapa wpisów o uprawnieniach i tożsamości agentów AI

Wszystkie wpisy o uprawnieniach, tożsamości i dostępie agentów AI w sześciu grupach, plus wpisy pokrewne.

A. Modele uprawnień

Jak zapisać regułę: role, atrybuty, relacje.

• RBAC, ABAC i ReBAC: uprawnienia agentów AI — porównanie trzech modeli z przykładem i testami odmowy.
• RBAC: dostęp agentów AI — role użytkownika, usługi i agenta.
• ABAC: dostęp agentów AI — warunki zależne od działu, klasyfikacji i czasu.
• ReBAC: dostęp agentów AI — dostęp wynikający z relacji osób i zasobów.

B. Silniki polityk i autoryzacji

Gdzie zapada decyzja „wolno / nie wolno”.

• Cerbos: dostęp agentów AI — punkt decyzji oddzielony od kodu aplikacji.
• Cedar Policy: dostęp agentów AI — język i silnik polityk.
• SpiceDB: dostęp agentów AI — baza relacji w modelu Zanzibar.

C. Tożsamość i logowanie

Kto pyta: katalogi, SSO, konta ludzi i agentów.

• Keycloak w AI OS: tożsamość ludzi i agentów — logowanie i tokeny w otwartym stosie.
• Univention Nubus: katalog tożsamości dla AI OS — użytkownicy i grupy w prywatnej chmurze.
• FreeIPA: tożsamość serwerów Linux pod kontrolą firmy — konta i hosty, na których pracuje AI.
• Casdoor: SSO z interfejsem dla aplikacji AI OS — wspólne logowanie wielu aplikacji.
• Authentik w AI OS: SSO i brama do starszych aplikacji — logowanie także dla paneli bez własnego SSO.
• Authelia: lekka kontrola dostępu przed panelem AI — ochrona wejścia za reverse proxy.

D. Sieć i dostęp zdalny

Kanał, którym łączą się węzły i ludzie — nie zastępuje autoryzacji.

• WireGuard dla AI OS: bezpieczny tunel, nie cała polityka — szyfrowany kanał między węzłami.
• Defguard: WireGuard z tożsamością i kontrolą dostępu — kto dostaje tunel i jak go odwołać.

E. Dane i dostęp w procesie

Ile danych potrzebuje agent i jak długo.

• Do jakich danych agent AI naprawdę potrzebuje dostępu? — zakres dostępu od potrzeby procesu.
• Czy agent AI powinien pamiętać rozmowy z klientem? — pamięć agenta jako dane do kontroli.
• Jak nadać wykonawcy tymczasowy dostęp do danych? — dostęp na czas zadania i jego odebranie.

F. Ryzyka

• OWASP LLM Top 10 2026: dziesięć ryzyk aplikacji z AI — w tym nadmierna sprawczość agenta.

Pokrewne

• Agent przygotował decyzję. Kto za nią odpowiada? — odpowiedzialność za decyzję przygotowaną przez agenta.
• Microsoft Agent 365: kto pilnuje firmowych agentów AI? — rejestr i nadzór agentów w ekosystemie Microsoft.
• OWASP w AI SDLC: bezpieczeństwo od zadania do wdrożenia — testy bezpieczeństwa w cyklu wytwarzania.