Governance mit Lesen-zuerst und Deny-closed

Wie Olivares AI beobachtet, bevor es durchsetzt, Aktionen standardmaessig ablehnend steuert.

Governance in Olivares AI baut auf zwei Prinzipien auf, die Sie sich gleichzeitig merken koennen: Beobachten, bevor Sie durchsetzen, und wenn Sie durchsetzen, standardmaessig Nein. Das Produkt kartiert und auditiert, was jeder Agent erreichen kann, lange bevor es eine einzelne Aktion einschraenkt, und die Einschraenkungen, die es durchsetzt, sind standardmaessig-ablehnend.

Lesen-zuerst: Beobachtung vor Durchsetzung

Die Standard-Haltung der Plattform ist detektiv, nicht praeventiv. Sie baut die Lese-/Schreib-Zugriffskarte auf, indem sie Logs, OpenTelemetry und natives Audit ausserhalb des Datenpfads aufnimmt — sie ist nie im Datenpfad des Agenten, sodass ein ausfallender Kollektor nie die Produktion lahmlegen kann. Aus dieser Karte gleicht sie Erlaubtes gegen Beobachtetes ab und zeigt Drift an, damit ein Mensch urteilen kann.

Das ist wichtig dafuer, wie Sie den Rest dieser Seite lesen. Das Produkt beobachtet und steuert breit; es fuehrt nicht breit aus. Wo es eine Aktion auf Ihrer Infrastruktur ausfuehren kann, ist diese Faehigkeit eines von drei Dingen, und der Modulkatalog markiert, welches:

live — verdrahtet und heute aktiv (ein kleines Set);
on-demand — das Backend ist gebaut und mit einem Injektionspunkt verdrahtet, aber bleibt standardmaessig-ablehnend oder degradiert, bis Sie es bereitstellen (ein Executor, ein Dispatcher, ein Inferenz-Credential);
Naht — eine deklarierte, standardmaessig-ablehnende Schnittstelle ohne Backend im Standard-Binary.

Eine Abwesenheit von Durchsetzung ist also normalerweise beabsichtigt, kein Versehen. Lesen-zuerst bedeutet, dass der ehrliche Standard ist, zu beobachten und aufzuzeichnen, und nur die Oberflaechen einzuschraenken, die Sie explizit eingeschaltet haben.

Das Autorisierungsmodell, innerhalb dessen Sie steuern

Jede gesteuerte Entscheidung laeuft durch denselben Autorisierungskern, der den Rest der API schuetzt. Drei Eigenschaften sind verinnerlichenswert, bevor Sie etwas aendern.

RBAC ist standardmaessig-ablehnend. Ein Prinzipal ohne Mitgliedschaft in einem Mandanten wird abgelehnt — es gibt keine implizite Berechtigung. Berechtigungen sind mandantenbezogen, und ein Handler agiert nur auf dem einzelnen Mandanten, zu dem die Anfrage aufgeloest wurde, was Confused-Deputy- und IDOR-Klassen konstruktionsbedingt schliesst. Die Rollen bilden eine Leiter: viewer liest, editor schreibt, admin verwaltet Mandanten-IAM, owner haelt alles. Das Lesen des Zugriffsgraphen ist bewusst ein Editor-und-hoeher-Privileg — eine vollstaendige Karte dessen, was jeder Agent erreichen kann, ist ein Aufklaerungsplan — und jeder solche Lesevorgang wird in das Audit-Ledger geschrieben.

Die Policy-Naht schraenkt nur ein. Ueber RBAC hinaus koennen Sie einen attributbasierten Policy Decision Point verdrahten. Die Komposition ist eine Schnittmenge — RBAC ∩ natives ABAC ∩ externer PDP — sodass eine Richtlinie nur weiter einschraenken kann, was RBAC bereits erlaubt hat; sie kann nie eine Berechtigung erweitern. Dies wird durchgesetzt, nicht per Konvention. Sie waehlen hoechstens eine externe Engine:

# Eingebettetes Cedar (reines Go, kein Sidecar) oder OPA ueber HTTP. Standard: keines.
OLIVARES_PDP_ENGINE=cedar   # oder: opa | none

