ABAC: dostęp agentów AI

Kontrola dostępu oparta na atrybutach podmiotu, zasobu i kontekstu. Ogranicza zapis w zależności od działu, klasyfikacji danych i godziny. Ten tekst ocenia konkretną rolę komponentu w systemie AI-native. „Najlepszy” oznacza tu dobry wybór przy określonych wymaganiach, nie zwycięzcę w każdej firmie.

Szeroką architekturę opisuje filar bezpieczeństwa AI. Źródłem opisu projektu jest dokumentacja lub repozytorium twórców. Stan funkcji i licencji należy potwierdzić dla wybranej wersji.

Czym jest i do czego służy?

Kontrola dostępu oparta na atrybutach podmiotu, zasobu i kontekstu. Ogranicza zapis w zależności od działu, klasyfikacji danych i godziny. W praktyce trzeba oddzielić rolę tej technologii od całej platformy: komponent rozwiązuje określony problem, a tożsamość, polityka danych i obserwowalność nadal wymagają własnego projektu.

Przykład polityki: akcja „pobierz umowę” jest dozwolona tylko, gdy dział użytkownika odpowiada właścicielowi sprawy, dokument ma odpowiednią klasyfikację, a żądanie pochodzi z zatwierdzonego środowiska. Atrybuty muszą pochodzić z zaufanego źródła; tekst promptu nie może sam ustalać klasyfikacji. Testuj przypadki brakującego atrybutu i odmowę domyślną.

Dlaczego warto rozważyć ją w suwerennym AI OS?

Pozwala wyrazić warunki, których nie da się sensownie upakować w role. Suwerenność oceniamy przez możliwość uruchomienia, kontrolę danych i uprawnień, przenośność formatu oraz plan zmiany dostawcy. Jeśli rozwiązanie jest usługą zarządzaną, należy jawnie wskazać granicę kontroli; otwarty klient czy API nie czynią całej usługi open source.

Jak wykorzystać ją przy kodowaniu z AI?

W AI SDLC agent kodujący może przygotować konfigurację, adapter i test integracyjny, lecz człowiek powinien sprawdzić uprawnienia, koszty oraz skutki błędu. Punktem odbioru jest działający scenariusz: ogranicza zapis w zależności od działu, klasyfikacji danych i godziny. Agent nie powinien sam zatwierdzać swojej zmiany ani otrzymywać szerszych uprawnień niż wymaga zadanie. Przed wdrożeniem warto zachować ślad: wymaganie, wersję zależności, wynik testu i osobę akceptującą.

Alternatywy i ograniczenia

Możliwe alternatywy: RBAC, ReBAC i polityki aplikacyjne. Niespójne atrybuty i brak audytu decyzji czynią politykę nieprzewidywalną. Wybór powinien wynikać z pomiaru na własnych danych, zgodności z obecnym zespołem i możliwości wycofania rozwiązania. Sama liczba gwiazdek repozytorium lub obietnica marketingowa nie zastępuje próby.

Zobacz też porównanie RBAC, ABAC i ReBAC, jeśli projekt wymaga połączenia tych modeli.

Co sprawdzić przed decyzją?

Zbuduj małą próbę realizującą ten przypadek: ogranicza zapis w zależności od działu, klasyfikacji danych i godziny. Zmierz opóźnienie, koszt, jakość wyniku i zachowanie po błędzie. Sprawdź też, czy inny członek zespołu potrafi odtworzyć wynik na podstawie zapisanej konfiguracji. Powiązane składniki architektury to RBAC oraz SpiceDB. Zapisz kryterium, po którym rozwiązanie będzie można wymienić.