Role-Based Access Control (RBAC) to fundament bezpieczeństwa IT od dekad. Pracownik ma rolę — „analityk finansowy”, „manager sprzedaży”, „administrator IT” — i ta rola definiuje do czego ma dostęp. Nie osoba, nie jednostka — rola. System jest przewidywalny i audytowalny.
Gdy agent AI wchodzi do organizacji — RBAC staje przed nowym pytaniem: jaką „rolę” ma agent? Czy agent obsługi klienta powinien mieć takie same uprawnienia jak pracownik obsługi klienta? Czy powinien mieć węższe? Szersze? I co gdy ten sam agent działa dla różnych użytkowników z różnymi rolami?
Czym jest RBAC dla agentów
RBAC dla agentów (Role-Based Access Control) to rozszerzenie tradycyjnego modelu kontroli dostępu o agentów AI jako osobny typ principal — definiujące jakie zasoby, systemy i akcje są dostępne dla agenta, niezależnie od uprawnień użytkownika w imieniu którego działa, z możliwością kumulowania lub ograniczania uprawnień względem użytkownika.
Trzy modele RBAC dla agentów
Agent dziedziczy uprawnienia użytkownika: agent może robić dokładnie to co użytkownik. Prosta implementacja, ale ryzykowna — skompromitowany agent ma pełen dostęp użytkownika.
Agent ma własną rolę (mniejszą niż użytkownik): agent obsługi klienta ma dostęp do CRM — ale tylko do odczytu i tylko dla rekordów klientów przypisanych do tego użytkownika. Nie może modyfikować konfiguracji CRM nawet jeśli użytkownik może. Principle of least privilege w praktyce.
Agent ma własną rolę (większą niż użytkownik): możliwe w scenariuszach gdzie agent agreguje wiedzę z wielu źródeł dla user experience — agent widzący raporty z różnych działów, prezentujący syntezę użytkownikowi który nie ma dostępu do wszystkich źródeł. Ryzykowne, wymaga starannego zaprojektowania.
Azure RBAC dla agentów
Azure Active Directory (Microsoft Entra ID) pozwala tworzyć Service Principals dla agentów — tak jak dla aplikacji. Każdy agent ma własną tożsamość AAD z przypisanymi rolami Azure. Agent jest audytowalny przez Azure Monitor jako osobna tożsamość — nie jako „użytkownik X wykonał akcję” ale „agent Y działający dla użytkownika X wykonał akcję”.
Managed Identities pozwalają agentom uruchamianym w Azure (Azure Functions, Container Apps) uzyskiwać tokeny dostępu bez przechowywania credentials — agent „jest” tożsamością przez infrastrukturę Azure, nie przez klucz API przechowywany w kodzie.
RBAC a permission injection
RBAC zaimplementowany na poziomie infrastruktury (nie w prompcie agenta) jest odporny na permission injection. Agent nie może poprosić przez prompt o uprawnienia których nie ma — bo uprawnienia są zarządzane przez Azure RBAC/IAM, nie przez model językowy. To jest implementacja zasady że granice uprawnień muszą być na poziomie infrastruktury, nie promptu.