aiversum

Rozdział 8

Kontrola dostępu oparta na rolach i ścieżka audytu (RBAC, audit trail): co to jest i jak kontrolować agentów AI

Kontrola dostępu oparta na rolach (RBAC) przydziela uprawnienia rolom, a role ludziom i agentom AI. Ścieżka audytu (audit trail) to dziennik, który zapisuje, kto, kiedy i co zrobił. Razem mówią zarządowi, co agent może zrobić i co naprawdę zrobił.

Przegląd: 26 września 2026Autor: Damian Świderek

Kontrola i raporty

C1

Role i uprawnienia

Każda rola, człowieka i agenta, ma spisany zakres: co czyta, co przygotowuje, czego nie dotyka. Jak w obiegu faktur: księgowa przygotowuje, kierownik podpisuje.

Kto o tym decyduje u Was

IT nadaje dostęp i regularnie go przegląda. Zarząd zatwierdza, kto co podpisuje.

Schemat pojęcia, a nie opis produktu Aiversum. Role, sprawy, godziny i nazwy systemów na ekranie to dane przykładowe.

Co z tego działa dziś

  • Działa u klientaLogowanie Entra ID klienta, certyfikat z PKI klienta, Defender
  • Działa u klientaDostęp do CRM przez siedem nazwanych narzędzi, tylko odczyt
  • Działa u klientaWysyłka wyłącznie po zatwierdzeniu szkicu przez człowieka, zatwierdzenie w dzienniku
  • Działa u klientaUdział plikowy klienta jako źródło wiedzy
  • Działa u klientaDziennik silnika (sesje, narzędzia, model) i dziennik panelu (kto, kiedy, jaki plik)

Co ustawiamy przy wdrożeniu

  • Role ludzi w panelu (np. kierownik, administrator, audytor)
  • Zdarzenia agentów w SIEM klienta (np. Microsoft Sentinel)
  • Alerty o zachowaniu agenta dla SOC
  • Przycisk „zatrzymaj agenta” w panelu
  • Agent raportowy o stanie firmy (program liczy, model opisuje, człowiek zatwierdza)
Pełny rejestr z datą: /stan

Co to znaczy dla Twojej firmy

Koszt

Kontrola kosztuje przede wszystkim czas ludzi. Ktoś spisuje role agenta, ktoś czyta dziennik, ktoś odpowiada na alerty.

Dochodzą opłaty za narzędzia. Microsoft Sentinel nalicza je głównie od ilości przyjętych danych. Dziennik Entra na dłużej niż 30 dni trzeba eksportować do płatnego magazynu.

Zabezpieczenia Entra dla agentów, np. dostęp warunkowy, wymagają u Microsoftu licencji Agent 365. Rola spisana raz służy każdemu kolejnemu agentowi z tym samym zadaniem.

Ryzyko

Nadmierna sprawczość (excessive agency) to ryzyko nr 3 w zestawieniu OWASP na 2026 r. OWASP wskazuje trzy źródła: za dużo funkcji, uprawnień i samodzielności.

Agent na koncie pracownika dziedziczy wszystkie jego prawa. W dzienniku trudno wtedy odróżnić krok agenta od kroku człowieka.

Bez dziennika nie odpowiecie w sporze, kto zatwierdził odpowiedź wysłaną do klienta.

Decyzja

Przed pilotem wskażcie osobę, która nadaje agentowi role i regularnie je przegląda. Ustalcie, kto czyta dziennik: właściciel procesu, IT, audyt wewnętrzny albo zespół bezpieczeństwa (SOC).

Wskażcie też osobę, która może agenta zatrzymać. Sprawdźcie na próbie, ile jej to zajmie.

