Steuern und Genehmigen

Olivares AI steuert Agentenzugriff mit Risikostufen, Dual-Control, auditiertem Break-Glass und einem nur-anhängenden Ledger jeder Entscheidung.

Sobald eine Quelle verbunden ist und die Zugriffskarte zeigt, was jeder Agent lesen und schreiben kann, ist die nächste Aufgabe, es zu steuern: Entscheiden, wer und was handeln darf, und jede Entscheidung zu einer aufgezeichneten Tatsache machen. Diese Seite behandelt den Genehmigungsablauf — Risikostufen, Dual-Control, Break-Glass und das Ledger, an dem alles verankert ist.

Governance ist standardmäßig-ablehnend. Ein Prinzipal ohne Rolle in einem Mandanten wird abgelehnt; es gibt keine implizite Berechtigung. Das Produkt beobachtet breit, führt aber nicht breit aus — wo es eine Aktion steuert, tut es dies standardmäßig-ablehnend, nie als pauschaler Ausführer.

Das Autorisierungsmodell

Jeder Governance-Aufruf läuft durch denselben Autorisierungskern wie der Rest der API: RBAC zuerst, auf einen einzelnen Mandanten begrenzt, mit einer optionalen externen Richtlinienebene darüber.

Die Rollen bilden eine Leiter — viewer (Lesen), editor (Schreiben), admin (Mandanten-IAM), owner (alles im Mandanten). Das Lesen der Zugriffskarte ist bewusst nicht die niedrigste Stufe: Eine Karte dessen, was jeder Agent berühren kann, ist ein Aufklärungsplan, daher wird es ab editor aufwärts gewährt, mandantenbezogen, und jeder Lesevorgang wird im Ledger aufgezeichnet.

Ein optionaler Policy Decision Point (eingebettetes Cedar oder OPA über HTTP) kann attributbasierte Regeln darüberlegen. Er komponiert als Schnittmenge — RBAC ∩ natives ABAC ∩ externer PDP — und hat eine Invariante:

Die Richtlinienebene kann nur Zugriff wegnehmen, nie hinzufügen. Eine Richtlinie kann etwas ablehnen, das RBAC erlaubt hätte; sie kann nie etwas gewähren, das RBAC ablehnt. Ein falsch konfigurierter oder nicht erreichbarer PDP schließt ablehnend, und das Deaktivieren des externen PDP lässt Anfragen nie ungesteuert — natives RBAC und ABAC steuern weiter.

Risikostufen

Eine gesteuerte Aktion wird in eine von vier Stufen klassifiziert — low, medium, high, critical — abgeleitet von der OWASP-AI-Agent-Risikotaxonomie. Die Stufe bestimmt, wie viel menschliche Kontrolle die Aktion erfordert, bevor sie fortschreiten kann.

Die Stufe wird nicht auf der Genehmigungszeile gespeichert. Sie wird bei jeder Entscheidung aus dem aktuellen Richtlinien-Set plus einem eingebauten Standard neu abgeleitet, sodass eine Richtlinienänderung sofort wirksam wird und ein veralteter Snapshot die Messlatte nie unter die Live-Klassifikation halten kann (standardmäßig-ablehnend).

Stufe	Standard-Kontrolle
`low` / `medium`	wird nur durch explizite Richtlinie zugewiesen
`high`	der Standard für alles, was die Genehmigungswarteschlange erreicht — eine menschliche Genehmigung
`critical`	eine verbindliche Zwei-Personen-Untergrenze (siehe unten)

Das eingebaute critical-Set deckt das wirklich Irreversible ab: Produktions-Deploy und -Retire, Datenlöschung und -vernichtung, Sicherheitsdurchsetzungs- und Kill-Switch-Änderungen, Schlüsselverwahrung und -rotation, sowie NHI-Offboarding. Eine Genehmigungsrichtlinie mit einem expliziten risk_tier kann den Standard pro Aktion heben oder senken — das ist das auditierte Wort des Operators — aber sie kann nie eine critical-Aktion unter die Dual-Control-Untergrenze senken.

Genehmigungsanfragen und Dual-Control

Eine Genehmigungsanfrage öffnet standardmäßig-ablehnend und zeitbegrenzt: Sie startet als pending, trägt einen Ablauf und autorisiert nichts, bis genug Menschen entschieden haben. Eine passende Genehmigungsrichtlinie ist autoritativ für den Schwellenwert und die Timeouts, sodass ein Antragsteller seine eigene Messlatte nie senken kann.

Drei Invarianten werden serverseitig durchgesetzt, nicht per Konvention:

Funktionstrennung. Der Antragsteller kann nicht über seine eigene Anfrage entscheiden. Dies basiert auf der stabilen Benutzeridentität, nicht dem Credential-String, den eine einzelne Person variieren könnte.
Eine Entscheidung pro Mensch. Ein Unique-Index sichert gegen eine Doppelentscheider-Race-Condition ab; dieselbe Person kann nicht doppelt für den Schwellenwert zählen.
Ablauf bindet. Eine abgelaufene Anfrage kann nie eine bindende Entscheidung erhalten — der effektive Status wird bei jeder Entscheidung neu abgeleitet, Sweep hin oder her.

