Cookbook: Kill-Switch-Uebung

Eine sichere Kill-Switch-Uebung auf einer Nicht-Produktionsumgebung durchfuehren -- den umgebungsweiten Stopp aktivieren.

Der Kill Switch ist das umgebungsweite Ablehnungstor. Das Aktivieren ist bewusst guenstig — Admin-Stufe, kein Quorum — weil ein Stopp, der auf Konsens wartet, kein Stopp ist. Die Wiederaktivierung ist bewusst teuer: Dual-Control, kein Break-Glass. Sie wollen eine Luecke in keiner der beiden Richtungen um 03:00 Uhr entdecken.

Eine Uebung auf einem Nicht-Produktions-Mandanten ist der einzige sichere Weg zu beweisen, dass das Stopp-Tor jede Aktionsnaht ablehnt, dass ausstehende Genehmigungen atomar storniert werden und dass die Wiederaktivierung tatsaechlich zwei verschiedene Menschen erfordert. Fuehren Sie sie durch, bevor Sie sie brauchen.

Voraussetzungen

Ein Nicht-Produktions-Mandant. Die Uebung aktiviert einen echten umgebungsweiten Stopp. Fuehren Sie sie gegen Staging oder Dev aus, nie gegen Produktion.
Mindestens drei menschliche Benutzer. (1) Ein admin-stufiger Aktivierender; (2) zwei verschiedene Wiederaktivierungs-Genehmiger (editor oder hoeher), die die critical Dual-Control-Untergrenze erfuellen; (3) ein unbeteiligter Post-Reviewer (editor oder hoeher), der das erzwungene Post-Review schliesst. Der Post-Reviewer kann mit einem Genehmiger ueberlappen, wenn er nicht der Aktivierende ist.
Eine Liste der zu testenden gesteuerten Aktionsnaehte — Deploy Apply, Orchestrierung Fire, Voice Open, Modellausfuehrung, Budget-Ausgabe, plus alle benutzerdefinierten Oberflaechen, die Sie verdrahtet haben.

Schritt 1: Den Kill Switch aktivieren

Der Aktivierende aktiviert den Kill Switch mit einer obligatorischen Begruendung:

# Der API-Aufruf -- ersetzen Sie Host, Port und Auth-Header.
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

Das Aktivieren ist bewusst guenstig: Admin-Stufe, ein Grund, kein Genehmigungsquorum, keine Stufenerhoehung, kein Break-Glass. Die Stopp-Zeile wird die einzige Wahrheitsquelle. Jedes gesteuerte Aktionstor konsultiert sie live bei jeder Aktion und schliesst bei einem Lesefehler ablehnend.

In derselben Transaktion wie die Aktivierung wird jede ausstehende betroffene Aktionsgenehmigung storniert — eine Vor-Stopp-Absicht kann nicht zu einer Berechtigung reifen, sobald die Umgebung zurueckkommt. Notieren Sie den Zeitstempel; Sie werden das Ledger spaeter darauf pruefen.

Schritt 2: Ablehnung verifizieren

Mit aktiviertem Kill Switch versuchen Sie jede gesteuerte Aktion, die Ihre Umgebung verdrahtet hat. Jede muss als abgelehnt zurueckkommen.

Zu testende Aktionsnaehte:

Naht	Was zu versuchen ist	Erwartetes Ergebnis
Deploy	`POST /v1/deploy/apply` mit einem gueltigen Plan	Abgelehnt
Orchestrierung	`POST /v1/orchestration/fire`	Abgelehnt
Voice	`POST /v1/voice/open`	Abgelehnt
Modellausfuehrung	Jeder Inferenz- oder Modellaufruf ueber den gesteuerten Pfad	Abgelehnt
Budget-Ausgabe	Jede Ausgabenaktion gegen die Budget-Tore	Abgelehnt

Testen Sie jede Naht, die Ihre Umgebung bereitgestellt hat. Wenn Sie benutzerdefinierte Aktionsoberflaechen ueber den Governance-Kern verdrahtet haben, schliessen Sie diese ebenfalls ein.

Verifizieren Sie auch, was weiterhin funktionieren muss:

Der Stopp haelt die agentische Umgebung an, nie die Kontrollen, die sie steuern. Governance-Aktionen bleiben verfuegbar:

Zugriffskarte lesen — GET /v1/access-map sollte normal zurueckkommen.
Audit-Ledger anzeigen — GET /v1/audit/export sollte das Ledger zurueckgeben, einschliesslich des soeben erstellten Aktivierungsereignisses.
Genehmigungen auflisten — die Genehmigungswarteschlange ist lesbar; die zuvor ausstehenden Genehmigungen sollten als storniert angezeigt werden.