Pytania do dostawcy i IT

  1. Czy agent ma własną tożsamość w naszym Entra ID, czy działa na koncie pracownika?
  2. Jaką rolę dostaje agent w każdym systemie i czy tylko czyta, czy także zapisuje?
  3. Co trafia do dziennika: narzędzie, model, wynik, zatwierdzenie człowieka, próby odrzucone?
  4. Gdzie leży dziennik, jak długo go trzymamy i kto może zmienić wpis?
  5. Czy dziennik trafi do naszego systemu SIEM, np. Microsoft Sentinel albo Splunk, i w jakim formacie?

Krok po kroku

  1. 01

    Role i uprawnienia

    IT i właściciel procesu spisują role ludzi i agentów. Każda rola mówi, co wolno czytać, a co zmieniać.

  2. 02

    Dziennik i audyt

    Każde działanie trafia do dziennika: kto, co, kiedy i czym. Audytor filtruje wpisy i sprawdza, czy agent trzymał się roli.

  3. 03

    Agent sprawdza agenta

    Drugi agent czyta pracę pierwszego i szuka błędów. Wątpliwą sprawę oddaje do kolejki człowieka.

  4. 04

    SOC widzi agentów

    Zdarzenia z dziennika trafiają do zespołu bezpieczeństwa. Gdy agent wyjdzie poza zakres, analityk blokuje jego konto i bada sprawę.

Jak kontroluje się agenta AI?

Kontrola agenta ma trzy części: tożsamość, uprawnienia i dziennik. Tożsamość mówi, kto działa. Uprawnienia mówią, co mu wolno, a dziennik zapisuje, co zrobił.

Pomyślcie o biurowcu. Pracownik dostaje identyfikator z nazwiskiem i kartę, która otwiera wybrane drzwi. Portiernia zapisuje każde wejście.

Rola to typ karty, np. „księgowość” albo „recepcja”. Nie programujecie drzwi dla każdej osoby osobno. Zmieniacie uprawnienia roli, a zmiana obejmuje wszystkich, którzy ją mają.

Model RBAC opisali w 1992 r. David Ferraiolo i Rick Kuhn z amerykańskiego NIST. W 2004 r. stał się normą ANSI/INCITS 359, zmienioną w 2012 r.

Agent AI dostaje tę samą konstrukcję. Ma własny identyfikator, rolę z listą narzędzi i wpis w dzienniku przy każdym kroku.

Najważniejsza różnica: agent czyta treści od obcych, np. maile od klientów. Taka treść może zawierać ukryte polecenie (prompt injection). Dlatego agent dostaje wąskie, nazwane narzędzia zamiast szerokiego dostępu.

Zasada najmniejszych uprawnień (least privilege) mówi: tyle dostępu, ile wymaga zadanie. NIST opisuje ją w katalogu zabezpieczeń SP 800-53 jako kontrolę AC-6.

Uprawnienia sprawdza program wokół modelu, czyli warstwa kontroli (harness). Model tylko proponuje krok. Program sprawdza rolę i dopiero wtedy wykonuje krok albo go odrzuca.

Dziennik to portiernia z kamerą. Zapisuje wejścia, ale też próby wejścia bez karty. Po incydencie z niego odtwarzacie, co się stało.

RBAC a ABAC: czym się różnią

RBAC (role)ABAC (atrybuty)
Podstawa decyzjiRola osoby albo agentaCechy osoby, zasobu, sprawy i sytuacji
PrzykładRola „obsługa korespondencji” czyta CRM i pisze szkiceAgent czyta tylko sprawy swojego działu, w godzinach pracy biura
Kiedy wystarczaGdy zadania da się podzielić na stałe roleGdy dostęp zależy od klasy dokumentu, klienta albo miejsca
Koszt utrzymaniaNiski przy kilku rolach, rośnie, gdy ról przybywaWyższy: reguły trzeba spisać, przetestować i przeglądać
ŁączenieRola wyznacza zakresAtrybuty zawężają go w konkretnej sprawie

RBAC a ABAC: role czy cechy sprawy

