Ein echter Kill-Switch existiert außerhalb der Denkprozesse des Agenten. Ein einziger Aufruf, und jede nachfolgende Entscheidungsprüfung für diesen Agenten liefert auf der Policy-Ebene deny zurück — unabhängig davon, was der Prompt des Agenten sagt. Es ist keine "Bitte aufhören"-Anweisung, die das Modell ignorieren, mit der es argumentieren oder von der es sich durch eine manipulierte Eingabe abbringen lassen kann. Es ist ein Flag, das das Modell nie sieht, geprüft auf einer Ebene, bei der es kein Mitspracherecht hat.
"Füge eine Systemnachricht hinzu, die den Agenten anweist zu stoppen" ist die instinktive erste Antwort, und sie liegt auf der falschen Ebene. Ein System-Prompt ist eine Anweisung, die das Modell zusammen mit jeder anderen Anweisung interpretiert, die um seine Aufmerksamkeit konkurriert — einschließlich einer erfolgreichen Prompt-Injection, einer feststeckenden agentischen Schleife, die aufgehört hat, neue Anweisungen zu lesen, oder eines Modells, das eine früher im Kontext vergrabene Anweisung einfach niedriger priorisiert. Keiner dieser Fehlermodi ist hypothetisch; es sind genau die Szenarien, für die ein Kill-Switch existiert. Wenn der Mechanismus, auf den du dich verlässt, um den Agenten zu stoppen, sich innerhalb desselben Denkprozesses befindet, der sich gerade fehlverhält, ist er keine Kontrolle. Es ist ein Vorschlag.
Ein Operator mit der Berechtigung guard.killswitch.write ruft POST /v1/suite/guard/kill/{agent_id} mit einem Grund auf. Das setzt is_killed = true im Datensatz des Agenten — nicht mehr, und der eigene Prozess des Agenten ist nicht daran beteiligt.
POST /v1/decisions/check wertet das Kill-Flag vor jedem anderen Zweig aus. Jede nachfolgende Anfrage kommt als deny mit reason_code: "agent_killed" zurück, egal welche Aktion der Agent versucht hat.
Ein eliminierter Agent kann keine neuen portablen Anmeldeinformationen mehr ausstellen. POST /v1/credentials/issue liefert einen 403 in dem Moment, in dem es is_killed prüft, bevor irgendetwas anderes läuft.
Ein Vault-Ledger-Eintrag (agent.killed), eine Standard-Audit-Log-Zeile und eine Workspace-Benachrichtigung mit Gefahren-Schweregrad werden zum Zeitpunkt der Eliminierung geschrieben — es gibt einen Nachweis, wer, wann und warum, unabhängig vom Agenten.
POST /v1/suite/guard/unkill/{agent_id} löscht das Flag und stellt die normale Entscheidungsprüfung und Ausstellung von Anmeldeinformationen wieder her. Das Eliminieren eines Agenten rührt seinen Trust-Score-Verlauf nicht an — es ist eine separate, audit-protokollierte Operator-Aktion.
Sei präzise bei der Grenze. Der Kill-Switch verweigert an jedem Kontrollpunkt, der VeriSwarm um Erlaubnis bittet — eine Entscheidungsprüfung, eine Anfrage nach Anmeldeinformationen, eine A2A-Aufgabenübergabe zu oder von dem eliminierten Agenten. Er greift nicht in die eigene Laufzeitumgebung des Agenten ein, um die Ausführung mitten in einer Aufgabe zu stoppen, und er widerruft keine Anmeldeinformationen, die der Agent bereits besitzt und die er weiterhin einem System vorlegen könnte, das nicht zuerst bei VeriSwarm nachfragt. Deshalb ist er eine Kontrolle unter sechs, kein Ersatz für die anderen — Tool-Berechtigungen nach dem Prinzip der geringsten Rechte und PII-Tokenisierung verringern, was ein Agent im Zeitfenster falsch machen kann, bevor überhaupt jemand zum Kill-Switch greift. Die vollständige Sechs-Kontrollen-Checkliste ansehen.
Das Aktivieren oder Zurücksetzen des Kill-Switch erfordert ein Sitzungstoken mit guard.killswitch.write — im Besitz der Rollen super_admin, platform_admin, tenant_admin und operator. Er ist absichtlich nicht mit dem eigenen API-Schlüssel des Agenten erreichbar: Ein Agent, der kompromittiert wurde, oder einer, der sich in Richtung einer schädlichen Aktion hindenkt, kann sich nicht selbst eliminieren oder wiederherstellen. Die Kontrolle muss von außen kommen.
Eine von einem Operator ausgelöste Übersteuerung, die sofort die Handlungsfähigkeit eines bestimmten Agenten blockiert, ohne auf den eigenen Codepfad oder die Mitwirkung des Agenten angewiesen zu sein. Bei VeriSwarm setzt ein einziger Aufruf — POST /v1/suite/guard/kill/{agent_id} — ein Flag im Datensatz des Agenten. Von diesem Zeitpunkt an liefert jede Trust-Entscheidungsprüfung gegen diesen Agenten (POST /v1/decisions/check) deny mit reason_code: "agent_killed" zurück, und die Ausstellung neuer Anmeldeinformationen für diesen Agenten wird von vornherein verweigert. Er ist umkehrbar: Ein Unkill-Aufruf (POST /v1/suite/guard/unkill/{agent_id}) stellt den normalen Betrieb wieder her.
Nein — eine System-Prompt-Anweisung ist eine Bitte, von der sich das Modell abbringen lassen kann. Das ist der entscheidende Unterschied. Ein echter Kill-Switch bittet den Agenten nicht, aufzuhören; er ändert, was passiert, wenn der Agent versucht zu handeln. Die Prüfung findet auf der Entscheidungsebene statt, außerhalb der eigenen Denkschleife des Modells, sodass eine erfolgreiche Prompt-Injection, eine feststeckende agentische Schleife oder ein Modell, das eine frühere Anweisung einfach ignoriert, keine Rolle spielt — die nächste Entscheidungsprüfung kommt trotzdem verweigert zurück.
Drei Dinge, bestätigt anhand des Live-Entscheidungspfads: Jeder nachfolgende Aufruf von POST /v1/decisions/check für diesen Agenten liefert deny zurück (decision_preview.py prüft agent.is_killed vor jedem anderen Zweig); die Ausstellung neuer portabler Anmeldeinformationen für diesen Agenten wird mit einem 403 verweigert (routes/credentials.py); und, wo das A2A-Protokoll von VeriSwarm und JIT-Zugriffsprüfungen im Spiel sind, werden auch Versuche anderer Agenten blockiert, dem eliminierten Agenten Aufgaben zu übergeben oder ihm Zugriff zu gewähren. Was er nicht tut, ist, in den eigenen Prozess des Agenten einzugreifen und ihn mitten in der Ausführung zu stoppen — siehe die nächste Antwort.
Nein, und das ist die ehrliche Grenze eines Kill-Switch auf Entscheidungsebene. Er verweigert an jedem nachfolgenden Kontrollpunkt, der VeriSwarm um Erlaubnis bittet — Entscheidungen, Ausstellung von Anmeldeinformationen, A2A-Aufgabenübergabe. Wenn ein Agent bereits ausgestellte Anmeldeinformationen hat, die er anderswo nutzen kann, oder wenn er in einem System arbeitet, das nicht bei VeriSwarm nachfragt, bevor es handelt, erreicht ihn das Eliminieren in VeriSwarm diesen Pfad nicht. Der Kill-Switch ist eine Kontrolle auf Policy-Ebene für Agenten, die Entscheidungen prüfen, bevor sie handeln — genau deshalb sind Kontrolle #2 der Sicherheits-Checkliste (Tool-Berechtigungen nach dem Prinzip der geringsten Rechte) und Kontrolle #4 (Injection-Scanning) unabhängig wichtig, nicht als Absicherung für den Kill-Switch, sondern als Kontrollen, die verringern, was ein Agent falsch machen kann, bevor du überhaupt zu ihm greifen müsstest.
Nein — ihn zu aktivieren oder zurückzusetzen erfordert ein Sitzungstoken mit der Berechtigung guard.killswitch.write, im Besitz von Rollen mit vollem Zugriff (super_admin, platform_admin, tenant_admin, operator). Er ist absichtlich nicht über den eigenen API-Schlüssel des Agenten zugänglich: Ein Agent — oder etwas, das ihn kompromittiert hat — kann sich nicht selbst eliminieren, um seine Spuren zu verwischen, und kann sich auch nicht selbst wiederherstellen.
Der Kill-Switch ist Teil von VeriSwarm Guard, einer Funktion des Max-Tarifs. Jede Aktivierung und Zurücksetzung schreibt einen unveränderlichen Vault-Ledger-Eintrag (agent.killed / agent.unkilled), wenn Vault aktiviert ist, plus einen Standard-Audit-Log-Eintrag und eine Workspace-Benachrichtigung mit Gefahren-Schweregrad — es gibt also einen Nachweis, wer den Agenten eliminiert hat, wann und warum, unabhängig davon, was der Agent selbst meldet.
Der Kill-Switch ist eine Guard-Funktion des Max-Tarifs. Der kostenlose Tarif von Gate gibt dir zuerst die Entscheidungsebene und die Ereignis-Sichtbarkeit, an die er andockt.