Für critical-Aktionen ist der Schwellenwert auf zwei verschiedene menschliche Genehmiger begrenzt (NIST SP 800-53 AC-3(2) Dual Authorization). Die Untergrenze wird sowohl bei der Erstellung (der gespeicherte Schwellenwert kann nie unter zwei beginnen) als auch bei der Entscheidung durchgesetzt (eine vor der Kritisch-Einstufung erstellte Anfrage kann immer noch nicht mit einem Menschen passieren). Ein einzelner Genehmiger kann nie eine kritische Aktion erfüllen.

Eine critical-Entscheidung erfordert zusätzlich eine hardwareverifizierte Sitzung: Der entscheidende Mensch muss eine frische WebAuthn- oder PIV-Stufenerhöhung (AAL3) haben. Ein System-Token trägt keine menschliche Gewährleistung und wird abgelehnt — a system token cannot approve.

Jede Entscheidung hängt eine unveränderliche Zeile an den Entscheidungs-Trail der Anfrage und ein Ledger-Ereignis an, das die Entscheidung, den resultierenden Status und die Risikostufe aufzeichnet, unter der sie getroffen wurde.

Break-Glass

Zwei-Personen-Kontrolle hat ein Notventil für den 03:00-Uhr-Vorfall, bei dem der zweite Genehmiger nicht erreichbar ist. Ein Admin — immer ein echter Mensch, nie ein System-Token — aktiviert eine zeitbegrenzte Notfall-Berechtigung, die eine gesteuerte Aktion ohne ihr Quorum fortschreiten lässt. Der Pfad ist nie leise:

Aktivierung erfordert eine Begründung, auditiert sich selbst in derselben Transaktion ins Ledger und emittiert einen kritischen Befund an die Benachrichtigungsschiene.
Jede Nutzung hängt eine unveränderliche Zeile und ein Ledger-Ereignis an, das die Berechtigung, die Aktion und das Subjekt benennt. Eine Aktion, die unter Break-Glass fortschritt, ist dauerhaft von einer ordnungsgemäß genehmigten unterscheidbar.
Die Berechtigung ist zeitbegrenzt — Standard eine Stunde, Obergrenze 24. Ein “Notfall”, der länger braucht, ist ein Betriebsmodus, kein Notfall, und muss den normalen Dual-Control-Weg nehmen.
Erzwungenes Post-Review. Eine neue Berechtigung kann nicht aktiviert werden, solange eine vorherige unüberprüft ist, und die Überprüfung muss von einem anderen Menschen als dem Aktivierenden kommen. Sie können keine Notfälle stapeln, um Kontrolle zu umgehen.

Break-Glass lockert ein fehlendes Quorum; es überschreibt nie eine explizite menschliche Ablehnung. Eine Anfrage, die jemand bewusst abgelehnt hat, bleibt abgelehnt.

Die Garantie aufgezeichneter Entscheidungen

Unabhängig von der Tiefe des Workflows darüber ist eine Governance-Entscheidung eine aufgezeichnete Tatsache. Mutierende Aktionen werden dem Audit-Ledger mit dem echten Akteur in derselben Transaktion wie die Änderung angehängt, und sensible Lesevorgänge (die Zugriffskarte, das Ledger selbst) auditieren sich selbst in einem festgeschriebenen Schreibvorgang. Sie können keine ungesteuerte Änderung vornehmen, die das Ledger stillschweigend vergisst.

Das Ledger ist nur-anhängend, hash-verkettet und Ed25519-signiert. Jeder Datensatz trägt seq, prev_hash, hash und sig, sodass eine Umschreibung der Geschichte kryptographisch erkennbar ist, und das Ledger enthält nie PII. Für die externe, unveränderliche Kopie, die ein Auditor anfordert, wird das Ledger als authentifizierter Pull-Export unter /v1/audit/export exponiert, mit format-Werten cef, leef, syslog, otlp und ocsf. Jeder exportierte Datensatz trägt die Ketten-Integritätsfelder, sodass ein SIEM- oder WORM-Speicher die Kette offline re-verifizieren kann — die abgelöste Signatur verteidigt gegen eine nur-Datenbank-Kompromittierung, und die Off-Box-Kopie gegen einen vollständig kompromittierten Host.

Ehrlicher Umfang

Der Autorisierungskern, die Genehmigungs-Engine und das Ledger laufen heute. Was noch reift, ist die reichhaltigere Operator-Review-Oberfläche — eine vollständige Genehmtigungswarteschlangen-Konsole; die Endpunkte und die serverseitigen Invarianten sind ausgeliefert, die polierte UI ist der Weg nach vorn. Wie beim Rest der Plattform ist dies pre-1.0 Open Core: Lesen Sie Ehrlichkeit und Grenzen für das, was live ist versus was angestrebt wird. Olivares AI ist darauf ausgelegt, SOC 2, ISO 27001 und EU-AI-Act-Kontrollen zu erfüllen, nicht dagegen zertifiziert.