W RBAC uprawnienie wynika z roli. Agent w roli „obsługa korespondencji” czyta dane klienta i pisze szkice odpowiedzi.

W kontroli opartej na atrybutach (ABAC) decyzja zależy też od cech sprawy. Liczy się np. klasa dokumentu, dział klienta albo godzina pracy biura.

Oba podejścia da się łączyć. Rola wyznacza zakres, atrybuty zawężają go w konkretnej sprawie.

Tożsamość agenta: własne konto zamiast hasła pracownika

NIST NCCoE w szkicu z 5.02.2026 r. traktuje agenta jak osobny podmiot w systemie tożsamości. Pyta o identyfikację, autoryzację, audyt, niezaprzeczalność i ochronę przed prompt injection. Niezaprzeczalność znaczy, że nikt nie wyprze się swojego kroku.

Microsoft Entra ID ma dla agentów osobny typ tożsamości (Entra Agent ID). W dziennikach logowań i audytu Entra agent ma własne oznaczenie. Jego logowania i zmiany w katalogu oddzielicie więc od ludzi (Microsoft Learn, strona z 28.04.2026 r.).

Co agent zrobił z mailami i plikami, pokazuje osobno audyt Microsoft Purview.

Podobnie Microsoft opisuje agenta do triażu alertów w Defenderze (dawniej: triażu phishingu). Triaż to wstępna ocena zgłoszenia. Microsoft zaleca temu agentowi osobną tożsamość i rolę z minimum uprawnień.

Grupa nadzorująca agenta ma mieć uprawnienia równe albo wyższe niż on.

Ścieżka audytu: co zapisywać i kto to czyta

Dziennik agenta odpowiada na pytania: kto działał, jakim narzędziem i na jakich danych. Odpowiada też, kto zatwierdził wynik. Zapisujcie również próby odrzucone, bo pokazują próby wyjścia poza rolę.

Wpisu nie powinien móc zmienić ten, kogo wpis dotyczy. Wpisów dziennika audytu Entra nie da się zmienić ani usunąć (Microsoft Learn, strona z 5.06.2026 r.). Portal trzyma je jednak 7 dni w wersji Free i 30 dni w P1/P2.

Na dłużej trzeba je eksportować, np. do magazynu Azure albo systemu SIEM. SIEM to system, który zbiera dzienniki bezpieczeństwa z całej firmy.

Audyt wewnętrzny sprawdza w dzienniku, czy agent trzymał się roli. Audytor zewnętrzny albo organ kontroli dostaje wyciąg za wskazany okres.

AI Act wymaga, by systemy wysokiego ryzyka technicznie umożliwiały automatyczne rejestrowanie zdarzeń (art. 12). Po zmianie z lipca 2026 r. dotyczy to systemów z załącznika III od 2.12.2027 r. To opis mechanizmu, nie ocena, czy Wasz system jest wysokiego ryzyka.

Kto kontroluje agenta: człowiek, drugi agent, SOC

Człowiek zatwierdza sprawy, które firma zastrzegła dla siebie. Widzi szczegóły jednej sprawy, ale nie zauważy wzorca w setkach spraw.

Agent sprawdzający czyta pracę innego agenta i szuka błędów, jak druga osoba przed wysłaniem pisma. Sam nie decyduje, tylko zgłasza uwagi. Nie zobaczy faktów, których nie dostał.

Zespół bezpieczeństwa (SOC, security operations center) patrzy na wszystkich agentów naraz. Wychwytuje nietypowe zachowanie, np. nagły skok liczby wywołań narzędzi. Może zablokować konto agenta, ale nie oceni, czy odpowiedź do klienta była słuszna.

SOC potrzebuje dwóch rzeczy: dziennika agenta w swoim SIEM i osobnej tożsamości agenta. Bez niej alert wskaże pracownika zamiast agenta.

Z naszej praktyki: tożsamość, wąskie narzędzia, dziennik w aiv