Wenn eine Aktionsnaht etwas anderes als abgelehnt zurueckgibt, oder wenn eine Governance-Aktion blockiert ist, stoppen Sie die Uebung und untersuchen Sie. Der Kill Switch hat eine Luecke.

Schritt 3: Die Umgebung wieder aktivieren

Die Wiederaktivierung ist nie unilateral. Sie erfordert eine frische Dual-Control-Genehmigung auf der critical-Stufe: zwei verschiedene Menschen, strukturell beim Umschalten neu verifiziert. Es gibt bewusst keinen Break-Glass-Pfad fuer die Wiederaktivierung — “Die Umgebung bleibt gestoppt” ist der sichere Zustand.

Der Aktivierende (oder ein beliebiger Admin) beantragt die Wiederaktivierung:

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

Dies erstellt eine Genehmigungsanfrage auf critical-Stufe. Zwei Genehmiger — jeweils ein verschiedener Mensch, keiner mit System-Token — muessen sie jeweils ueber POST /v1/approvals/<request-id>/decide mit {"decision": "approve"} genehmigen. Die Dual-Control-Untergrenze wird serverseitig durchgesetzt: Der Doppelentscheider-Schutz verhindert, dass eine Person doppelt zaehlt, und ein System-Token wird abgelehnt (keine menschliche Gewaehrleistung). Selbst wenn die Richtlinien-Stufe herabgestuft wird, haelt die strukturelle Untergrenze — eine critical-Aktion kann nicht mit einem Genehmiger passieren. Sobald beide Genehmigungen vorliegen, wird die Umgebung wieder aktiviert.

Schritt 4: Wiederherstellung verifizieren

Wiederholen Sie jeden Aktionsversuch aus Schritt 2. Jeder sollte jetzt erfolgreich sein (erlaubt oder in den normalen Genehmigungsablauf geleitet). Wenn eine Naht nach der Wiederaktivierung weiterhin abgelehnt wird, hat sich die Wiederaktivierung nicht vollstaendig verbreitet — untersuchen Sie, bevor Sie die Uebung abzeichnen.

Schritt 5: Das Post-Review abschliessen

Ein erzwungenes Post-Review durch einen unbeteiligten Menschen ist strukturell erforderlich, bevor eine weitere Kill-Switch-Aktivierung erfolgen kann. Der Reviewer muss jemand sein, der nicht der Aktivierende war:

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

Bis dieses Review abgeschlossen ist, ist eine nachfolgende Kill-Switch-Aktivierung blockiert. Das ist beabsichtigt — Sie koennen keine Aktivierungen stapeln, um Kontrolle zu umgehen.

Was im Ledger zu pruefen ist

Exportieren Sie nach der Uebung das Audit-Ledger und verifizieren Sie den vollstaendigen Trail:

olivares audit export --format json --since <drill-start-timestamp>

Das Ledger sollte in dieser Reihenfolge enthalten:

Aktivierungsereignis — der Admin, der Grund (“scheduled quarterly drill”), der Zeitstempel und das Sicherheitsniveau der aktivierenden Sitzung.
Genehmigungs-Stornierungen — jede ausstehende betroffene Genehmigung, die in derselben Transaktion wie die Aktivierung storniert wurde.
Ablehnungsereignisse — eins fuer jeden Aktionsversuch, der waehrend des Stopps abgelehnt wurde.
Wiederaktivierungsanfrage — die Genehmigungsanfrage auf critical-Stufe.
Zwei Genehmigungsentscheidungen — eine pro Genehmiger, jede mit Benennung der verschiedenen menschlichen Identitaet.
Wiederaktivierungsereignis — die Umgebung wiederhergestellt.
Post-Review-Ereignis — der unbeteiligte Reviewer, seine Notizen, der Abschlusszeitstempel.

Jeder Datensatz traegt die Ketten-Integritaetsfelder (seq, prev_hash, hash, sig). Ein fehlender oder nicht in der Reihenfolge befindlicher Eintrag bedeutet, dass das Ledger eine Luecke hat — untersuchen Sie, bevor Sie ihm bei einem echten Vorfall vertrauen.

Haeufigkeit

Fuehren Sie die Uebung quartalsweise durch. Der Kill Switch ist die letzte Verteidigungslinie; wenn er eine Luecke hat, wollen Sie sie in einem geplanten Fenster finden, nicht waehrend eines Vorfalls. Fuegen Sie die Uebung Ihrem Betriebskalender hinzu, zusammen mit anderen Kontinuitaetsuebungen (Backup-Wiederherstellung, Failover, Break-Glass-Aktivierung).

Wenn sich Ihre Umgebung wesentlich aendert — neue Aktionsnaehte verdrahtet, neue Mandanten bereitgestellt, Policy-Engine gewechselt — fuehren Sie eine ungeplante Uebung durch, um die neue Oberflaeche abzudecken.