Zarzadzaj i zatwierdzaj

Gdy zrodlo jest podlaczone i mapa dostepu pokazuje co kazdy agent moze odczytac i zapisac, nastepnym zadaniem jest zarzadzanie: zdecydowanie kto i co moze dzialac, i uczynienie kazdej decyzji zapisanym faktem. Ta strona obejmuje przeplyw zatwierdzania — poziomy ryzyka, podwojna kontrole, break-glass i rejestr, do ktorego wszystkie sie kotwicza.

Zarzadzanie jest domyslnie odrzucajace. Podmiot bez roli w dzierzawcy jest odrzucany; nie ma niejawnego nadania. Produkt obserwuje szeroko, ale nie aktywuje szeroko — tam, gdzie zarzadza akcja, robi to domyslnie odrzucajac, nigdy jako ogolny wykonawca.

Model autoryzacji

Kazde wywolanie zarzadcze przechodzi przez ten sam rdzen autoryzacji co reszta API: RBAC na poczatku, ograniczony do pojedynczego dzierzawcy, z opcjonalna warstwa zewnetrznej polityki na wierzchu.

Role tworza drabinke — viewer (odczyt), editor (zapis), admin (IAM dzierzawcy), owner (wszystko w dzierzawcy). Odczytywanie mapy dostepu celowo nie jest najnizszym poziomem: mapa tego, co kazdy agent moze dotknac, to mapa rozpoznawcza, wiec jest nadawana od poziomu editor wzwyz, ograniczona do dzierzawcy, a kazdy odczyt jest zapisywany w rejestrze.

Opcjonalny punkt decyzyjny polityki (Cedar wbudowany lub OPA przez HTTP) moze nalozyc reguly oparte na atrybutach na wierzch. Skladaja sie jako przeciecie — RBAC ∩ natywny ABAC ∩ zewnetrzny PDP — i maja jeden niezmiennik:

Warstwa polityk moze tylko zabrac dostep, nigdy go dodac. Polityka moze odrzucic cos, co RBAC by zezwolil; nigdy nie moze nadac czegos, co RBAC odrzuca. Zle skonfigurowany lub nieosiagalny PDP zamyka sie odrzucajac, a wylaczenie zewnetrznego PDP nigdy nie pozostawia zadan bez zarzadzania — natywne RBAC i ABAC dalej zarzadzaja.

Poziomy ryzyka

Zarzadzana akcja jest klasyfikowana w jeden z czterech poziomow — low, medium, high, critical — wyprowadzanych z taksonomii ryzyka AI-agent OWASP. Poziom steruje tym, ile ludzkiej kontroli akcja wymaga zanim moze przebiec.

Poziom nie jest przechowywany na wierszu zatwierdzania. Jest ponownie wyprowadzany z biezacego zbioru polityk plus wbudowanego domyslnego przy kazdej decyzji, wiec zmiana polityki zaczyna obowiazywac natychmiast, a przestarzaly snapshot nigdy nie moze utrzymac poprzeczki ponizej aktywnej klasyfikacji (domyslne odrzucanie).

Wbudowany zbior critical obejmuje prawdziwie nieodwracalne: wdrozenie i wycofanie produkcyjne, usuniecie i kasowanie danych, zmiany w egzekucji bezpieczenstwa i wylacznika awaryjnego, opieka nad kluczami i rotacja, oraz wylaczanie NHI. Polityka zatwierdzania z wyraznym risk_tier moze podnosic lub obnizac domyslny per akcja — to audytowane slowo operatora — ale nigdy nie moze obnizyc akcji critical ponizej progu podwojnej kontroli.

Zadania zatwierdzania i podwojna kontrola

Zadanie zatwierdzania otwiera sie domyslnie odrzucajaco i z ograniczeniem czasowym: zaczyna jako oczekujace, niesie wygasniecie i nie autoryzuje niczego, dopoki wystarczajaca liczba ludzi nie zdecyduje. Pasujaca polityka zatwierdzania jest autorytatywna dla progu i timeoutow, wiec wnioskujacy nigdy nie moze obnizyc wlasnej poprzeczki.

Trzy niezmienniki sa wymuszane po stronie serwera, nie przez konwencje:

• Rozdzielenie obowiazkow. Wnioskujacy nie moze decydowac o wlasnym zadaniu. To kluczuje na stabilnej tozsamosci uzytkownika, nie na lancuchu poswiadczen, ktory jedna osoba mogla zmieniac.
• Jedna decyzja na czlowieka. Unikalny indeks stanowi zabezpieczenie przed wyscigiem duplikatu decydenta; ta sama osoba nie moze liczyc sie dwukrotnie wobec progu.
• Wygasniecie wiaze. Wygasle zadanie nigdy nie moze otrzymac wiazocej decyzji — efektywny status jest ponownie wyprowadzany przy kazdej decyzji, z przegladem lub bez.

