RBAC, ABAC i ReBAC: uprawnienia agentów AI

RBAC, ABAC i ReBAC to trzy sposoby odpowiedzi na pytanie, czy konkretny podmiot może wykonać konkretną akcję na konkretnym zasobie. W systemie agentowym podmiotem może być użytkownik, usługa albo agent działający w imieniu użytkownika. Model językowy może zaproponować operację, ale decyzja o jej dopuszczeniu musi zapaść poza promptem. To fundament bezpieczeństwa i utrzymania AI.

Co oznaczają te skróty?

Model	Na czym opiera decyzję	Przykładowa reguła
RBAC (Role-Based Access Control)	Rola przypisana podmiotowi	Analityk może czytać raport, a operator może zatwierdzić zmianę.
ABAC (Attribute-Based Access Control)	Atrybuty podmiotu, zasobu, akcji i kontekstu	Raport można czytać, jeśli należy do działu użytkownika i nie ma klauzuli poufności.
ReBAC (Relationship-Based Access Control)	Relacje w grafie podmiotów i zasobów	Użytkownik ma dostęp do dokumentu, bo należy do zespołu przypisanego do projektu właściciela.

RBAC jest czytelny i łatwy do audytu przy niewielkiej liczbie ról. Rozbudowana organizacja szybko tworzy jednak „eksplozję ról”: osobna rola dla każdego klienta, projektu i wyjątku staje się trudna do utrzymania. ABAC wyraża warunki zależne od klasyfikacji danych, działu, lokalizacji lub czasu. Wymaga wiarygodnych atrybutów i odmowy, gdy któregoś brakuje. ReBAC pasuje do organizacji, w której dostęp wynika z członkostwa, własności, delegacji i hierarchii zasobów. Wymaga aktualnego grafu relacji oraz jasnych zasad cofania dostępu.

Szczegółowe przykłady opisują osobne wpisy o RBAC, ABAC i ReBAC. Definicje można porównać ze źródłami: NIST RBAC, NIST SP 800-162 o ABAC oraz model relacji SpiceDB.

Dlaczego agent wymaga dodatkowej ostrożności?

Tradycyjny użytkownik klika widoczny przycisk. Agent może sam wybrać narzędzie, ułożyć argumenty i wykonać serię kroków. Dlatego sprawdzenie uprawnienia tylko przy otwarciu panelu jest niewystarczające. Każde narzędzie mające efekt uboczny powinno egzekwować politykę w momencie wywołania. Zakres dostępu agenta nie może być większy od zakresu zleceniodawcy, a sama treść dokumentu lub promptu nie może nadać agentowi nowej roli.

Przykład: pracownik prosi agenta o streszczenie umów klienta A. RBAC pozwala roli „opiekun klienta” czytać umowy. ABAC ogranicza odczyt do dokumentów o dopuszczalnej klasyfikacji. ReBAC sprawdza, czy pracownik rzeczywiście należy do zespołu obsługującego klienta A. Jeśli agent później proponuje wysłanie umowy, musi nastąpić osobna decyzja dla akcji „eksportuj”, niezależna od prawa odczytu.

Jak połączyć modele w AI OS?

Nie trzeba wybrać dokładnie jednego. Role mogą wyznaczać ogólny zakres, atrybuty dodawać warunki, a relacje określać dostęp do konkretnego obiektu. Ważna jest jedna ścieżka decyzyjna: podmiot, akcja, zasób, kontekst, wersja polityki i wynik „allow/deny”. W systemie z ontologią operacyjną definicja akcji powinna wskazywać także wymagane uprawnienie i skutki wykonania. Do egzekwowania można ocenić Cerbos, SpiceDB albo Cedar, zależnie od modelu polityki.

Jak to testować z agentem kodującym?

Poproś agenta o test tabelaryczny obejmujący: poprawny dostęp, obcy projekt, brak atrybutu, cofniętą delegację, próbę zapisu przy prawie odczytu i prompt injection żądający obejścia reguły. Test musi wywołać prawdziwą granicę narzędzia, a nie jedynie funkcję pomocniczą używaną przez UI. Po zmianie polityki sprawdź, czy aktywne sesje i cache nie utrzymują starej decyzji. Przegląd człowieka powinien ocenić zarówno regułę, jak i dane źródłowe, na których opiera się decyzja.

Jeśli organizacja nie potrafi wskazać właściciela tożsamości, zasobu i relacji, najpierw potrzebna jest mapa uprawnień. Bez niej ani rozbudowany silnik polityk, ani ostrożnie napisany prompt nie zapewnią bezpiecznej autonomii.