Kill Switch für KI-Agenten: wie man Aktionen ohne Release im Notfall stoppt

Idee in 30 Sekunden

Kill switch ist eine Notfallkontrolle in der Runtime, mit der du neue Agent-Aktionen während eines Incidents sofort stoppen kannst, ohne Release und ohne Prompt-Änderung.

Wann das nötig ist:
wenn ein Agent Write-Aktionen ausführen kann, mit externen APIs arbeitet und ein Fehler bereits zu einem Production-Incident eskaliert.

Problem

Wenn ein Agent schädliche Aktionen startet, bleibt meist keine Zeit für "Prompt nachjustieren und Release machen". Während das Team die Ursache analysiert, kann der Agent dieselben Aktionen weiter ausführen. Und jede Minute Verzögerung bedeutet neue Seiteneffekte (Zustandsänderungen) in Production.

Typisches Bild:

• doppelte E-Mails oder Nachrichten
• massenhafte Create/Update-Operationen
• überflüssige Aufrufe externer APIs

Analogie: Das ist wie ein Not-Aus-Knopf an einer Produktionslinie. Bei einer Störung musst du zuerst die Bewegung stoppen und erst danach die Ursache analysieren.

Wenn der Kill Switch nur in der UI wirkt, ist das keine Notfallkontrolle. Der echte Stop muss in der Runtime-Loop und im Tool Gateway passieren.

Lösung

Die Lösung ist ein zentraler Kill-Switch-Policy-Layer, der nach dem Bilden der nächsten Agent-Aktion geprüft wird, aber vor der Ausführung. Die Policy gibt allow oder stop mit explizitem Grund zurück: killed_global, killed_tenant, writes_disabled, tool_disabled.

Basismodell:

• global kill — stoppt im Notfall alle
• tenant kill — stoppt einen konkreten Kunden
• writes disabled — erlaubt read, blockiert write
• tool disabled — blockiert gezielt ein konkretes Tool

Das ist eine eigenständige Notfall-Kontrollschicht, nicht Teil von Prompt oder UI-Logik.

Kill switch ≠ vollständiges Governance-System

Kill switch und Governance lösen unterschiedliche Aufgaben:

• Kill switch stoppt den Incident "hier und jetzt"
• Governance steuert Agent-Verhalten dauerhaft (RBAC, Limits, Budgets, Approval)

Eins ohne das andere funktioniert nicht gut:

• ohne kill switch ist ein Incident schwer sofort zu stoppen
• ohne Governance passieren Incidents zu häufig

Kill-switch-Kontur

Diese Prüfungen arbeiten als Notfall-Kontur in der Runtime zusammen.

Wie das in der Architektur aussieht

Der Kill-Switch-Policy-Layer steht in der Runtime-Loop zwischen Planung und Ausführung der nächsten Agent-Aktion. Jede Entscheidung (allow oder stop) wird im Audit Log festgehalten.

Jeder Schritt läuft vor der Ausführung durch diesen Flow: Runtime führt Aktionen nicht direkt aus, sondern übergibt die Entscheidung zuerst an den Policy Layer.

Flow kurz zusammengefasst:

• Runtime bildet die nächste Aktion
• Policy liest global/tenant flags + writes/tool rules
• allow -> die nächste Agent-Aktion wird ausgeführt
• stop -> Run stoppt mit explizitem reason (killed_global, killed_tenant, writes_disabled, tool_disabled)
• die Entscheidung wird ins Audit Log geschrieben

Beispiel

Ein Support-Agent hat wegen eines fehlerhaften Szenarios begonnen, email.send massenhaft zu senden. Ein Operator aktiviert writes_disabled für einen konkreten Tenant.

Ergebnis:

• neue Write-Aktionen werden sofort blockiert
• Read-Aktionen können verfügbar bleiben
• in den Logs stehen who/when/why für jede Blockierung

Kill switch stoppt den Incident direkt in der Runtime-Loop und wartet nicht auf ein neues Release.

Im Code sieht das so aus

Das vereinfachte Schema oben zeigt den Haupt-Flow. In der Praxis wird der Kill-State zentral gelesen und für Sekunden gecacht. Kritisch: kill-check muss O(1) sein und mit kurzem Cache (1-2 Sekunden) laufen, sonst reagiert der Notfallstop zu spät. In Production wird derselbe kill-check meist zusätzlich im Tool Gateway ausgeführt, damit kein Aufruf die Runtime-Kontrolle umgehen kann.

Beispiel für Kill-Switch-Konfiguration:

kill_switch:
  global_flag: agent_kill_global
  tenant_flag_prefix: "agent_kill_tenant:"
  writes_disabled_default: false
  disabled_tools_key: agent_disabled_tools
  cache_ttl_seconds: 2

while True:
    action = planner.next(state)
    action_key = make_action_key(action.name, action.args)  # stabiler Schlüssel für dedupe/audit

    kill_state = kill_store.read(tenant_id=state.tenant_id)
    decision = kill_policy.check(kill_state, action)

    if decision.outcome == "stop":
        audit.log(
            run_id,
            decision=decision.outcome,
            reason=decision.reason,
            scope=decision.scope,
            action=action.name,
            action_key=action_key,
            actor=kill_state.last_updated_by,
        )
        return stop(decision.reason)

    result = tool.execute(action.args)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        scope=decision.scope,
        action=action.name,
        action_key=action_key,
        result=result.status,
    )

    if result.final:
        return result

Kill switch stoppt neue Aktionen. Für in-flight Aktionen ist meist ein separater Best-Effort-Cancel-Mechanismus nötig.

Wie das während der Ausführung aussieht

Szenario 1: global stop

1. Operator aktiviert global_kill=true.
2. Runtime bildet die nächste Aktion und liest den Kill-State.
3. Policy gibt stop (reason=killed_global) zurück.
4. Neue Aktionen werden nicht ausgeführt.
5. In den Logs stehen scope=global und actor.

Szenario 2: tenant stop

1. Für Tenant t_42 wird tenant_kill=true aktiviert.
2. Runs dieses Tenants erhalten stop (reason=killed_tenant).
3. Andere Tenants laufen weiter.
4. Incident ist ohne globalen Stopp lokalisiert.

Szenario 3: writes disabled

1. writes_disabled=true wird aktiviert.
2. Read-Aktion läuft mit allow durch.
3. Write-Aktion erhält stop (reason=writes_disabled).
4. System wechselt in read-only degrade mode.

Typische Fehler

• kill switch nur in UI, aber nicht in runtime/tool gateway
• nur ein globaler Stop ohne per-tenant-Modus
• fehlender writes-disabled-Modus
• langer Cache-TTL (Minuten statt Sekunden)
• fehlender Audit Trail für Operator-Aktionen
• fehlendes getestetes Incident-Runbook

Ergebnis: Das Team hat einen "Button", aber keine echte Notfallsteuerung.

Selbstcheck

Schneller Kill-Switch-Check vor dem Production-Start:

FAQ

Q: Was sollte zuerst aktiviert werden: global stop oder writes disabled?
A: Starte mit writes_disabled, wenn der Incident in Write-Aktionen liegt. Nutze global_kill, wenn ein breites Ausfallrisiko besteht und ein sofortiger Vollstopp nötig ist.

Q: Wo genau sollte kill switch geprüft werden?
A: Mindestens an zwei Stellen: in der Runtime-Loop vor der nächsten Aktion und im Tool Gateway vor der Tool-Ausführung.

Q: Kann Kill-State gecacht werden?
A: Ja, aber kurz (Sekunden). Im Incident macht ein minutenlanger Cache den Kill Switch fast nutzlos.

Q: Wie implementiert man Kill-Flags technisch?
A: Üblicherweise als globale und tenant-scoped Flags in Redis/Config-Store, die der Policy Layer vor jeder Aktion liest.

Q: Bricht kill switch bereits laufende Aktionen ab?
A: Nicht immer. Er blockiert zuverlässig neue Aktionen. Für in-flight Tasks braucht es einen separaten Best-Effort-Cancel-Mechanismus.

Q: Kann kill switch RBAC und Budgets ersetzen?
A: Nein. Kill switch ist ein Notfall-Stop-Mechanismus. RBAC, Limits und Budgets sind für den laufenden Betrieb nötig.

Wo Kill Switch im Gesamtsystem liegt

Kill switch ist die Notfall-Ebene von Agent Governance. Zusammen mit RBAC, Budgets, Approval und Audit bildet er ein vollständiges Production-Kontrollsystem.

Verwandte Seiten

Als Nächstes zum Thema:

• Agent Governance Überblick — Gesamtmodell für Agent-Kontrolle in Production.
• Zugriffskontrolle (RBAC) — wie begrenzt wird, wer was ausführen darf.
• Budget Controls — wie Ausgaben und runaway runs begrenzt werden.
• Step limits — wie Loops auf Runtime-Loop-Ebene gestoppt werden.
• Human approval — wo manuelle Bestätigung vor riskanten Aktionen nötig ist.