Dla akcji critical prog jest ustawiony na minimum dwoch roznych ludzkich zatwierdzajacych (NIST SP 800-53 AC-3(2) podwojna autoryzacja). Prog jest wymuszany zarowno przy tworzeniu zadania (zapisany prog nigdy nie moze zaczynac ponizej dwoch) jak i ponownie stosowany w punkcie decyzji (zadanie utworzone zanim akcja stala sie krytyczna nadal nie moze przejsc z jednym czlowiekiem). Jeden zatwierdzajacy nigdy nie moze spełnic krytycznej akcji.

Decyzja critical dodatkowo wymaga sesji weryfikowanej sprzetowo: decydujacy czlowiek musi miec swieze podwyzszenie WebAuthn lub PIV (AAL3). Token systemowy nie niesie ludzkiej pewnosci i jest odrzucany — token systemowy nie moze zatwierdzac.

Kazda decyzja dolacza niezmienny wiersz do sladu decyzji zadania i zdarzenie rejestru zapisujace decyzje, wynikowy status i poziom ryzyka, w ramach ktorego zostala podjeta.

Break-glass

Podwojna kontrola ma zawor bezpieczenstwa na wypadek incydentu o 03:00, gdy drugi zatwierdzajacy jest nieosiagalny. Admin — zawsze prawdziwy czlowiek, nigdy token systemowy — aktywuje ograniczone czasowo nadanie awaryjne, ktore pozwala bramkowanej akcji przebiec bez kworum. Sciezka nigdy nie jest cicha:

• Aktywacja wymaga uzasadnienia, samoaudytuje sie do rejestru w tej samej transakcji i emituje krytyczne odkrycie do szyny powiadomien.
• Kazde uzycie dolacza niezmienny wiersz i zdarzenie rejestru nazywajace nadanie, akcje i podmiot. Akcja, ktora przebiegla w ramach break-glass, jest trwale odroznialna od prawidlowo zatwierdzonej.
• Nadanie jest ograniczone czasowo — domyslnie godzina, z twardym limitem 24. “Sytuacja awaryjna”, ktora potrzebuje dluzej, to tryb operacyjny, nie sytuacja awaryjna, i musi przejsc przez normalna podwojna kontrole.
• Wymuszona kontrola po fakcie. Nowe nadanie nie moze byc aktywowane, gdy jakiekolwiek poprzednie nadanie jest niesprawdzone, a przeglad musi pochodzic od innego czlowieka niz aktywujacy. Nie mozesz spietre sytuacji awaryjnych, by uniknac kontroli.

Break-glass lagodzi brakujace kworum; nigdy nie nadpisuje jawnego ludzkiego odrzucenia. Zadanie, ktore ktos celowo odrzucil, pozostaje odrzucone.

Gwarancja zapisanych decyzji

Niezaleznie od glebokosci powyzszego workflow, decyzja zarzadcza to zapisany fakt. Mutujace akcje sa dolaczane do rejestru audytu z prawdziwym aktorem w tej samej transakcji co zmiana, a wrazliwe odczyty (mapa dostepu, sam rejestr) samoaudytuja sie w zatwierdzonym zapisie. Nie mozesz dokonac niezarzadzanej zmiany, ktora rejestr cicho zapomni.

Rejestr jest tylko-do-dopisywania, z lancuchem haszy i podpisany Ed25519. Kazdy rekord niesie seq, prev_hash, hash i sig, wiec przepisywanie historii jest kryptograficznie wykrywalne, a rejestr nigdy nie zawiera PII. Dla zewnetrznej, niezmiennej kopii, o ktora pyta audytor, rejestr jest udostepniany jako uwierzytelniony eksport pull na /v1/audit/export, z wartosciami format cef, leef, syslog, otlp i ocsf. Kazdy wyeksportowany rekord niesie pola integralnosci lancucha, wiec SIEM lub magazyn WORM moze ponownie zweryfikowac lancuch offline — odlaczony podpis chroni przed kompromitacja samej bazy danych, a kopia poza maszyną przed w pelni skompromitowanym hostem.

Uczciwy zakres

Rdzen autoryzacji, silnik zatwierdzania i rejestr dzialaja dzisiaj. To, co jeszcze dojrzewa, to bogatsza powierzchnia przegladowa operatora — pelna konsola kolejki zatwierdzania; punkty koncowe i niezmienniki po stronie serwera sa dostarczone, dopracowany interfejs to sciezka naprzod. Jak z reszta platformy, to pre-1.0 open core: przeczytaj Uczciwosci i ograniczenia co jest aktywne vs projektowane. Olivares AI jest projektowany w kierunku SOC 2, ISO 27001 i EU AI Act, nie certyfikowany wobec nich.

Powiazane

• Zarzadzanie — model autoryzacji i postawa samoaudytu w pelni.
• Dozwolone vs obserwowane — dryf, na ktorym dzialaja te decyzje.
• Podlacz zrodlo — podlacz sygnaly, z ktorych dryf jest budowany.
• Wylacznik awaryjny — stopniowe zatrzymanie awaryjne infrastruktury.