Ein nützlicher Kill-Schalter für KI-Agenten ist ein koordinierter Eindämmungspfad. Es muss die aktive Arbeit stoppen, die nächste vorgeschlagene Aktion ablehnen, den Identitätspfad schließen, die Arbeitslast isolieren und eine Aufzeichnung des Geschehens aufbewahren. Eine einzelne Kontrolle deckt nur einen Teil dieser Aufgabe ab. In diesem Leitfaden werden die Architektur, die Fehlermodi und die Testnachweise beschrieben, die ein Bediener benötigen sollte. Es folgt der praktischen Lektion aus unserer exemplarischen Vorgehensweise zum Hugging Face-Einbruch durch autonome Agenten: Maschinengeschwindigkeitsaktionen erfordern eine Kontrolle auf dem Aktionspfad. Nur allgemeine technische Anleitung; Passen Sie das Design an Ihre Systeme und Ihr Bedrohungsmodell an.
Der Begriff „Kill Switch“ umfasst mehrere Bedienelemente
Identitätsplattformen verwenden den Begriff für Zugriffsbeschränkungen. Im Support-Artikel vom Juni 2026 von Okta heißt es, dass es sich beim aktuellen Kill-Switch um eine manuelle Aktion handelt und weist einen Administrator an, den Agentendatensatz, die verknüpfte Anwendung und den zugehörigen Autorisierungsserver zu deaktivieren. Seine Regulated-Environment-Release beschreibt die manuelle Deaktivierung als die Aktion, die neue Token-Anfragen und zukünftige Autorisierungen verhindert.
Diese Steuerelemente schließen einen Identitätspfad. Das Betriebssystem verfügt möglicherweise noch über einen Worker im Speicher, eine Warteschlange enthält möglicherweise noch geplante Jobs und ein nachgelagerter Dienst hat möglicherweise bereits eine Anforderung angenommen. Ein Stopp auf Systemebene verteilt daher einen Vorfallbefehl auf mehrere unabhängige Durchsetzungspunkte.
Behandeln Sie den Befehl als versionierte Statusänderung mit einer Vorfallkennung, einem Mandanten, einem Zielbereich, einem Grund, einem Akteur, einer Ausgabezeit und einer Frist. Jeder Durchsetzungspunkt bestätigt den gleichen Befehl und meldet sein Ergebnis. Der Vorfall bleibt unkontrolliert, solange eine erforderliche Bestätigung fehlt.
| Durchsetzungspunkt | Erforderliche Aktion | Anerkennungsbeweis |
|---|---|---|
| Ausführungskoordinator | Brechen Sie aktive Ausführungen ab und entfernen Sie Arbeiten in der Warteschlange für den ausgewählten Agenten, das Release, den Mandanten oder die Umgebung | Lauf-IDs, vorheriger Status, Endstatus, Abbruchzeit, nicht abgeschlossene Aktivität |
| Punkt zur Richtliniendurchsetzung | Verweigern Sie jeden neuen Toolaufruf und jede neue Ausgabeversion, die vom Vorfallumfang abgedeckt ist | Vorfallregelversion, Entscheidungseingang, erste abgelehnte Aktion, Ablehnungsanzahl |
| Identität und Geheimnisse | Deaktivieren Sie die Agentenidentität, widerrufen Sie Token, rotieren Sie offengelegte Anmeldeinformationen und verhindern Sie die Aktualisierung | Identitäts-ID, Token- und Schlüsselkennungen, Sperrergebnis, Ablauf des Restzugriffs |
| Arbeitsbelastung und Netzwerk | Entlassen Sie Mitarbeiter oder stellen Sie sie unter Quarantäne und wenden Sie die Richtlinie für den Austritt von Vorfällen an | Workload-IDs, Isolationsrichtlinie, Verbindungsinventar, Quarantänezeit |
| Nachgelagerte Systeme | Lehnen Sie die Identitäts- oder Idempotenzschlüssel des Vorfalls ab und halten Sie an, bis Nebenwirkungen vorliegen | Abgelehnte Anforderungs-IDs, ausstehende Jobs entfernt, begangene Nebenwirkungen aufgelistet |
| Beweisladen | Schließen Sie Befehle, Anerkennungen, Richtlinienentscheidungen und Lücken | Zeitleiste des Vorfalls, Integritätsergebnis, Exporteurstatus, benannter Beweiseigentümer |
Eine Netzwerkunterbrechung lässt mehrere Ausführungspfade offen
Die Netzwerkisolation ist ein Aktuator im Fan-Out. Es stoppt den Verkehr, der die von ihm kontrollierte Grenze überquert. Lokaler Code kann weiter ausgeführt werden, eine Datenbanktransaktion ist möglicherweise bereits festgeschrieben, ein externer Job kann nach Annahme der Anforderung fortgesetzt werden und ein Worker verfügt möglicherweise über Anmeldeinformationen, die auf einer anderen Route weiterhin gültig sind.
Die sichere Grenze liegt unmittelbar vor jeder Nebenwirkung. Der Agent schlägt einen Tool-Aufruf vor. Eine Durchsetzungsstelle überprüft den Vorfallstatus, die Identität, das Tool, die Argumente, die Richtlinie und das aktuelle Budget. Der Anruf wird erst nach dieser Entscheidung fortgesetzt. Ein Kill-Befehl aktualisiert den Vorfallstatus, der bei jeder späteren Überprüfung angezeigt wird.
Dieses Design deckt auch Agenten ab, die ein In-Process-Signal ignorieren. Die entscheidende Komponente läuft außerhalb des Agentenprozesses und besitzt Zugriff auf das Tool. Die Workload-Beendigung verkürzt dann die Zeit bis zur Eindämmung, während der externe Durchsetzungspunkt neue Auswirkungen verhindert.
- Lokale Ausführung: Prozess, Container, virtuelle Maschine oder Sandbox beenden oder unter Quarantäne stellen
- Ausführung in der Warteschlange: Geplante Nachrichten stornieren und von Arbeitern gehaltene Leases ungültig machen
- Berechtigungsbasierte Ausführung: Widerrufen oder rotieren Sie alle vom betroffenen Bereich aus erreichbaren Anmeldeinformationen
- Akzeptierte Downstream-Arbeit: Ausstehende Jobs über die Downstream-API abbrechen und die bereits festgeschriebenen Jobs auflisten
- Von Menschen genehmigte Arbeit: Ausstehende Entscheidungsanfragen schließen und verhindern, dass eine verspätete Genehmigung den Lauf fortsetzt
Die Stoppsequenz
Die folgende Reihenfolge minimiert die Lücke zwischen der Bedieneraktion und der letzten möglichen Nebenwirkung. Der erste dauerhafte Schreibvorgang legt die Epoche des Vorfalls fest. Jeder Richtliniendurchsetzungspunkt liest diese Epoche, bevor er einen kontrollierten Aufruf ausführt.
| Bestellen | Befehl | Abschlussbedingung |
|---|---|---|
| 1 | Erstellen Sie den Incident-Befehl und legen Sie den betroffenen Bereich auf „Deny“ fest | Die Epoche des dauerhaften Vorfalls ist für jede Durchsetzungsstelle lesbar |
| 2 | Aktive Ausführungen signalisieren und in der Warteschlange befindliche Arbeiten abbrechen | Jeder Lauf ist terminal oder wird explizit als noch in Ausführung aufgeführt aufgeführt |
| 3 | Deaktivieren Sie Identitäten, widerrufen Sie Token und rotieren Sie offengelegte Geheimnisse | Die erneute Autorisierung schlägt fehl und die Restlebensdauer des Tokens wird aufgezeichnet |
| 4 | Quarantäne-Workloads und Einschränkung des ausgehenden Datenverkehrs | Die betroffene Rechenleistung hat keine nicht genehmigte Route zu einem Tool oder Datenspeicher |
| 5 | Brechen Sie ausstehende Folgeaufträge ab und starten Sie Ausgleichsmaßnahmen | Jede akzeptierte Anfrage hat einen abgeschlossenen, ausstehenden, fehlgeschlagenen oder kompensierenden Status |
| 6 | Versiegeln Sie das Eindämmungsprotokoll und legen Sie fehlende Bestätigungen offen | Der Eigentümer des Vorfalls kann die endgültige Nebenwirkung, die verbleibende Exposition und Beweislücken sehen |
So verhält sich der KLA-Stopppfad
Die KLA-Steuerungsebene verwendet separate KLA-Runtime- und KLA-Policy-Engine-Steuerelemente. Die Stornierungs-API löst eine mandantenbezogene Ausführung im Status PENDING, RUNNING oder GATED auf, sendet ein kill-Signal an ihren Workflow und zeichnet die Ausführung als CANCELLED auf. Der Workflow prüft das Signal, bevor ein anderer Knoten gestartet wird. Ein Lauf, der auf eine Entscheidungsanforderung wartet, beobachtet ebenfalls den Abbruch und wird beendet, ohne die vorgeschlagene Aktion fortzusetzen.
Wenn es aktiviert ist, wertet das KLA Policy Engine-Governance-Gateway vorgeschlagene Toolaufrufe aus und erzwingt allow, warn, require_approval oder block. Wenn die Richtlinienauswertung fehlschlägt, verwendet das Gateway in der Produktion standardmäßig block und in anderen Umgebungen require_approval. Das Gateway umfasst einen separaten Bereinigungsvorgang für zurückgehaltene Tool-Aufrufe, der stornierte Hauptbucheinträge aufzeichnet und Stornierungsbelege versiegelt. Die Ausführungsstornierungsroute ruft diesen Vorgang heute nicht auf, daher müssen Betreiber zurückgehaltene Einträge während der Eindämmung separat überprüfen.
Eine Aktivität, die ihr Durchsetzungstor bereits überschritten hat, kann beendet werden, bevor der Workflow das Signal erkennt. Downstream-Idempotenz, Workload-Beendigung und kompensierende Aktionen decken dieses Intervall ab. Im Vorfallprotokoll muss die letzte Nebenwirkung angegeben werden, die aufgetreten ist, nachdem der Bediener den Befehl erteilt hat.
Diese Verhaltensweisen werden in der KLA-Entwicklungsumgebung überprüft, der einzigen Umgebung, die KLA derzeit ausführt.
Der Leitfaden zur verantwortungsvollen Autonomie erklärt, wo menschliche Entscheidungen im normalen Betrieb hingehören. Während der Eindämmung hat der Umfang des Vorfalls Vorrang und eine verspätete Genehmigung kann einen abgebrochenen Lauf nicht erneut öffnen.
Entwerfen Sie jeden Degradationsmodus
Der Kill-Pfad ist am wertvollsten, wenn ein Teil des Systems ausfällt. Jeder Aktor benötigt einen lokalen sicheren Zustand, eine Frist und einen sichtbaren Bestätigungsstatus.
| Misserfolg | Erforderliches Verhalten | Beweise, die es aufzubewahren gilt |
|---|---|---|
| Richtliniendienst nicht erreichbar | Wenden Sie die lokale Fail-Closed-Entscheidung an und behalten Sie die Epoche des Vorfalls im Durchsetzungscache | Ursachencode, Cache-Version, verweigerte Aktion, Wiederherstellungszeit |
| Workflow-Signal verzögert | Lehnen Sie neue Nebenwirkungen am Durchsetzungspunkt ab und stellen Sie die Arbeitslast unter Quarantäne | Signalversuche, Workflow-Status, Quarantänebestätigung |
| Identitätsanbieter nicht verfügbar | Wenden Sie Downstream-Verweigerungsregeln an, isolieren Sie die Arbeitslast und verfallen Sie kurzlebige Anmeldeinformationen | Anbieterfehler, Restlebensdauer der Anmeldeinformationen, Systeme unter lokaler Ablehnung |
| Beweisexporter nicht verfügbar | Halten Sie die Quelldatensätze dauerhaft und kennzeichnen Sie das Bundle als ausstehend | Speicherorte der Quelldatensätze, Integritätsstatus, Wiederholungseigentümer |
| Ein bereits begangener Nebeneffekt | Öffnen Sie das systemspezifische Entschädigungs- oder Wiederherstellungsverfahren | Ursprüngliche Anfrage, bestätigtes Ergebnis, Vergütungseigentümer und Ergebnis |
| Ein Aktor quittiert nie | Halten Sie den Vorfall unter Kontrolle und eskalieren Sie ihn an den benannten Systembesitzer | Fehlender Aktuator, verstrichene Zeit, Eskalationsverlauf |
Testen Sie den Schalter als Steuerungssystem
Eine Dashboard-Antwort bestätigt den Eingang der Betreiberanfrage. Die Akzeptanz erfordert Beweise von jedem Durchsetzungspunkt und eine beobachtete Obergrenze für die endgültige Nebenwirkung.
NIST AI RMF Manage 2.4 und Manage 4 fordert Mechanismen zum Abschalten oder Deaktivieren von KI-Systemen, deren Ergebnisse von der beabsichtigten Verwendung abweichen, sowie dokumentierte Reaktion, Wiederherstellung und Kommunikation bei Vorfällen. Das NIST Generative AI Profile fügt benannte Eigentümerschaft, Probe, retrospektive Verbesserung und Ausrichtung an das Melderecht für KI-Vorfallpläne Dritter hinzu.
- Aktiver Lauf: Geben Sie den Befehl aus, während zwischen Werkzeugaufrufen ein mehrstufiger Lauf stattfindet, und stellen Sie sicher, dass der nächste Aufruf abgelehnt wird
- Genehmigung warten: Geben Sie es aus, während eine Entscheidungsanforderung geöffnet ist, und stellen Sie sicher, dass eine spätere Genehmigung den Lauf nicht fortsetzen kann
- Richtlinienausfall: Trennen Sie den Richtliniendienst und stellen Sie sicher, dass keine vorgeschlagene Aktion zu allow aufgelöst wird
- Veraltete Anmeldeinformationen: Versuchen Sie den Zugriff mit jeder Token-Klasse, die vor dem Befehl ausgegeben wurde, und zeichnen Sie die verbleibende Lebensdauer auf
- Arbeiten in der Warteschlange: Setzen Sie geplante Jobs und bestätigen Sie, dass jeder einzelne einen End- oder Ausgleichsstatus erreicht
- Nicht kooperativer Prozess: Ignorieren Sie das In-Process-Signal und überprüfen Sie, ob externe Durchsetzung und Workload-Isolation es weiterhin enthalten
- Beweisfehler: Stoppen Sie den Exporter und bestätigen Sie, dass der Quelldatensatz mit einem sichtbaren Wiederholungseigentümer dauerhaft bleibt
- Wiederherstellung: Stellen Sie eine Version unter einer neuen Identität wieder her und überprüfen Sie, ob die Vorfallverweigerung auf jeder betroffenen älteren Version bestehen bleibt
Verbinden Sie den Switch mit dem Vorfall-Playbook
Der Kill-Schalter stellt die Eindämmung her. Der Betreuer muss den Vorfall noch eingrenzen, flüchtige Aufzeichnungen aufbewahren, eine bekanntermaßen funktionierende Version wiederherstellen, begangene Auswirkungen kompensieren und entscheiden, welche Benachrichtigungen gelten.
Verwenden Sie für diese Sequenz das AI Agent Incident Response Playbook. Füttere seine Schwellenwerte aus dem Post-Market-Überwachungsplan, sodass dieselben Signale, die den Vorfall eröffnen, einen einstudierten Stopppfad auslösen können.
Häufig gestellte Fragen
Was ist ein KI-Agent-Kill-Switch?
Ein KI-Agent-Kill-Switch ist ein koordinierter Vorfallbefehl, der aktive Ausführungen abbricht, neue Aktionen am Durchsetzungspunkt verweigert, Anmeldeinformationen widerruft, betroffene Workloads isoliert, ausstehende nachgelagerte Arbeiten abbricht und die abgeschlossenen Kontrollen aufzeichnet. Der Bereich kann auf eine Ausführung, einen Agenten, ein Release, einen Mandanten oder eine Umgebung abzielen.
Kann der Token-Widerruf einen betrügerischen KI-Agenten stoppen?
Durch den Token-Widerruf werden die von diesen Token verwalteten Autorisierungspfade geschlossen. Laufzeitabbruch, Workload-Isolation, Warteschlangenabbruch, Downstream-Deny-Regeln und kompensierende Aktionen decken Arbeiten ab, die bereits ausgeführt oder bereits akzeptiert werden.
Wo soll der Kill-Switch-Check laufen?
Führen Sie die entscheidende Prüfung außerhalb des Wirkstoffprozesses und unmittelbar vor jeder Nebenwirkung durch. Die Prüfung sollte einen dauerhaften Vorfallstatus lesen und Anrufe innerhalb des betroffenen Bereichs ablehnen, einschließlich Anrufen, die von einem Prozess vorgeschlagen werden, der sein eigenes Abbruchsignal ignoriert.
Wie testen wir einen Kill-Schalter für KI-Agenten?
Testen Sie aktive Ausführungen, Wartezeiten bei Genehmigungen, Arbeiten in der Warteschlange, veraltete Anmeldeinformationen, einen Richtlinienausfall, einen nicht kooperativen Prozess, einen Fehler beim Beweisexport und eine Wiederherstellung unter einem bekanntermaßen funktionierenden Release. Messen Sie die Zeit und Anzahl der Nebenwirkungen zwischen dem Befehl und der endgültigen festgeschriebenen Aktion.
Welche Beweise sollte der Wechsel liefern?
Behalten Sie den Vorfallbefehl, den Akteur, den Umfang, die Ausgabezeit, die Bestätigungen von jedem Aktor, die verweigerten Aktionen, Token- und Schlüsseländerungen, das Ergebnis der Workload-Isolation, den endgültigen begangenen Nebeneffekt, die ausstehende Entschädigung und den Integritätsstatus des Beweisdatensatzes bei.
Die wichtigsten Erkenntnisse
Ein glaubwürdiger Kill-Schalter für KI-Agenten ist ein kleines Steuerungssystem mit mehreren unabhängigen Aktuatoren. Fügen Sie dem Aktionspfad einen dauerhaften Ablehnungsstatus hinzu, brechen Sie den Workflow ab, schließen Sie den Identitätszugriff, isolieren Sie die Datenverarbeitung, gleichen Sie nachgelagerte Arbeiten ab und lassen Sie den Vorfall offen, bis alle erforderlichen Kontrollen ihn bestätigen. Die Probe verwandelt diese Architektur in eine gemessene Eindämmungszeit und einen Rekord, den ein Vorfalleigentümer verteidigen kann.