Ein brauchbarer Kill Switch für KI-Agenten ist ein koordinierter Eindämmungspfad. Er muss laufende Arbeit stoppen, die nächste vorgeschlagene Aktion ablehnen, den Identitätspfad schließen, den Workload isolieren und festhalten, was geschehen ist. Eine einzelne Kontrolle deckt nur einen Teil dieser Aufgabe ab. Dieser Leitfaden beschreibt die Architektur, die Fehlermodi und die Testnachweise, die ein Betreiber verlangen sollte. Er folgt der praktischen Lehre aus unserer Analyse des Eindringens eines autonomen Agenten bei Hugging Face: Handeln in Maschinengeschwindigkeit braucht eine Kontrolle auf dem Aktionspfad. Nur allgemeine technische Hinweise; passen Sie das Design an Ihre Systeme und Ihr Bedrohungsmodell an.
Der Begriff „Kill Switch“ umfasst mehrere Kontrollen
Identitätsplattformen verwenden den Begriff für die Eindämmung von Zugriffen. Oktas Support-Artikel vom Juni 2026 beschreibt den aktuellen Kill Switch als manuelle Aktion und weist Administratoren an, den Agentendatensatz, die verknüpfte Anwendung und den zugehörigen Autorisierungsserver zu deaktivieren. Die Mitteilung zu regulierten Umgebungen beschreibt die manuelle Deaktivierung als die Aktion, die neue Token-Anfragen und künftige Autorisierungen verhindert.
Diese Kontrollen schließen einen Identitätspfad. Im Betriebssystem kann noch ein Worker im Speicher laufen, eine Warteschlange kann noch geplante Jobs enthalten, und ein nachgelagerter Dienst kann eine Anfrage bereits angenommen haben. Ein Stopp auf Systemebene verteilt deshalb einen Vorfallbefehl auf mehrere unabhängige Durchsetzungspunkte.
Behandeln Sie den Befehl als versionierte Zustandsänderung mit Vorfallkennung, Mandant, Zielbereich, Grund, Akteur, Ausstellungszeit und Frist. Jeder Durchsetzungspunkt bestätigt denselben Befehl und meldet sein Ergebnis. Solange eine erforderliche Bestätigung fehlt, gilt der Vorfall als nicht eingedämmt.
| Durchsetzungspunkt | Erforderliche Aktion | Nachweis der Bestätigung |
|---|---|---|
| Ausführungs-Orchestrator | Aktive Ausführungen abbrechen und eingereihte Arbeit für den gewählten Agenten, das Release, den Mandanten oder die Umgebung entfernen | Ausführungs-IDs, vorheriger Status, Endstatus, Abbruchzeit, nicht abgeschlossene Aktivität |
| Policy-Durchsetzungspunkt | Jeden neuen Tool-Aufruf und jede Ausgabefreigabe im Vorfallbereich ablehnen | Version der Vorfallregel, Entscheidungsbeleg, erste abgelehnte Aktion, Anzahl der Ablehnungen |
| Identität und Secrets | Agentenidentität deaktivieren, Tokens widerrufen, offengelegte Zugangsdaten rotieren und Refresh verhindern | Identitäts-ID, Token- und Schlüsselkennungen, Ergebnis des Widerrufs, Ablauf des Restzugriffs |
| Workload und Netzwerk | Worker beenden oder in Quarantäne nehmen und die Egress-Policy für den Vorfall anwenden | Workload-IDs, Isolations-Policy, Verbindungsinventar, Quarantänezeit |
| Nachgelagerte Systeme | Die Vorfallidentität oder Idempotenzschlüssel zurückweisen und ausstehende Seitenwirkungen anhalten | IDs zurückgewiesener Anfragen, entfernte ausstehende Jobs, Liste festgeschriebener Seitenwirkungen |
| Nachweisspeicher | Befehl, Bestätigungen, Policy-Entscheidungen und Lücken versiegeln | Vorfall-Zeitachse, Integritätsergebnis, Exporter-Status, benannter Verantwortlicher für die Nachweise |
Eine Netzwerktrennung lässt mehrere Ausführungspfade offen
Die Netzwerkisolierung ist ein Aktor unter mehreren. Sie stoppt Verkehr, der die von ihr kontrollierte Grenze überquert. Lokaler Code kann weiterlaufen, eine Datenbanktransaktion kann bereits festgeschrieben sein, ein externer Job kann nach Annahme der Anfrage weiterlaufen, und ein Worker kann Zugangsdaten halten, die auf einem anderen Weg gültig bleiben.
Die sichere Grenze liegt unmittelbar vor jeder Seitenwirkung. Der Agent schlägt einen Tool-Aufruf vor. Ein Durchsetzungspunkt prüft Vorfallstatus, Identität, Tool, Argumente, Policy und aktuelles Budget. Der Aufruf läuft erst nach dieser Entscheidung weiter. Ein Kill-Befehl aktualisiert den Vorfallstatus, den jede spätere Prüfung liest.
Dieses Design erfasst auch Agenten, die ein prozessinternes Signal ignorieren. Die entscheidende Komponente läuft außerhalb des Agentenprozesses und kontrolliert den Zugriff auf das Tool. Das Beenden des Workloads verkürzt dann die Zeit bis zur Eindämmung, während der externe Durchsetzungspunkt neue Wirkungen verhindert.
- Lokale Ausführung: Prozess, Container, virtuelle Maschine oder Sandbox beenden oder in Quarantäne nehmen
- Eingereihte Ausführung: geplante Nachrichten stornieren und Leases der Worker ungültig machen
- Ausführung mit Zugangsdaten: alle aus dem betroffenen Bereich erreichbaren Zugangsdaten widerrufen oder rotieren
- Angenommene nachgelagerte Arbeit: ausstehende Jobs über die API des nachgelagerten Systems abbrechen und die bereits festgeschriebenen Jobs auflisten
- Von Menschen genehmigte Arbeit: offene Decision Requests schließen und verhindern, dass eine späte Genehmigung die Ausführung fortsetzt
Die Stoppsequenz
Die folgende Reihenfolge verkürzt die Lücke zwischen der Aktion des Betreibers und der letzten möglichen Seitenwirkung. Der erste dauerhafte Schreibvorgang legt die Vorfall-Epoche fest. Jeder Policy-Durchsetzungspunkt liest diese Epoche, bevor er einen kontrollierten Aufruf ausführt.
| Reihenfolge | Befehl | Abschlussbedingung |
|---|---|---|
| 1 | Vorfallbefehl anlegen und den betroffenen Bereich auf Ablehnung setzen | Die dauerhafte Vorfall-Epoche ist für jeden Durchsetzungspunkt lesbar |
| 2 | Aktive Ausführungen signalisieren und eingereihte Arbeit abbrechen | Jede Ausführung ist beendet oder ausdrücklich als noch laufend aufgeführt |
| 3 | Identitäten deaktivieren, Tokens widerrufen und offengelegte Secrets rotieren | Neue Autorisierungen schlagen fehl und die Restlaufzeit der Tokens ist erfasst |
| 4 | Workloads in Quarantäne nehmen und Egress einschränken | Die betroffene Rechenumgebung hat keinen nicht genehmigten Weg zu einem Tool oder Datenspeicher |
| 5 | Ausstehende nachgelagerte Jobs abbrechen und Ausgleichsmaßnahmen starten | Jede angenommene Anfrage hat den Status abgeschlossen, ausstehend, fehlgeschlagen oder ausgeglichen |
| 6 | Eindämmungsdatensatz versiegeln und fehlende Bestätigungen sichtbar machen | Der Vorfallverantwortliche sieht die letzte Seitenwirkung, die verbleibende Exposition und Nachweislücken |
So verhält sich der KLA-Stopppfad
KLA Control Plane nutzt getrennte Kontrollen in KLA Runtime und KLA Policy Engine. Eine Person mit Berechtigung zur Vorfallverwaltung kann eine laufende Ausführung aus deren Vorfall heraus einfrieren. Das Einfrieren sendet ein kill-Signal an den Workflow der Ausführung, der die Ausführung als CANCELLED erfasst. Der Workflow prüft das Signal, bevor er einen weiteren Knoten startet. Eine Ausführung, die auf einen Decision Request wartet, erkennt das Signal, storniert die offene Anfrage und endet, ohne die vorgeschlagene Aktion fortzusetzen. Gehört zur Ausführung eine offene Agentenaktion, storniert der Worker diese Aktion, und KLA versiegelt dafür einen Stornierungsbeleg.
Die allgemeine Abbruchroute für Ausführungen schließt nur verwaiste Datensätze, deren Workflow nachweislich nicht mehr existiert, und kann keine intakte Ausführung stoppen. Übungen und Runbooks sollten das Einfrieren aus dem Vorfall nutzen. Das Einfrieren eines Agenten aus einem Vorfall pausiert seine Stufen in Processes: Jeder Agentenschritt prüft vor dem Start, ob er eingefroren ist, und übergibt die Arbeit dann an eine Person oder stoppt die Ausführung.
Agenten, die über den KLA-Eingang für Agentenaktionen handeln, arbeiten unter einem Agentenmandat. Der Widerruf des Mandats blockiert daran gebundene offene Vorschläge mit dem Grundcode mandate_revoked, storniert deren offene Decision Requests und lehnt die nächste Aktion ab, die der Agent vorschlägt. Eine bereits zugelassene Aktion kann noch abgeschlossen werden. Die Agentenpause greift auf diesem Pfad nicht; widerrufen Sie deshalb das Mandat, um einen solchen Agenten zu stoppen.
Ist das Governance-Gateway der KLA Policy Engine aktiviert, bewertet es vorgeschlagene Tool-Aufrufe und setzt allow, warn, require_approval oder block durch. Schlägt die Policy-Auswertung fehl, fällt das Gateway in der Produktion auf block und in anderen Umgebungen auf require_approval zurück, niemals auf allow. Eine Genehmigung ist an einen Hash der Tool-Argumente gebunden; geänderte Argumente werden blockiert. Die Bereinigungsoperation des Gateways für zurückgehaltene Tool-Aufrufe erfasst stornierte Ledger-Einträge und versiegelt Stornierungsbelege. KLA ruft sie auf, wenn eine offene Agentenaktion storniert wird; prüfen Sie andere zurückgehaltene Einträge während der Eindämmung deshalb gesondert.
Eine Aktivität, die ihr Durchsetzungstor bereits passiert hat, kann abschließen, bevor der Workflow das Signal erkennt. Idempotenz in nachgelagerten Systemen, das Beenden von Workloads und Ausgleichsmaßnahmen decken dieses Intervall ab. Der Vorfalldatensatz muss die letzte Seitenwirkung nennen, die nach dem Befehl des Betreibers festgeschrieben wurde.
Dieser Abschnitt beschreibt den aktuellen KLA-Quellcode.
Der Leitfaden zu Accountable Autonomy erklärt, wo menschliche Entscheidungen im normalen Betrieb hingehören. Während der Eindämmung hat der Vorfallbereich Vorrang, und eine späte Genehmigung kann eine abgebrochene Ausführung nicht wieder öffnen.
Jeden Degradationsmodus entwerfen
Der Stopppfad ist am wertvollsten, während ein Teil des Systems ausfällt. Jeder Aktor braucht einen lokalen sicheren Zustand, eine Frist und einen sichtbaren Bestätigungsstatus.
| Ausfall | Erforderliches Verhalten | Aufzubewahrender Nachweis |
|---|---|---|
| Policy-Dienst nicht erreichbar | Die lokale Fail-closed-Entscheidung anwenden und die Vorfall-Epoche im Cache des Durchsetzungspunkts halten | Grundcode, Cache-Version, abgelehnte Aktion, Wiederherstellungszeit |
| Workflow-Signal verzögert | Neue Seitenwirkungen am Durchsetzungspunkt ablehnen und den Workload in Quarantäne nehmen | Signalversuche, Workflow-Status, Bestätigung der Quarantäne |
| Identitätsanbieter nicht verfügbar | Ablehnungsregeln in nachgelagerten Systemen anwenden, den Workload isolieren und kurzlebige Zugangsdaten auslaufen lassen | Fehler des Anbieters, Restlaufzeit der Zugangsdaten, Systeme unter lokaler Ablehnung |
| Nachweis-Exporter nicht verfügbar | Die Quelldatensätze dauerhaft halten und das Paket als ausstehend kennzeichnen | Speicherorte der Quelldatensätze, Integritätsstatus, Verantwortlicher für die Wiederholung |
| Eine Seitenwirkung ist bereits festgeschrieben | Das systemspezifische Ausgleichs- oder Wiederherstellungsverfahren eröffnen | Ursprüngliche Anfrage, festgeschriebenes Ergebnis, Verantwortlicher und Ergebnis des Ausgleichs |
| Ein Aktor bestätigt nie | Den Vorfall als nicht eingedämmt führen und an den benannten Systemverantwortlichen eskalieren | Fehlender Aktor, verstrichene Zeit, Eskalationsverlauf |
Den Schalter als Steuerungssystem testen
Eine Antwort im Dashboard bestätigt nur den Eingang der Anfrage des Betreibers. Die Abnahme erfordert Nachweise von jedem Durchsetzungspunkt und eine beobachtete Obergrenze für die letzte Seitenwirkung.
NIST AI RMF Manage 2.4 und Manage 4 verlangen Mechanismen, um KI-Systeme abzukoppeln oder zu deaktivieren, deren Ergebnisse von der vorgesehenen Verwendung abweichen, sowie dokumentierte Reaktion, Wiederherstellung und Kommunikation bei Vorfällen. Das NIST Generative AI Profile ergänzt für Vorfallpläne zu KI von Dritten benannte Verantwortliche, Übungen, Verbesserung im Rückblick und die Abstimmung mit Meldepflichten.
- Aktive Ausführung: den Befehl erteilen, während eine mehrstufige Ausführung zwischen zwei Tool-Aufrufen steht, und prüfen, dass der nächste Aufruf abgelehnt wird
- Warten auf Genehmigung: den Befehl erteilen, während ein Decision Request offen ist, und prüfen, dass eine spätere Genehmigung die Ausführung nicht fortsetzt
- Policy-Ausfall: den Policy-Dienst trennen und prüfen, dass keine vorgeschlagene Aktion zu allow aufgelöst wird
- Veraltete Zugangsdaten: mit jeder vor dem Befehl ausgestellten Token-Art einen Zugriff versuchen und die Restlaufzeit erfassen
- Eingereihte Arbeit: geplante Jobs anlegen und bestätigen, dass jeder einen End- oder Ausgleichsstatus erreicht
- Unkooperativer Prozess: das prozessinterne Signal ignorieren und prüfen, dass externe Durchsetzung und Workload-Isolierung ihn trotzdem eindämmen
- Ausfall der Nachweise: den Exporter stoppen und bestätigen, dass der Quelldatensatz dauerhaft bleibt und ein Verantwortlicher für die Wiederholung sichtbar ist
- Wiederherstellung: ein Release unter einer neuen Identität wiederherstellen und prüfen, dass die Ablehnung aus dem Vorfall für jede betroffene ältere Version bestehen bleibt
Eine Kill-Switch-Übung durchführen
Eine Übung macht aus dem Stopppfad gemessene Zeiten. Führen Sie sie in einer Testumgebung mit einem synthetischen Agenten durch, der dieselben Arten von Rechten hält wie der Produktivagent: eine laufende Ausführung, einen offenen Decision Request, einen zurückgehaltenen Tool-Aufruf und gültige Zugangsdaten. Benennen Sie eine Übungsleitung, eine beobachtende Person, die die Zeit nimmt, und die Verantwortlichen jedes nachgelagerten Systems.
Ein Kill Switch stoppt künftige Aktionen. Eine abgewickelte Zahlung, eine zugestellte E-Mail oder ein vor dem Befehl überschriebener Datensatz bleibt bestehen. Die Übung findet diese Wirkungen und übergibt jede an das Korrekturverfahren des Systems, dem sie gehört.
Warum das wichtig ist, haben wir in unseren eigenen Dogfood-Tests gelernt. Eine Person aus dem Vorfallteam führte „Agent einfrieren“ durch den vollständigen Eindämmungsablauf, mit Grundcode, Erläuterung und Prüfung von Auswirkungsradius und Umkehrbarkeit, und bestätigte die Aktion. Die Anfrage schlug mit einem Fehler fehl, den der Bildschirm nicht anzeigte, und der Vorfall stand weiter auf nicht eingedämmt. Der Vorfall verwies auf die Ausführung, das Einfrieren brauchte aber den Agenten. Wir haben die Aktion so geändert, dass sie den Agenten aus der Ausführung ermittelt oder einen Fehler zurückgibt, der die stattdessen zu verwendende Aktion nennt. Aus diesem Grund prüft Schritt 2 der Übung den Endstatus jeder Ausführung: Das Vorfallteam muss wissen, ob die Eindämmung stattgefunden hat.
- Erst wiederherstellen, wenn die Ursache bekannt oder eingedämmt ist, jede laufende Aktion einen Status hat, jede abgeschlossene Wirkung einen Verantwortlichen für die Korrektur hat und eine andere Person als die anfragende die neue Befugnis genehmigt hat.
- Die alte Befugnis bleibt widerrufen. Der wiederhergestellte Agent läuft unter einem neuen Mandat oder Release, und ein Test zeigt, dass das widerrufene weiterhin ablehnt.
- Die Überwachung verstärken für den wiederhergestellten Agenten und die Schwelle festlegen, ab der die verstärkte Beobachtung endet.
| Schritt | Aktion | Bestanden, wenn | Festzuhalten |
|---|---|---|---|
| 1. Ausrufen | Den Vorfall eröffnen, den Bereich festlegen (Agent, Release, Mandant oder Umgebung) und die Uhr bei T0 starten | Vorfall und Bereich existieren, bevor ein Aktor läuft | Vorfall-ID, Bereich, ausrufende Person, T0 |
| 2. Ausführungen einfrieren | Jede aktive Ausführung im Bereich einfrieren und den Agenten für Stufen in Processes einfrieren | Jede Ausführung im Bereich ist CANCELLED oder als noch laufend aufgeführt | Ausführungs-IDs, vorheriger Status, Endstatus, Zeit |
| 3. Befugnis widerrufen | Das Agentenmandat widerrufen, die Identität deaktivieren und Tokens beim Identitätsanbieter widerrufen | Neue Autorisierungen schlagen fehl und die Restlaufzeit der Tokens ist bekannt | Widerrufende Person, Grund, Zeit, Token-IDs und Ablauf |
| 4. Nächste Aktion versuchen | Den synthetischen Agenten seine nächste Aktion auf jedem genutzten Pfad vorschlagen lassen: Eingang, Gateway und direkter Aufruf mit altem Token | Jeder Versuch wird abgelehnt und keiner erreicht das nachgelagerte System | Zeit des Versuchs, Pfad, Ablehnungscode wie mandate_revoked, Log des nachgelagerten Systems |
| 5. Laufende Arbeit einordnen | Jede Aktion auflisten, die bei T0 lief oder zurückgehalten war | Jede Aktion ist vor T0 abgeschlossen, nach T0 abgeschlossen, storniert oder ausstehend, ohne unbekannten Status | Aktions-ID, Status, Zeitpunkt der Festschreibung, Verantwortlicher |
| 6. Späte Genehmigung versuchen | Den Decision Request genehmigen, der bei T0 offen war | Die Genehmigung kann die abgebrochene Ausführung nicht fortsetzen | Entscheidungsversuch und Ablehnung |
| 7. Wiederherstellen | Ein neues Mandat oder Release mit neuen Zugangsdaten ausstellen, sobald die Bedingungen für die Wiederherstellung erfüllt sind | Nur die neue Befugnis funktioniert; das widerrufene Mandat lehnt weiterhin ab | Genehmigende Person der Wiederherstellung, geprüfte Bedingungen, erste zugelassene Aktion |
| 8. Abschließen | Den Übungsdatensatz versiegeln und jede Lücke mit einem Verantwortlichen auflisten | Der Vorfallverantwortliche unterzeichnet den Datensatz | Nachweisreferenz, Lücken, Verantwortliche für die Behebung, Termin der nächsten Übung |
Beispiel eines Übungsdatensatzes (synthetisch)
Der folgende Datensatz ist synthetisch. Er zeigt den Detailgrad, den eine Übung festhalten sollte, einschließlich der Befunde, für deren Aufdeckung es Übungen gibt.
| Zeit (UTC) | Ereignis | Ergebnis |
|---|---|---|
| 09:00:00 | Die Übungsleitung ruft den Vorfall INC-DRILL-07 für einen synthetischen Zahlungsagenten aus | Bereich erfasst |
| 09:00:40 | Das Vorfallteam friert Ausführung R-118 (laufend) und Ausführung R-121 (wartet auf einen Decision Request) ein | Beide Ausführungen um 09:00:44 CANCELLED; der Decision Request von R-121 ist storniert |
| 09:01:10 | Die Compliance-Beauftragte widerruft das Agentenmandat mit dem Grund „drill“ | Zwei offene Vorschläge mit mandate_revoked blockiert |
| 09:01:30 | Der Identitätsverantwortliche deaktiviert die Agentenidentität und widerruft ihre Tokens | Ein um 08:55 ausgestelltes Access Token bleibt bei der Ziel-API bis 09:10 gültig |
| 09:02:05 | Der synthetische Agent schlägt payments.create_transfer über den Eingang vor | Mit mandate_revoked abgelehnt; keine Anfrage im Log des Zahlungssystems |
| 09:02:20 | Der synthetische Agent ruft die Ziel-API direkt mit dem Token von 08:55 auf | Von der Ziel-API angenommen. Befund: das Restfenster des Tokens im Zielsystem schließen |
| 09:03:00 | Die beobachtende Person ordnet die laufende Arbeit ein | Eine Überweisung wurde um 09:00:41 in R-118 festgeschrieben, bevor die Ausführung das Signal las. Befund: Treasury verantwortet den Rückruf |
| 09:04:30 | Die prüfende Person versucht, den bei T0 offenen Request von R-121 zu genehmigen | Abgelehnt, weil der Request nicht mehr offen ist |
| 09:20:00 | Die Übungsleitung versiegelt den Datensatz mit zwei Befunden und je einem Verantwortlichen | Nächste Übung nach beiden Korrekturen angesetzt |
Den Schalter mit dem Vorfall-Playbook verbinden
Der Kill Switch stellt die Eindämmung her. Das Vorfallteam muss danach noch den Vorfall eingrenzen, flüchtige Aufzeichnungen sichern, ein bekannt fehlerfreies Release wiederherstellen, festgeschriebene Wirkungen ausgleichen und entscheiden, welche Meldungen anfallen.
Nutzen Sie für diese Abfolge das Playbook für die Reaktion auf Vorfälle mit KI-Agenten. Speisen Sie seine Schwellenwerte aus dem Plan zur Beobachtung nach dem Inverkehrbringen, damit dieselben Signale, die den Vorfall eröffnen, einen eingeübten Stopppfad auslösen können.
Häufig gestellte Fragen
Was ist ein Kill Switch für KI-Agenten?
Ein Kill Switch für KI-Agenten ist ein koordinierter Vorfallbefehl, der aktive Ausführungen abbricht, neue Aktionen am Durchsetzungspunkt ablehnt, Zugangsdaten widerruft, betroffene Workloads isoliert, ausstehende nachgelagerte Arbeit abbricht und festhält, welche Kontrollen abgeschlossen haben. Der Bereich kann eine Ausführung, einen Agenten, ein Release, einen Mandanten oder eine Umgebung umfassen.
Kann der Widerruf von Tokens einen außer Kontrolle geratenen KI-Agenten stoppen?
Der Widerruf von Tokens schließt die Autorisierungspfade, die über diese Tokens laufen. Abbruch zur Laufzeit, Workload-Isolierung, Abbruch der Warteschlange, Ablehnungsregeln in nachgelagerten Systemen und Ausgleichsmaßnahmen decken Arbeit ab, die bereits läuft oder bereits angenommen wurde.
Wo sollte die Kill-Switch-Prüfung laufen?
Führen Sie die entscheidende Prüfung außerhalb des Agentenprozesses und unmittelbar vor jeder Seitenwirkung aus. Die Prüfung sollte einen dauerhaften Vorfallstatus lesen und Aufrufe im betroffenen Bereich ablehnen, auch Aufrufe eines Prozesses, der sein eigenes Abbruchsignal ignoriert.
Wie testen wir einen Kill Switch für KI-Agenten?
Testen Sie aktive Ausführungen, Wartezeiten auf Genehmigungen, eingereihte Arbeit, veraltete Zugangsdaten, einen Policy-Ausfall, einen unkooperativen Prozess, einen Fehler beim Export der Nachweise und die Wiederherstellung unter einem bekannt fehlerfreien Release. Messen Sie Zeit und Anzahl der Seitenwirkungen zwischen dem Befehl und der letzten festgeschriebenen Aktion.
Welche Nachweise sollte der Schalter erzeugen?
Bewahren Sie Vorfallbefehl, Akteur, Bereich, Ausstellungszeit, Bestätigungen jedes Aktors, abgelehnte Aktionen, Änderungen an Tokens und Schlüsseln, Ergebnis der Workload-Isolierung, letzte festgeschriebene Seitenwirkung, ausstehenden Ausgleich und den Integritätsstatus des Nachweisdatensatzes auf.
Die wichtigsten Erkenntnisse
Ein glaubwürdiger Kill Switch für KI-Agenten ist ein kleines Steuerungssystem mit mehreren unabhängigen Aktoren. Legen Sie einen dauerhaften Ablehnungsstatus auf den Aktionspfad, brechen Sie den Workflow ab, schließen Sie den Identitätszugang, isolieren Sie die Rechenumgebung, gleichen Sie nachgelagerte Arbeit ab und halten Sie den Vorfall offen, bis jede erforderliche Kontrolle bestätigt hat. Übungen machen aus dieser Architektur eine gemessene Eindämmungszeit und einen Datensatz, den ein Vorfallverantwortlicher vertreten kann.