W aiv do panelu wchodzi się firmowym kontem przez Entra ID firmy. Działa u klienta Agent łączy się z modelem przez tożsamość zarządzaną w chmurze firmy, bez kluczy. Działa u klienta Agent sięga do CRM przez siedem nazwanych narzędzi, tylko do odczytu. Działa u klienta

Agent zostawia szkic, a o tym, co wychodzi do klienta, decyduje pracownik. Działa u klienta Dziennik silnika zapisuje sesje, narzędzia i model, a dziennik panelu: kto, kiedy i jaki plik. Działa u klienta

Wdrażamy też zapis decyzji z tożsamością z logowania i odmowę żądań bez niej.

Każde zdanie o aiv ma stan z rejestru. Pełny rejestr z datą: /stan.

Co ustawiamy przy wdrożeniu

Ustawiamy kilku agentów, każdego z osobnym zakresem uprawnień. Włączamy też zlecanie pracy podagentom z kontrolą, czy podagent nie oddał pustej odpowiedzi.

W panelu ustawiamy role ludzi, np. osobną dla audytora. Dziennik przekazujemy do Waszego SIEM, np. Microsoft Sentinel.

Przykład

Przykład ilustracyjny: spór z dostawcą o termin płatności

Dostawca twierdzi, że firma zgodziła się w mailu na 60 dni terminu płatności. Dział prawny prosi o historię sprawy. Firma ma pełny dziennik decyzji, więc sprawdza go krok po kroku.

Dziennik pokazuje, że agent napisał szkic o 9:12 na podstawie dwóch wpisów z systemu zakupowego. W szkicu był termin 30 dni. Pracownik w roli „zakupy” zmienił go na 60 dni i zatwierdził szkic o 9:20.

Tożsamość pracownika pochodzi z logowania, a zmiana treści ma własny wpis. Spór dotyczy więc decyzji człowieka, nie błędu agenta.

Przykład ilustracyjny, nie opis wdrożenia.

Najczęstsze pytania

RBAC co to znaczy?

RBAC (role-based access control) to kontrola dostępu oparta na rolach. Uprawnienia przypisuje się roli, np. „obsługa korespondencji”, a rolę osobie albo agentowi. Zmiana uprawnień roli zmienia dostęp wszystkich, którzy ją mają.

Czy agent może zrobić coś, do czego nie ma uprawnień?

Nie powinien, jeśli uprawnienia sprawdza program wokół modelu. Model tylko proponuje krok, a warstwa kontroli sprawdza rolę agenta.

Ryzyko rośnie, gdy agent ma konto z szerokimi prawami. Tak samo, gdy dostaje ogólne narzędzie, np. konsolę. Wtedy granica stoi tylko w instrukcji, którą ukryte polecenie w mailu potrafi obejść.

Co musi trafiać do dziennika agenta?

Kto działał (agent czy człowiek), kiedy, jakim narzędziem i z jakim wynikiem. Do tego model, który odpowiadał, oraz zatwierdzenie człowieka z jego tożsamością.

Zapisujcie też próby odrzucone. Hasła i klucze program powinien ukryć przed zapisem, żeby dziennik sam nie stał się wyciekiem.

Czy wpisy w dzienniku da się zmienić?

Zależy od tego, gdzie leży dziennik. Łańcuch skrótów łączy wpisy jak numerowane strony księgi. Każdy wpis niesie odcisk poprzedniego, więc zmianę da się wykryć.

Łańcuch zmiany nie blokuje. Blokadę daje magazyn, który przyjmuje tylko nowe wpisy (WORM). Zapytajcie IT, które z tych zabezpieczeń macie.

Jak długo przechowywać dziennik agenta?

Tyle, ile wymagają Wasze przepisy, umowy i polityka bezpieczeństwa. AI Act każe podmiotowi stosującemu system wysokiego ryzyka trzymać rejestry zdarzeń co najmniej sześć miesięcy. Dotyczy to rejestrów pod jego kontrolą, chyba że inne prawo mówi inaczej (art. 26 ust. 6).

