--- title: "Co to są uprawnienia agentów AI? Poradnik dla firm" url: "https://majchrzycki.com/blog/co-to-jest-uprawnienia-agentow-ai-poradnik-dla-firm" description: "Dlaczego agent AI potrzebuje własnej tożsamości, jak działają RBAC, ABAC i ReBAC, kto zatwierdza działania agenta i od czego zacząć mapę uprawnień." --- # Co to są uprawnienia agentów AI? Poradnik dla firm 6 października 2026· Aktualizacja: 6 października 2026·10 min czytania·[Krzysztof Majchrzycki](https://majchrzycki.com/o-mnie) Temat: [Bezpieczeństwo i utrzymanie AI](https://majchrzycki.com/blog/filar/bezpieczenstwo-i-utrzymanie-ai) **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](https://majchrzycki.com/blog/filar/bezpieczenstwo-i-utrzymanie-ai). Czym jest sam agent i dlaczego jego uprawnienia rosną razem z autonomią, wyjaśnia [poradnik o agentach AI](https://majchrzycki.com/blog/co-to-jest-agent-ai-poradnik-dla-firm). ## 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](https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities) 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](https://csrc.nist.gov/glossary/term/least_privilege) 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](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM03_ExcessiveAgency.md) 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](https://majchrzycki.com/blog/dostep-agenta-ai-do-danych-firmy). ## 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ł. Jak agent AI dostaje dostęp: cztery kroki. Tożsamość — własne konto agenta z właścicielem albo uprawnienia delegowane przez użytkownika. Polityka — reguła sprawdza podmiot, akcję, zasób i kontekst; wynik: zezwól, odmów albo zezwól po zatwierdzeniu człowieka. System docelowy — wykonuje działanie tylko po pozytywnej decyzji, model nie decyduje. Audyt — zapis tożsamości, akcji, zasobu, wersji polityki, wyniku i osoby zatwierdzającej. Jak agent dostaje dostęp: tożsamość, polityka, system docelowy, audyt. Uproszczenie autora na podstawie OWASP GenAI LLM Top 10 2026 i dokumentacji Microsoft Entra Agent ID. W agentach korzystających z Model Context Protocol część tych kroków opisuje sama specyfikacja. W wersji 2026-07-28 [autoryzacja MCP](https://modelcontextprotocol.io/specification/latest/basic/authorization) 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](https://majchrzycki.com/blog/co-to-jest-mcp-poradnik-dla-firm). ## 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](https://csrc.nist.gov/projects/role-based-access-control) 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](https://csrc.nist.gov/pubs/sp/800/162/upd2/final) 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](https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/) (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ą. Karta „RBAC, ABAC czy ReBAC?”. RBAC: dostęp wynika ze stanowiska, ról jest kilka — przykład: obsługa reklamacji czyta umowy. ABAC: potrzebne są warunki, takie jak klasyfikacja danych, kwota, dział lub godzina — przykład: tylko umowy bez klauzuli poufne. ReBAC: dostęp wynika z relacji, takich jak opiekun klienta, członek projektu lub właściciel — przykład: tylko opiekun klienta A. Najczęściej łączy się modele: role wyznaczają ogólny zakres, atrybuty i relacje rozstrzygają o konkretnym rekordzie. Uproszczenie autora. RBAC, ABAC czy ReBAC? Kiedy który model wystarcza i jak się je łączy. Uproszczenie autora na podstawie NIST i artykułu o Zanzibarze. 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](https://majchrzycki.com/blog/rbac-abac-rebac-uprawnienia-agentow-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](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM03_ExcessiveAgency.md) 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](https://majchrzycki.com/blog/agent-ai-kto-zatwierdza-decyzje). ## 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](https://majchrzycki.com/blog/co-to-jest-obserwowalnosc-ai-poradnik-dla-firm). 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](https://www.microsoft.com/licensing/terms/productoffering/Agent365/EAEAS) 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](https://majchrzycki.com/blog/co-to-jest-ai-os-poradnik-dla-firm). ## 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](https://majchrzycki.com/wspolpraca/prezentacja-systemu-ai-dla-zarzadu): 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](https://majchrzycki.com/blog/rbac-abac-rebac-uprawnienia-agentow-ai) — porównanie trzech modeli z przykładem i testami odmowy. - [RBAC: dostęp agentów AI](https://majchrzycki.com/blog/rbac-agent-ai-os) — role użytkownika, usługi i agenta. - [ABAC: dostęp agentów AI](https://majchrzycki.com/blog/abac-agent-ai-os) — warunki zależne od działu, klasyfikacji i czasu. - [ReBAC: dostęp agentów AI](https://majchrzycki.com/blog/rebac-agent-ai-os) — 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](https://majchrzycki.com/blog/cerbos-agent-autoryzacja) — punkt decyzji oddzielony od kodu aplikacji. - [Cedar Policy: dostęp agentów AI](https://majchrzycki.com/blog/cedar-policy-agent-ai-os) — język i silnik polityk. - [SpiceDB: dostęp agentów AI](https://majchrzycki.com/blog/spicedb-agent-rebac) — 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](https://majchrzycki.com/blog/keycloak-tozsamosc-agentow-ai-os) — logowanie i tokeny w otwartym stosie. - [Univention Nubus: katalog tożsamości dla AI OS](https://majchrzycki.com/blog/univention-nubus-tozsamosc-suwerenna-ai-os) — użytkownicy i grupy w prywatnej chmurze. - [FreeIPA: tożsamość serwerów Linux pod kontrolą firmy](https://majchrzycki.com/blog/freeipa-linux-iam-ai-os) — konta i hosty, na których pracuje AI. - [Casdoor: SSO z interfejsem dla aplikacji AI OS](https://majchrzycki.com/blog/casdoor-sso-aplikacje-ai-os) — wspólne logowanie wielu aplikacji. - [Authentik w AI OS: SSO i brama do starszych aplikacji](https://majchrzycki.com/blog/authentik-sso-proxy-ai-os) — logowanie także dla paneli bez własnego SSO. - [Authelia: lekka kontrola dostępu przed panelem AI](https://majchrzycki.com/blog/authelia-reverse-proxy-ai-os) — 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](https://majchrzycki.com/blog/wireguard-vpn-suwerenny-ai-os) — szyfrowany kanał między węzłami. - [Defguard: WireGuard z tożsamością i kontrolą dostępu](https://majchrzycki.com/blog/defguard-wireguard-iam-ai-os) — 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?](https://majchrzycki.com/blog/dostep-agenta-ai-do-danych-firmy) — zakres dostępu od potrzeby procesu. - [Czy agent AI powinien pamiętać rozmowy z klientem?](https://majchrzycki.com/blog/czy-agent-ai-powinien-pamietac-rozmowy-z-klientem) — pamięć agenta jako dane do kontroli. - [Jak nadać wykonawcy tymczasowy dostęp do danych?](https://majchrzycki.com/blog/tymczasowy-dostep-do-danych-dla-wykonawcy) — dostęp na czas zadania i jego odebranie. ### F. Ryzyka - [OWASP LLM Top 10 2026: dziesięć ryzyk aplikacji z AI](https://majchrzycki.com/blog/owasp-llm-top-10-2026-lista-ryzyk) — w tym nadmierna sprawczość agenta. ### Pokrewne - [Agent przygotował decyzję. Kto za nią odpowiada?](https://majchrzycki.com/blog/agent-ai-kto-zatwierdza-decyzje) — odpowiedzialność za decyzję przygotowaną przez agenta. - [Microsoft Agent 365: kto pilnuje firmowych agentów AI?](https://majchrzycki.com/blog/microsoft-agent-365-zarzadzanie-agentami-ai) — rejestr i nadzór agentów w ekosystemie Microsoft. - [OWASP w AI SDLC: bezpieczeństwo od zadania do wdrożenia](https://majchrzycki.com/blog/owasp-bezpieczenstwo-w-ai-sdlc) — testy bezpieczeństwa w cyklu wytwarzania. - Agenci AI - Bezpieczeństwo - Uprawnienia - Zarząd ## Sprawdźmy, do czego Wasz agent naprawdę potrzebuje dostępu Prezentacja dla zarządu: weźmiemy jednego agenta, rozpiszemy jego tożsamość, dane, działania i miejsca zatwierdzenia przez człowieka — zanim dostanie konto w systemach firmy. Niezależnie od vendora i partnera. [Umów prezentację dla zarządu](https://majchrzycki.com/wspolpraca/prezentacja-systemu-ai-dla-zarzadu) FAQ ## Najczęstsze pytania Czy agent AI może korzystać z konta pracownika? Nie powinien. Na koncie pracownika nie da się odróżnić działań człowieka od działań agenta, agent dostaje wszystkie uprawnienia tej osoby, a po jej odejściu z firmy dostęp agenta wisi w powietrzu. Agent potrzebuje własnej tożsamości z właścicielem i zakresem dopasowanym do zadania. Gdy działa w imieniu użytkownika, dostaje tylko te uprawnienia, które użytkownik mu deleguje. Który model wybrać: RBAC, ABAC czy ReBAC? Najczęściej kilka naraz. RBAC (role) wystarcza, gdy dostęp wynika ze stanowiska i ról jest kilka. ABAC (atrybuty) dokłada warunki: klasyfikację danych, dział, kwotę, godzinę. ReBAC (relacje) pasuje, gdy dostęp wynika z tego, kto jest opiekunem klienta, członkiem projektu albo właścicielem dokumentu. Typowy układ: role wyznaczają ogólny zakres, a atrybuty i relacje rozstrzygają o konkretnym rekordzie. Czy wystarczy napisać w prompcie, czego agentowi nie wolno? Nie. Instrukcja w prompcie to prośba, nie zabezpieczenie. Złośliwa treść w mailu albo dokumencie może ją obejść, a model może się pomylić. OWASP w kategorii Excessive Agency (LLM03:2026) zaleca autoryzację w logice systemu: każde żądanie do systemu docelowego sprawdza narzędzie, niezależny punkt decyzji polityki albo sam system docelowy. Co to jest Microsoft Entra Agent ID? To rozszerzenie Microsoft Entra o tożsamości dla agentów AI: tworzenie ich z szablonów, polityki dostępu, przeglądy i logi. Według dokumentacji Microsoft (stan na 6.10.2026) Agent ID jest dostępny dla wszystkich klientów Microsoft Entra, a rozszerzenie funkcji bezpieczeństwa Entra na agentów wymaga licencji Microsoft Agent 365. Szczegóły licencji trzeba sprawdzić w warunkach produktu przed zakupem. Kiedy agent powinien czekać na zatwierdzenie człowieka? Przy działaniach o dużym skutku albo nieodwracalnych: wypłata pieniędzy, wysyłka do klienta, zmiana warunków umowy, usunięcie danych. Działania odwracalne i o małym skutku mogą przechodzić automatycznie, z zapisem w logu. Granicę ustala właściciel procesu, a egzekwuje ją system, nie model. Kto w firmie odpowiada za uprawnienia agenta? Właściciel procesu decyduje, co agent ma robić i jakie działania wymagają zatwierdzenia. Administrator tożsamości przekłada to na konto, role i polityki. Właściciel danych określa, co agent może czytać. Zespół bezpieczeństwa przegląda logi i incydenty. Każdy agent ma imiennego właściciela, który odpowiada za jego zakres i wyłączenie. Czy otwarte narzędzia autoryzacji są gotowe do użycia w firmie? Projekty takie jak Keycloak, Open Policy Agent, Cedar, Cerbos, OpenFGA czy SpiceDB mają licencję Apache-2.0 i regularne wydania (stan na 6.10.2026). Licencja nie rozwiązuje jednak utrzymania: ktoś musi pisać polityki, testować je i reagować na błędy. Część z nich działa w modelu open-core z usługą komercyjną. Wybór zależy od tego, czy firma ma zespół, który to utrzyma. ## Czytaj dalej - [RBAC, ABAC i ReBAC: uprawnienia agentów AI](https://majchrzycki.com/blog/rbac-abac-rebac-uprawnienia-agentow-ai) - [Do jakich danych agent AI naprawdę potrzebuje dostępu?](https://majchrzycki.com/blog/dostep-agenta-ai-do-danych-firmy) - [Cerbos: dostęp agentów AI](https://majchrzycki.com/blog/cerbos-agent-autoryzacja) - [Keycloak w AI OS: tożsamość ludzi i agentów](https://majchrzycki.com/blog/keycloak-tozsamosc-agentow-ai-os)