Zarządzanie w Olivares AI opiera się na dwóch zasadach, które można utrzymać w głowie jednocześnie: obserwuj zanim wyegzekwujesz i gdy egzekwujesz, domyślnie odrzucaj. Produkt mapuje i audytuje to, co każdy agent może osiągnąć, na długo zanim zablokuje choćby jedną akcję, a bramy, które uruchamia, są domyślnie odrzucające.
Odczyt jako priorytet: obserwacja przed egzekucją
Domyślna postawa platformy jest detektywistyczna, nie prewencyjna. Buduje mapę dostępu odczyt/zapis poprzez pochłaniane logów, OpenTelemetry i natywnego audytu poza pasmem — nigdy nie jest na ścieżce danych agenta, więc kolektor, który ulegnie awarii, nie może położyć produkcji. Z tej mapy porównuje dozwolone z obserwowanymi i ujawnia dryf do oceny przez człowieka.
To ma znaczenie dla tego, jak czytasz resztę tej strony. Produkt obserwuje i zarządza szeroko; nie aktywuje szeroko. Tam, gdzie może podjąć akcję na twojej infrastrukturze, ta możliwość jest jedną z trzech rzeczy, a katalog modułów oznacza którą:
- live — podłączone i działające dzisiaj (wąski zbiór);
- on-demand — backend jest zbudowany i podłączony do punktu wstrzykiwania, ale pozostaje domyślnie odrzucający lub zdegradowany aż go udostępnisz (executor, dispatcher, poświadczenie inferencji);
- seam — zadeklarowany, domyślnie odrzucający interfejs bez backendu w domyślnym pliku binarnym.
Więc brak egzekucji jest zwykle celowy, nie przeoczeniem. Odczyt jako priorytet oznacza, że uczciwe domyślne ustawienie to obserwacja i zapis, a bramkowanie tylko tych powierzchni, które wyraźnie włączyłeś.
Model autoryzacji, w ramach którego zarządzasz
Każda zarządzana decyzja przechodzi przez ten sam rdzeń autoryzacji, który chroni resztę API. Trzy właściwości warto zinternalizować zanim cokolwiek zmienisz.
RBAC jest domyślnie odrzucający. Podmiot bez członkostwa w dzierżawcy jest
odrzucany — nie ma niejawnego nadania. Uprawnienia są ograniczone do dzierżawcy, a
handler działa tylko na pojedynczym dzierżawcy, do którego żądanie zostało rozwiązane,
co zamyka klasy confused-deputy i IDOR z konstrukcji. Role tworzą drabinkę: viewer
czyta, editor zapisuje, admin zarządza IAM dzierżawcy, owner posiada wszystko.
Odczytywanie grafu dostępu jest celowo uprawnieniem od poziomu editor wzwyż
— pełna mapa tego, co każdy agent może osiągnąć, to mapa rozpoznawcza — a każdy
taki odczyt jest zapisywany w rejestrze audytu.
Warstwa polityk tylko ogranicza. Na wierzchu RBAC możesz podłączyć atrybutowy punkt decyzyjny polityk. Kompozycja to przecięcie — RBAC ∩ natywny ABAC ∩ zewnętrzny PDP — więc polityka może tylko dalej ograniczać to, co RBAC już zezwolił; nigdy nie może poszerzyć nadania. To jest wymuszone, nie konwencja. Wybierasz co najwyżej jeden zewnętrzny silnik:
# Wbudowany Cedar (czysty Go, bez sidecar) lub OPA przez HTTP. Domyślnie: brak.
OLIVARES_PDP_ENGINE=cedar # lub: opa | noneZ Cedar tworzysz reguły forbid; pusty zbiór reguł pozostawia decyzję RBAC. Z OPA
twój Rego musi domyślnie zezwalać, gdzie brakujący wynik lub jakikolwiek błąd
transportu zamyka się odrzucając. Nieprawidłowa konfiguracja PDP wyłącza tylko
zewnętrzny PDP i loguje ten fakt — natywny ABAC i RBAC dalej zarządzają, a
źle skonfigurowany silnik nigdy nie pozostawia żądania bez zarządzania. Każde
ograniczenie nakładane przez PDP jest audytowane.
Poziomy ryzyka i próg podwójnej kontroli
Akcje, które trafiają do kolejki zatwierdzania, są klasyfikowane w cztery poziomy
ryzyka — low, medium, high, critical — zgodnie z taksonomią AI-agent OWASP.
(To odrębna oś od poziomów zgodności EU AI Act; nie należy ich mylić.) Poziom jest
ponownie wyprowadzany z aktywnej polityki przy każdej decyzji bezpieczeństwa, nigdy
czytany z zapisanego snapshotu, więc zmiana polityki zaczyna obowiązywać natychmiast,
a przestarzały wiersz nigdy nie może utrzymać poprzeczki niżej niż bieżąca klasyfikacja.
Akcja critical niesie obowiązkowy próg dwuosobowy: co najmniej dwóch różnych
ludzkich zatwierdzających, zgodnie z NIST SP 800-53 AC-3(2) podwójna autoryzacja.
Próg jest wymuszany dwukrotnie — przy tworzeniu (zapisany próg nigdy nie może
zaczynać poniżej niego) i ponownie wyprowadzany przy decyzji (zdegradowany lub
przestarzały wiersz nadal nie może przejść z jednym zatwierdzającym) — więc nawet
polityka operatora, która wyraźnie obniża poziom, nie może uczynić krytycznej akcji
jednostronną. Wbudowany zbiór krytyczny to nieodwracalna, kształtująca infrastrukturę
rodzina: wdrożenie i wycofanie produkcyjne, usuwanie danych, zmiany w egzekucji
bezpieczeństwa, opieka nad kluczami i rotacja, oraz ponowne włączanie infrastruktury
po wyłączeniu awaryjnym.
Niższe poziomy nie zmieniają mechaniki silnika — zatwierdzenie, które już istnieje, wymaga co najmniej jednego człowieka — są słownikiem, na którym opierają się inne kontrole (na przykład podwyższanie uwierzytelniania przy krytycznej akcji).
Brama zatwierdzania człowiek-w-pętli
Tam, gdzie produkt bramkuje akcję, pętla wygląda tak: powierzchnia prezentuje (dryf z mapy dostępu, odkrycie z modułu bezpieczeństwa) → uprawniony operator decyduje → decyzja jest zapisywana w rejestrze audytu. Silnik zatwierdzania, który to wspiera, jest prawdziwy dzisiaj: żądanie otwiera się domyślnie odrzucająco, powiązane z hashem planu i ograniczone czasowo. Niezmienniki są wymuszane po stronie serwera, kluczowane na stabilnej tożsamości użytkownika (token systemowy nie ma tożsamości i nie może decydować):
- Rozdzielenie obowiązków — wnioskujący nigdy nie może decydować o własnym żądaniu.
- Ochrona przed duplikatem decydenta — jeden człowiek liczy się raz wobec progu.
- Wygaśnięcie — wyprowadzane przy odczycie, więc wygasłe żądanie nigdy nie może zostać związane, nawet zanim przegląd zmaterializuje jego wygaśnięcie.
To, co jeszcze dojrzewa, to bogatsza konsola przeglądowa operatora; punkty końcowe i silnik są dostarczane dzisiaj. Przewodnik Zarządzaj i zatwierdzaj przeprowadza przez aktywny przepływ.
Zależność, która sprawia, że cokolwiek z tego jest wiarygodne, to tożsamość per-agent. Audyt przypisuje aktywność do poświadczenia, nie z natury do agenta; współdzielone konto serwisowe składa atrybucję do poziomu tożsamości — ujawniane uczciwie jako odkrycie, nigdy cicho odzyskiwane. Zobacz dozwolone vs obserwowane i wierność dla tego, co to robi z sygnałem, na którym zarządzasz.
Break-glass: audytowany zawór bezpieczeństwa
Podwójna kontrola potrzebuje zaworu bezpieczeństwa na wypadek incydentu o 03:00, gdy jeden zatwierdzający jest nieosiągalny. Break-glass to ten zawór i jest głośny z konstrukcji. Aktywacja wymaga poziomu admin i prawdziwego człowieka (token systemowy jest odrzucany), weryfikowanego sprzętowo (AAL3) podwyższenia, pisemnego uzasadnienia i aktywnie nagrywanej sesji jako warunku wstępnego. Nadanie jest ograniczone czasowo — domyślnie godzina, twarde ograniczenie jeden dzień — a wygasłe nadanie nie może niczego autoryzować.
Gdy nadanie jest aktywne, akcja w zakresie może przebiegać bez kworum zatwierdzania, ale każde użycie jest dołączane do niezmiennego śladu i rejestru audytu, nazywając nadanie, akcję i podmiot — akcja, która przebiegła w ramach break-glass, jest trwale odróżnialna od zatwierdzonej. Wymuszona kontrola po fakcie zamyka pętlę: nowe nadanie nie może być aktywowane, gdy poprzednie jest niesprawdzone, a przegląd musi pochodzić od innego człowieka niż aktywujący.
Wyłącznik awaryjny: brama odrzucania dla całej infrastruktury
Wyłącznik awaryjny to jednoklikowe zatrzymanie awaryjne i odwraca zwykłą ergonomię celowo. Włączenie jest celowo tanie — poziom admin, obowiązkowy powód, bez kworum zatwierdzania, bez podwyższenia, bez break-glass — ponieważ zatrzymanie, które czeka na konsensus, nie jest zatrzymaniem. Poziom pewności sesji włączającej jest rejestrowany do celów kryminalistycznych; nadużycie włączania kosztuje tylko dostępność, co jest bezpiecznym kierunkiem.
Wiersz zatrzymania jest jedynym źródłem prawdy. Każda zarządzana brama aktywacji sprawdza go na żywo przy każdej akcji i zamyka się odrzucając przy błędzie odczytu — dokładne odwrotność kontraktu fail-open bram budżetowych, ponieważ nieczytelny stan zatrzymania nigdy nie może oznaczać “działaj”. Włączenie również unieważnia kolejkowaną pracę, której bramy nie mogą osiągnąć: każde oczekujące zatwierdzenie aktywacji w zakresie jest anulowane w tej samej transakcji, więc pre-stop intencja nie może dojrzeć do nadania, które zostanie wysłane w momencie powrotu infrastruktury. Akcje zarządzania są wyjęte — zatrzymanie wstrzymuje infrastrukturę agentową, nigdy kontrole, które nią zarządzają.
Ponowne włączenie nigdy nie jest jednostronne. Jest bramkowane świeżym
zatwierdzeniem podwójnej kontroli (próg critical dwóch różnych ludzi, strukturalnie
ponownie weryfikowany przy przełączeniu, więc zdegradowana polityka nie może go uczynić
jednostronnym), i celowo nie ma ścieżki break-glass dla ponownego włączenia:
“infrastruktura pozostaje zatrzymana” jest bezpiecznym stanem. Wymuszona kontrola
po fakcie przez niezaangażowanego człowieka zamyka incydent.
Gwarancja zapisanych decyzji
Niezależnie od głębokości powyższego workflow, decyzja zarządcza to zapisany fakt. Mutujące akcje są dołączane do rejestru audytu z prawdziwym aktorem w tej samej transakcji co zmiana, a wrażliwe odczyty (graf dostępu, sam rejestr) samoaudytują się w zatwierdzonym zapisie. Rejestr jest tylko do dopisywania i z łańcuchem haszy, każdy rekord niesie pola integralności łańcucha, więc przepisywanie historii jest wykrywalne i nigdy nie zawiera PII. Nie możesz dokonać niezarządzanej zmiany, która rejestr cicho zapomni.
Powiązane
- Dozwolone vs obserwowane — dryf, na którym działają te decyzje.
- Wierność — jak pewny jest sygnał pod decyzją.
- Zarządzaj i zatwierdzaj — aktywny przepływ zatwierdzania, krok po kroku.
- Wyłącznik awaryjny — brama odrzucania całej infrastruktury w terminach produktowych.
- Uczciwości i ograniczenia — postawa domyślnego odrzucania i detektywistyczna w pełni.