Cedar Policy: dostęp agentów AI

Otwarty język i silnik polityk autoryzacyjnych. Zapisuje warunki dostępu agenta do akcji i zasobów. 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?

Otwarty język i silnik polityk autoryzacyjnych. Zapisuje warunki dostępu agenta do akcji i zasobów. 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.

Polityka powinna obejmować podmiot, akcję, zasób i kontekst. Wersjonuj ją jak kod i uruchamiaj testy przypadków „allow” oraz „deny” przed wdrożeniem. Model językowy może poprosić o operację, ale nie może sam zmodyfikować reguły Cedar ani przypisać sobie roli.

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

Jawne, testowalne reguły odseparowują uprawnienia od promptu modelu. 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: zapisuje warunki dostępu agenta do akcji i zasobów. 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: OPA Rego, Cerbos, polityka w kodzie. Poprawna składnia polityki nie gwarantuje poprawnej mapy tożsamości i danych. 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.

Co sprawdzić przed decyzją?

Zbuduj małą próbę realizującą ten przypadek: zapisuje warunki dostępu agenta do akcji i zasobów. 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ć.