Mit Cedar verfassen Sie forbid-Regeln; ein leeres Regelwerk laesst die RBAC-Entscheidung bestehen. Mit OPA muss Ihr Rego standardmaessig-erlaubend sein, wobei ein fehlendes Ergebnis oder jeder Transportfehler standardmaessig-ablehnend schliesst. Eine ungueltige PDP-Konfiguration deaktiviert nur den externen PDP und protokolliert dies — natives ABAC und RBAC steuern weiter, und eine falsch konfigurierte Engine laesst nie eine Anfrage ungesteuert. Jede Einschraenkung, die der PDP anwendet, wird auditiert.

Risikostufen und die Dual-Control-Untergrenze

Aktionen, die die Genehmigungswarteschlange erreichen, werden in vier Risikostufen klassifiziert — low, medium, high, critical — gemaess der OWASP AI-Agent-Taxonomie. (Dies ist eine separate Achse von den EU-AI-Act-Compliance-Stufen; verwechseln Sie die beiden nicht.) Die Stufe wird bei jeder Sicherheitsentscheidung aus der Live-Richtlinie neu abgeleitet, nie aus einem gespeicherten Snapshot gelesen, sodass eine Richtlinienaenderung sofort wirksam wird und eine veraltete Zeile die Messlatte nie niedriger halten kann als die aktuelle Klassifikation.

Eine critical-Aktion traegt eine verbindliche Zwei-Personen-Untergrenze: mindestens zwei verschiedene menschliche Genehmiger, angelehnt an NIST SP 800-53 AC-3(2) Dual Authorization. Die Untergrenze wird zweimal durchgesetzt — bei der Erstellung (der gespeicherte Schwellenwert kann nie unter ihr beginnen) und bei der Entscheidung neu abgeleitet (eine herabgestufte oder Legacy-Zeile kann immer noch nicht mit einem Genehmiger passieren) — sodass selbst eine Betreiberrichtlinie, die die Stufe explizit senkt, eine kritische Aktion nicht einhaendig machen kann. Das eingebaute kritische Set umfasst die irreversiblen, estate-praegenden Aktionen: Produktions-Deploy und -Retire, Datenloeschung, Sicherheitsdurchsetzungs-Aenderungen, Schluesselverwahrung und -rotation, sowie die Wiederaktivierung der Umgebung nach einem Kill Switch.

Niedrigere Stufen aendern nicht die Mechanik der Engine — eine existierende Genehmigung erfordert bereits mindestens einen Menschen — sie sind das Vokabular, an das andere Kontrollen anknuepfen (zum Beispiel die Authentifizierungs-Stufenerhoehung bei einer kritischen Aktion).

Das Human-in-the-Loop-Genehmigungstor

Wo das Produkt eine Aktion einschraenkt, ist der Ablauf: Eine Oberflaeche praesentiert (Drift aus der Zugriffskarte, ein Befund aus dem Sicherheitsmodul) → ein autorisierter Operator entscheidet → die Entscheidung wird im Audit-Ledger aufgezeichnet. Die Genehmigungs-Engine, die dies unterstuetzt, existiert heute: Eine Anfrage oeffnet standardmaessig-ablehnend, gebunden an einen Plan-Hash und zeitbegrenzt. Die Invarianten werden serverseitig durchgesetzt, basierend auf der stabilen Benutzeridentitaet (ein System-Token hat keine Identitaet und kann nicht entscheiden):

Funktionstrennung — der Antragsteller kann nie ueber seine eigene Anfrage entscheiden.
Doppelentscheider-Schutz — ein Mensch zaehlt nur einmal fuer einen Schwellenwert.
Ablauf — wird beim Lesen abgeleitet, sodass eine abgelaufene Anfrage nie binden kann, selbst bevor ein Sweep ihren Ablauf materialisiert.

Was noch reift, ist die reichhaltigere Operator-Review-Konsole; die Endpunkte und die Engine werden heute ausgeliefert. Der Leitfaden Steuern und Genehmigen fuehrt durch den Live-Ablauf.

Die Abhaengigkeit, die all dies glaubwuerdig macht, ist Pro-Agent-Identitaet. Audit ordnet Aktivitaet einem Credential zu, nicht inhaerent einem Agenten; ein gemeinsames Dienstkonto kollabiert die Zuordnung auf die Identitaetsebene — ehrlich als Befund dargestellt, nie stillschweigend wiederhergestellt. Siehe Erlaubt vs Beobachtet und Genauigkeit fuer das, was das mit dem Signal macht, auf dem Sie steuern.

Break-Glass: Das auditierte Notventil