Dla systemów z załącznika III obowiązek stosuje się od 2.12.2027 r. Dziennik z danymi osobowymi podlega też RODO.

Częste nieporozumienia

  • „Agent działa na moim koncie, więc ma tylko moje prawa.” Właśnie dlatego ma ich za dużo. Wasze konto otwiera więcej drzwi, niż wymaga jego zadanie.
  • „Mamy dziennik, więc mamy audyt.” Dziennik, którego nikt nie czyta, niczego nie wykrywa. Wskażcie, kto go przegląda i jak często.
  • „Drugi agent zastąpi kontrolę człowieka.” Agent sprawdzający szuka błędów, ale odpowiedzialności nie przejmuje. Ostatnie słowo należy do człowieka.

Powiązane hasła

Źródła

  1. Role Based Access Control (projekt NIST CSRC; model Ferraiolo i Kuhn 1992, norma ANSI/INCITS 359-2004, zmieniona jako INCITS 359-2012; projekt archiwalny) — NIST CSRC, publikacja 2016-11-21 (aktualizacja 2026-03-04), dostęp 2026-09-26
  2. SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (AC-6 Least Privilege, rodzina AU Audit and Accountability) — NIST, publikacja 2020-09-23 (aktualizacja 2020-12-10), dostęp 2026-09-26
  3. OWASP GenAI LLM Top 10 2026 (LLM03:2026 Excessive Agency) — OWASP Gen AI Security Project, publikacja 2026-08-04 (data z metadanych strony), dostęp 2026-09-26
  4. LLM06:2025 Excessive Agency (OWASP Top 10 for LLM Applications 2025; definicja trzech źródeł nadmiernej sprawczości) — OWASP Gen AI Security Project, publikacja 2024-11-17, dostęp 2026-09-26
  5. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization (concept paper, Initial Public Draft) — NIST NCCoE, publikacja 2026-02-05, dostęp 2026-09-26
  6. Microsoft Entra Agent ID logs — Microsoft Learn, publikacja 2026-04-28, dostęp 2026-09-26
  7. What are Microsoft Entra audit logs? — Microsoft Learn, publikacja 2026-06-05, dostęp 2026-09-26
  8. Microsoft Entra data retention — Microsoft Learn, publikacja 2026-01-06, dostęp 2026-09-26
  9. Microsoft Entra licensing (Microsoft Entra Agent ID, Conditional Access for agents) — Microsoft Learn, publikacja 2026-06-18, dostęp 2026-09-26
  10. Plan costs and understand Microsoft Sentinel pricing and billing — Microsoft Learn, publikacja 2026-04-01, dostęp 2026-09-26
  11. Microsoft Security Copilot Phishing Triage Agent in Microsoft Defender — Microsoft Learn, publikacja 2026-07-02, dostęp 2026-09-26
  12. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (AI Act), art. 12 „Rejestrowanie zdarzeń” i art. 26 ust. 6 — EUR-Lex, Dz.Urz. UE L z 12.07.2024, publikacja 2024-07-12, dostęp 2026-09-26
  13. Rozporządzenie (UE) 2026/1744 (Digital Omnibus on AI) zmieniające rozporządzenie (UE) 2024/1689; terminy stosowania dla systemów wysokiego ryzyka — EUR-Lex, Dz.Urz. UE, publikacja 2026-07-24, dostęp 2026-09-26

Hasło pisze i przegląda Damian Świderek. Każdy fakt ma źródło z datą dostępu. Twierdzenia o aiv mają stan z rejestru /stan. Widzisz błąd? Napisz na hello@aiversum.ai.

Zobacz, jak ustawiamy tożsamość, uprawnienia i dziennik agentów w firmie.

Bezpieczeństwo agentów