Agent Intent-Based Access Control (IBAC) to architektura bezpieczeństwa, która uzależnia uprawnienia od celu operacyjnego użytkownika, a nie tylko od tożsamości technicznej. Rozwiązanie to ogranicza ryzyko eskalacji przywilejów przez autonomiczne systemy AI, wprowadzając deterministyczną weryfikację intencji przed każdym wywołaniem zewnętrznego narzędzia, co czyni manipulacje modelem bezużytecznymi.
Niewydolność statycznych modeli RBAC w środowiskach agentowych
Tradycyjne systemy kontroli dostępu oparte na rolach (RBAC) nie radzą sobie z niedeterministyczną naturą agentów AI, które dynamicznie komponują przepływy pracy i wywołują API w czasie rzeczywistym. Statyczne uprawnienia prowadzą do nadmiarowości przywilejów (over-privileging), ponieważ agenci otrzymują uprawnienia „na zapas”, co tworzy krytyczną powierzchnię ataku dla technik wstrzykiwania instrukcji (prompt injection).
W badaniach WASP benchmark 2025 wykazano, że proste, napisane przez człowieka wstrzyknięcia instrukcji odnoszą sukces w 86% przypadków, mimo że modele stają się coraz bardziej zaawansowane. Głównym problemem architektury jest fakt, że permissions agenta są oddzielone od faktycznego zapytania użytkownika; agent posiadający dostęp do poczty, kalendarza i plików może zostać zmanipulowany do exfiltracji danych, jeśli tylko otrzyma instrukcję zawartą w złośliwym dokumencie. Próby rozwiązywania tego problemu poprzez zwiększanie granulacji ról prowadzą do „eksplozji ról” (role explosion), co staje się niewykonalne operacyjnie przy skalowaniu systemów AI.
| Cecha | Tradycyjny Access Control | Agentic AI Access Control |
|---|---|---|
| Inicjator decyzji | Użytkownik (jawny) | Model AI (autonomiczny) |
| Punkt wymuszania | Login / API Gateway | Interfejs narzędzi agenta |
| Widoczność ryzyka | Statyczna (na podstawie grupy) | Dynamiczna (na podstawie intencji) |
| Mechanizm główny | Poświadczenia (API Keys) | Możliwości (Scoped Tokens) |
Architektura IBAC jako deterministyczna zapora dla intencji
Intent-Based Access Control (IBAC) przenosi proces decyzyjny poza logikę modelu LLM, wyodrębniając uprawnienia per-request z jawnej intencji użytkownika i wymuszając je deterministycznie przy każdej próbie użycia narzędzia. System analizuje zapytanie użytkownika przed rozpoczęciem egzekucji, generuje plan i zestaw krotek autoryzacyjnych (np. w standardzie OpenFGA), które stanowią twardą granicę dla agenta.
Proces automatyzacji IBAC obejmuje następujące etapy techniczne: 1. Parser intencji: Wyodrębnia minimalny zestaw wymaganych możliwości (capabilities) z zapytania użytkownika. 2. Generator krotek: Mapuje intencje na konkretne akcje i zasoby (np. `email:send#[email protected]`). 3. Bramka narzędziowa (Tool Gateway): Blokuje każde wywołanie narzędzia, które nie posiada pasującej krotki autoryzacyjnej, niezależnie od tego, jak bardzo „przekonany” o słuszności działania jest agent po ataku prompt injection.
W testach na benchmarku AgentDojo, framework IBAC osiągnął 100% skuteczności w trybie restrykcyjnym (strict mode), blokując wszystkie 240 prób ataku typu injection. Nawet jeśli rozumowanie agenta zostanie całkowicie przejęte przez napastnika, warstwa autoryzacji odrzuca operacje niewpisane w pierwotną krotkę intencji.
Monitorowanie dryftu intencji i kwarantanna w Varonis Atlas
System Varonis Atlas wprowadza Agent IBAC jako rozwiązanie operacyjne, które monitoruje każdy krok agenta w ramach sesji i porównuje go z pierwotną instrukcją uruchamiającą proces. Platforma ta działa inline między agentem a modelem, co pozwala na blokowanie niebezpiecznych akcji przed ich wykonaniem, a nie tylko na analizę logów post-factum.
Kluczowe parametry techniczne Varonis Atlas obejmują: Detekcja dryftu intencji: LLM-evaluator porównuje rozumowanie agenta i wybrane parametry narzędzi z zapytaniem użytkownika, oferując trzy poziomy czułości (Lenient, Balanced, Strict). Ewaluacja pełnej sesji: Analiza całego kontekstu rozmowy w celu wykrycia „pełzającego” dryftu lub wieloetapowych ataków jailbreak, które pojedynczo mogą wydawać się niegroźne. * Automatyczna kwarantanna: W przypadku naruszenia polityki, Atlas może natychmiast zablokować tożsamość stojącą za sesją na określony czas, co uniemożliwia kontynuację ataku.
Ryzyko projektowe w tym modelu wiąże się z precyzją parsera intencji; błędy mogą prowadzić do blokowania legalnych działań (under-scoping) lub nadawania zbyt szerokich uprawnień (over-scoping). Varonis minimalizuje to poprzez Human-in-the-Loop – akcje o wysokim ryzyku mogą być kierowane do zatwierdzenia przez człowieka.
Od poświadczeń do możliwości – paradygmat Capability-Based Access
W środowiskach autonomicznych następuje przesunięcie od kontroli opartej na tożsamości (Credentials) w stronę kontroli opartej na możliwościach (Capabilities). Poświadczenia, takie jak statyczne klucze API, są binarnymi przełącznikami pozbawionymi kontekstu semantycznego, co w przypadku agentów AI tworzy ogromny blast radius po ich przejęciu.
Model oparty na możliwościach (Capability-Based Access Control) traktuje dostęp jako niepodrabialny token do wykonania konkretnego zadania (np. „odczytaj wiersz 45 w tabeli Users”). Po zakończeniu zadania token staje się nieważny. Implementacja tego modelu w systemach AI drastycznie ogranicza lateral movement; jeśli agent zostanie przejęty na drugim etapie łańcucha działań, nie posiada on „możliwości” do wykonania etapu trzeciego bez ponownej autoryzacji.
Standardy takie jak SPIFFE/SPIRE mogą być wykorzystane do wydawania krótkotrwałych, rotowanych dokumentów tożsamości (SVID), co eliminuje potrzebę przechowywania statycznych sekretów w plikach konfiguracyjnych agentów.
Wnioski praktyczne i rekomendacje
- Wdróż deterministyczny parser intencji: Nie polegaj na odporności modelu LLM na manipulacje. Autoryzacja musi być zewnętrzna i niezmienna dla agenta w trakcie sesji.
- Zastosuj zasadę „Least Agency”: Skonfiguruj mikrosegmentację opartą na tożsamości, aby agenci mogli komunikować się wyłącznie z autoryzowanymi systemami i tylko w ramach przydzielonych zadań.
- Ustaw agresywne limity TTL (Time-To-Live): Możliwości (capabilities) przyznawane agentowi powinny wygasać natychmiast po przewidywanym czasie wykonania zadania, co ogranicza okno czasowe dla nadużyć.
- Zintegruj protokół SCIM do zarządzania cyklem życia: Traktuj agentów jako tożsamości nie-ludzkie (NHI) i automatyzuj ich usuwanie (de-provisioning) poprzez operację SCIM DELETE, co trwale neutralizuje zagrożenie w przypadku kompromitacji.
- Monitoruj dryft sesyjny: Wykorzystaj narzędzia klasy AI Runtime Security (np. Varonis Atlas, NeuralTrust), aby analizować łańcuch rozumowania (Chain of Thought) i blokować operacje wykraczające poza początkowy kontekst sesji.
Źródła
- 11 Best Agentic AI Security Solutions for Enterprise in 2026 | NeuralTrust
- Black Hat USA 2026 – Summary of Vendor Announcements (Part 1) – SecurityWeek
- From Identity to Intent: The Rise of Intent-Aware Access Fabrics for the AI Era
- Identity Management for Agentic AI | OpenID
- Intent-Based Access Control: Using LLMs to Intelligently Manage Access Control – arXiv
- Intent-based access control for AI agents – IndyKite
- Intent‑Based Access Control: A Technical Primer – Reva.AI
- Introducing Agent Intent-Based Access Control – Varonis
Dodaj komentarz