Zwei-Personen-Kontrolle braucht ein Notventil fuer den 03:00-Uhr-Vorfall, bei dem ein Genehmiger nicht erreichbar ist. Break-Glass ist dieses Ventil, und es ist konstruktionsbedingt laut. Die Aktivierung ist Admin-Stufe und erfordert einen echten Menschen (ein System-Token wird abgelehnt), eine hardwareverifizierte (AAL3) Stufenerhoehung, eine schriftliche Begruendung und eine aktiv aufgezeichnete Sitzung als Voraussetzung. Die Berechtigung ist zeitbegrenzt — Standard eine Stunde, Obergrenze ein Tag — und eine abgelaufene Berechtigung kann nichts autorisieren.

Waehrend eine Berechtigung aktiv ist, darf eine betroffene Aktion ohne ihr Genehmigungsquorum fortfahren, aber jede Nutzung wird einem unveraenderlichen Trail und dem Audit-Ledger angehaengt, mit Benennung der Berechtigung, der Aktion und des Subjekts — eine Aktion, die unter Break-Glass fortschritt, ist dauerhaft unterscheidbar von einer genehmigten. Ein erzwungenes Post-Review schliesst den Kreislauf: Eine neue Berechtigung kann nicht aktiviert werden, solange eine vorherige nicht ueberprueeft ist, und die Ueberpruefung muss von einem anderen Menschen als dem Aktivierenden kommen.

Der Kill Switch: Das umgebungsweite Ablehnungstor

Der Kill Switch ist der Ein-Klick-Notstopp, und er invertiert die uebliche Ergonomie absichtlich. Das Aktivieren ist bewusst guenstig — Admin-Stufe, ein obligatorischer Grund, kein Genehmigungsquorum, keine Stufenerhoehung, kein Break-Glass — weil ein Stopp, der auf Konsens wartet, kein Stopp ist. Das Sicherheitsniveau der aktivierenden Sitzung wird fuer die Forensik aufgezeichnet; Missbrauch des Aktivierens kostet nur Verfuegbarkeit, was die sichere Richtung ist.

Die Stopp-Zeile ist die einzige Wahrheitsquelle. Jedes gesteuerte Aktionstor konsultiert sie live bei jeder Aktion und schliesst bei einem Lesefehler ablehnend — das genaue Gegenteil des Fail-Open-Vertrags der Budget-Tore, weil ein unlesbarer Stopp-Zustand nie “weiter” bedeuten darf. Das Aktivieren widerruft auch die eingestellte Arbeit, die die Tore nicht erreichen koennen: Jede ausstehende betroffene Aktionsgenehmigung wird in derselben Transaktion storniert, sodass eine Vor-Stopp-Absicht nicht zu einer Berechtigung reifen kann, die in dem Moment dispatcht wird, in dem die Umgebung zurueckkommt. Governance-Aktionen selbst sind ausgenommen — der Stopp haelt die agentische Umgebung an, nie die Kontrollen, die sie steuern.

Die Wiederaktivierung ist nie unilateral. Sie ist an eine frische Dual-Control-Genehmigung gebunden (die critical Zwei-verschiedene-Menschen-Untergrenze, strukturell beim Umschalten neu verifiziert, sodass eine herabgestufte Richtlinie sie nicht einhaendig machen kann), und es gibt bewusst keinen Break-Glass-Pfad fuer die Wiederaktivierung: “Die Umgebung bleibt gestoppt” ist der sichere Zustand. Ein erzwungenes Post-Review durch einen unbeteiligten Menschen schliesst den Vorfall.

Die Garantie aufgezeichneter Entscheidungen

Unabhaengig von der Tiefe des Workflows darueber ist eine Governance-Entscheidung eine aufgezeichnete Tatsache. Mutierende Aktionen werden dem Audit-Ledger mit dem echten Akteur in derselben Transaktion wie die Aenderung angehaengt, und sensible Lesevorgaenge (der Zugriffsgraph, das Ledger selbst) auditieren sich selbst in einem festgeschriebenen Schreibvorgang. Das Ledger ist nur-anhaengend und hash-verkettet, jeder Datensatz traegt die Ketten-Integritaetsfelder, sodass eine Umschreibung der Geschichte erkennbar ist und es nie PII enthaelt. Sie koennen keine ungesteuerte Aenderung vornehmen, die das Ledger stillschweigend vergisst.

Governance: Lesen-zuerst und standardmaessig-ablehnend