Das HITL-Tor stellt sicher, dass keine risikoreiche Agentenaktion ohne menschliches Urteil fortschreitet. Dieses Cookbook durchlaeuft den gesamten Genehmigungslebenszyklus — vom Moment, in dem eine gesteuerte Aktion eine Anfrage ausloest, ueber die Risikostufen-Aufloesung, menschliche Entscheidungen und das Break-Glass-Notventil — sodass Sie jedes bewegliche Teil nachvollziehen koennen, bevor Sie ihm in der Produktion begegnen.
Wenn Sie das Autorisierungsmodell noch nicht gelesen haben, beginnen Sie mit Governance. Der Leitfaden Steuern und Genehmigen behandelt dieselbe Mechanik aus Operator-Perspektive; diese Seite ist die Schritt-fuer-Schritt-Referenz.
Der Anfrageablauf
Eine Genehmigungsanfrage oeffnet standardmaessig-ablehnend und zeitbegrenzt. Sie startet
als pending, traegt einen Ablauf und autorisiert nichts, bis genug Menschen entschieden
haben. Die Anfrage kann ihre eigene Messlatte nicht senken — eine passende
Genehmigungsrichtlinie ist autoritativ fuer den Schwellenwert und die Timeouts.
Die Anfrage ist an einen Plan-Hash des exakten Tool-Call-Payloads gebunden. Das ist die Anti-TOCTOU-Verteidigung: Wenn sich die zugrunde liegende Aktion zwischen Anfrage und Entscheidung aendert, stimmt der Hash nicht ueberein und die Genehmigung kann nicht binden. Eine veraltete Genehmigung autorisiert nie eine andere Aktion.
Risikostufen-Aufloesung
Vier Stufen bestimmen, wie viel menschliche Kontrolle eine gesteuerte Aktion erfordert:
| Stufe | Bedeutung |
|---|---|
low / medium | Wird nur durch explizite Genehmigungsrichtlinie zugewiesen — nichts faellt hier standardmaessig hinein |
high | Der Standard fuer alles, was die Genehmigungswarteschlange erreicht. Eine menschliche Genehmigung erforderlich |
critical | Verbindliche Zwei-Personen-Untergrenze (NIST SP 800-53 AC-3(2) Dual Authorization) |
Die Stufe wird bei jeder Entscheidung aus dem Live-Richtlinien-Set neu abgeleitet, nie aus einem gespeicherten Snapshot gelesen. Eine Richtlinienaenderung wird sofort wirksam. Eine veraltete Zeile kann die Messlatte nie niedriger halten als die aktuelle Klassifikation — das ist konstruktionsbedingt standardmaessig-ablehnend.
Das eingebaute critical-Set deckt das wirklich Irreversible ab: Produktions-Deploy und
-Retire, Datenloeschung und -vernichtung, Sicherheitsdurchsetzungs- und Kill-Switch-Aenderungen,
Schluesselverwahrung und -rotation, sowie NHI-Offboarding.
Eine Genehmigungsrichtlinie mit einem expliziten risk_tier kann den Standard pro Aktion
heben oder senken. Aber sie kann nie eine critical-Aktion unter die
Dual-Control-Untergrenze senken.
Schritt fuer Schritt
1. Eine gesteuerte Aktion loest eine Anfrage aus
Eine gesteuerte Aktion — Deploy Apply, Agent Fire, Budget-Override oder jede Aktion, die
einer Genehmigungsrichtlinie entspricht — erreicht die Genehmigungs-Engine. Die Engine
oeffnet eine neue Anfrage im pending-Zustand.
2. Die Anfrage bindet an einen Plan-Hash
Die Anfrage zeichnet einen Hash des exakten Tool-Call-Payloads auf. Diese Plan-Hash-Bindung ist die TOCTOU-Verteidigung: Die Entscheidung autorisiert nur die Aktion, fuer die die Anfrage erstellt wurde.
3. Risikostufe wird aus aktueller Richtlinie aufgeloest
Die Engine evaluiert das Live-Richtlinien-Set (RBAC, natives ABAC und jeden externen PDP), um die Risikostufe abzuleiten. Die Stufe wird nie aus einer frueheren Evaluation gecacht.
4. Ein menschlicher Pruefer entscheidet
Ein Mensch mit ausreichender Rolle gibt ein approve oder deny ab. Der Server setzt
drei Invarianten an diesem Punkt durch, basierend auf stabiler Benutzeridentitaet:
- Funktionstrennung. Der Antragsteller kann nicht ueber seine eigene Anfrage entscheiden. Dies basiert auf der stabilen Benutzeridentitaet, nicht dem Credential-String, den eine einzelne Person variieren koennte.
- Doppelentscheider-Schutz. Ein Unique-Index sichert gegen eine Doppelentscheider-Race-Condition ab — ein Mensch zaehlt einmal fuer den Schwellenwert.
- Ablauf bindet. Eine abgelaufene Anfrage kann nie eine bindende Entscheidung erhalten, selbst bevor ein Sweep den Ablauf materialisiert. Der effektive Status wird bei jeder Entscheidung neu abgeleitet.
5. Kritische Aktionen: Dual-Control mit AAL3
Fuer die critical-Stufe: Der Schwellenwert ist auf zwei verschiedene menschliche
Genehmiger begrenzt. Die Untergrenze wird sowohl bei der Erstellung durchgesetzt (der
gespeicherte Schwellenwert kann nie unter zwei beginnen) als auch bei der Entscheidung neu
angewandt (eine vor der Kritisch-Einstufung erstellte Anfrage kann immer noch nicht mit
einem Menschen passieren).
Jeder entscheidende Mensch muss eine frische hardwareverifizierte Sitzung haben — WebAuthn- oder PIV-Stufenerhoehung (AAL3). Ein System-Token traegt keine menschliche Gewaehrleistung und wird abgelehnt.
6. Die Entscheidung wird im Ledger aufgezeichnet
Jede Entscheidung haengt eine unveraenderliche 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. Das Ledger ist nur-anhaengend, hash-verkettet und Ed25519-signiert — eine Umschreibung der Geschichte ist kryptographisch erkennbar.
Ablauf
Der Ablauf wird beim Lesen abgeleitet, nicht einmal geschrieben. Eine abgelaufene Anfrage kann nie eine bindende Entscheidung erhalten, selbst wenn kein Hintergrund-Sweep den Ablauf materialisiert hat. Der effektive Status wird immer neu abgeleitet, sodass ein langsamer Sweep eine kosmetische Verzoegerung ist, keine Sicherheitsluecke.
Richtlinienkonfiguration
Genehmigungsrichtlinien lassen Sie die Standard-Risikostufe pro Aktionsklasse ueberschreiben.
Eine Richtlinie mit einem expliziten risk_tier kann eine Aktion von high auf low
verschieben oder ein medium auf critical anheben. Die eine Einschraenkung: Sie koennen
critical nie unter die Dual-Control-Untergrenze senken. Die Zwei-Personen-Anforderung
fuer irreversible Aktionen ist strukturell, nicht konfigurierbar.
Break-Glass
Wenn ein Quorum nicht erreichbar ist — der 03:00-Uhr-Vorfall, bei dem der zweite Genehmiger schlaeft — bietet Break-Glass ein auditiertes Notventil. Es ist konstruktionsbedingt laut.
Die Aktivierung erfordert alles davon:
- Der Aktivierende ist ein Admin, immer ein echter Mensch — ein System-Token wird abgelehnt.
- Eine frische AAL3-Stufenerhoehung (WebAuthn oder PIV).
- Eine schriftliche Begruendung, die in derselben Transaktion aufgezeichnet wird.
- Eine aktiv aufgezeichnete Sitzung als Voraussetzung.
Zeitbegrenzung: Die Berechtigung laeuft standardmaessig eine Stunde, Obergrenze 24. Ein Notfall, der laenger braucht, ist ein Betriebsmodus, kein Notfall, und muss den normalen Dual-Control-Weg nehmen.
Jede Nutzung wird aufgezeichnet. Jede unter Break-Glass ausgefuehrte Aktion haengt eine unveraenderliche 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 ordnungsgemaess genehmigten unterscheidbar.
Erzwungenes Post-Review. Eine neue Berechtigung kann nicht aktiviert werden, solange eine vorherige Berechtigung nicht ueberprueeft ist. Die Ueberpruefung muss von einem anderen Menschen als dem Aktivierenden kommen. Sie koennen keine Notfaelle stapeln, um Kontrolle zu umgehen.
Break-Glass lockert ein fehlendes Quorum; es ueberschreibt nie eine explizite Ablehnung. Eine Anfrage, die jemand bewusst abgelehnt hat, bleibt abgelehnt.
Was aufgezeichnet wird
Jede Entscheidung — Genehmigung, Ablehnung, Ablauf oder Break-Glass-Nutzung — wird an zwei Stellen angehaengt:
- Der Entscheidungs-Trail der Anfrage: eine unveraenderliche Folge von Entscheidungszeilen auf der Anfrage selbst, jede mit dem Entscheider, dem Urteil und dem Zeitstempel.
- Das Audit-Ledger: ein hash-verkettetes, Ed25519-signiertes Ereignis, das die Entscheidung, den resultierenden Anfragestatus und die Risikostufe aufzeichnet, unter der sie getroffen wurde.
Beide Schreibvorgaenge erfolgen in derselben Transaktion wie die Zustandsaenderung. Sie koennen keine gesteuerte Entscheidung treffen, die das Ledger stillschweigend vergisst.
Verwandte Themen
- Steuern und Genehmigen — der Operator-Leitfaden, der dieselbe Mechanik behandelt.
- Governance — das Autorisierungsmodell, die Selbst-Audit-Haltung und die Kill-Switch-Mechanik.
- Cookbook: Kill-Switch-Uebung — die umgebungsweite Ablehnungstor-Uebung.
- Kill Switch — die Produktseite fuer den Notstopp.