--- title: "Cedar Policy: dostęp agentów AI" url: "https://majchrzycki.com/blog/cedar-policy-agent-ai-os" description: "Otwarty język i silnik polityk autoryzacyjnych. Zastosowanie, alternatywy, ograniczenia i próba dla AI OS oraz AI SDLC." --- # Cedar Policy: dostęp agentów AI 3 maja 2026· Aktualizacja: 28 września 2026·2 min czytania·Krzysztof Majchrzycki Temat: [Bezpieczeństwo i utrzymanie AI](https://majchrzycki.com/blog/filar/bezpieczenstwo-i-utrzymanie-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](https://majchrzycki.com/blog/filar/bezpieczenstwo-i-utrzymanie-ai). Źródłem opisu projektu jest [dokumentacja lub repozytorium twórców](https://github.com/cedar-policy/cedar). 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](https://majchrzycki.com/blog/rbac-agent-ai-os) oraz [SpiceDB](https://majchrzycki.com/blog/spicedb-agent-rebac). Zapisz kryterium, po którym rozwiązanie będzie można wymienić. - Agenci AI ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Cerbos: dostęp agentów AI](https://majchrzycki.com/blog/cerbos-agent-autoryzacja) - [RBAC: dostęp agentów AI](https://majchrzycki.com/blog/rbac-agent-ai-os) - [SpiceDB: dostęp agentów AI](https://majchrzycki.com/blog/spicedb-agent-rebac) - [ABAC: dostęp agentów AI](https://majchrzycki.com/blog/abac-agent-ai-os)