本物のキルスイッチは、エージェントの推論の外側に存在します。1回の呼び出しで、そのエージェントに対するその後のすべての決定チェックが、ポリシー層でdenyを返すようになります——エージェントのプロンプトが何と言おうと関係ありません。それはモデルが無視したり、反論したり、巧妙な入力によって言いくるめられたりできる「止まってください」という指示ではありません。モデルが決して目にすることのないフラグであり、モデルには発言権のない層でチェックされます。
「エージェントに停止するよう伝えるシステムメッセージを追加する」というのは直感的な最初の答えですが、それは誤った層です。システムプロンプトは、モデルの注意を奪い合う他のあらゆる指示と並んでモデルが解釈する指示にすぎません——成功したプロンプトインジェクション、新しい指示を読み込まなくなった行き詰まったエージェント型ループ、あるいはコンテキストの前方に埋もれた指示の優先度を単純に下げるモデルなどが含まれます。これらの失敗モードはどれも仮定の話ではありません。まさにキルスイッチが存在する理由となるシナリオそのものです。エージェントを止めるために頼っているメカニズムが、現在誤動作しているのと同じ推論プロセスの内側にあるなら、それは制御ではありません。それは提案にすぎません。
権限 guard.killswitch.write を持つオペレーターが理由とともに POST /v1/suite/guard/kill/{agent_id} を呼び出します。これにより is_killed = true がエージェントのレコードに設定されます——それ以上でも以下でもなく、エージェント自身のプロセスはこれに一切関与しません。
POST /v1/decisions/check は他のどの分岐よりも先にキルフラグを評価します。以降のすべてのリクエストは deny とともに reason_code: "agent_killed" が返され、エージェントがどんなアクションを試みていたかに関係ありません。
キルされたエージェントは新しいポータブルなトラストクレデンシャルを発行できません。POST /v1/credentials/issue は、is_killed をチェックした瞬間に、他の何かが実行される前に403を返します。
Vault台帳エントリ(agent.killed)、標準の監査ログ行、そして危険度の高いワークスペース通知が、すべてキル時点で書き込まれます——エージェント自身とは独立して、誰が、いつ、なぜ行ったかの記録が残ります。
POST /v1/suite/guard/unkill/{agent_id} がフラグをクリアし、通常の決定チェックと認証情報発行を復元します。エージェントをキルしても、そのトラストスコアの履歴には影響しません——それは別個の、監査ログに記録されるオペレーター操作です。
境界について正確に理解してください。キルスイッチは、VeriSwarmに許可を求めるすべてのチェックポイントで拒否します——決定チェック、認証情報リクエスト、キルされたエージェントとの間のA2Aタスクの引き渡しです。エージェント自身のランタイムに入り込んでタスクの途中で実行を停止させることはできず、また、エージェントがすでに保持していて、VeriSwarmに事前確認しないシステムに提示し続けられる認証情報を取り消すこともできません。だからこそ、これは6つのうちの1つの制御であり、他の制御の代替ではありません——最小権限のツール許可とPIIトークン化は、誰かがキルスイッチに頼る前の段階でエージェントが何を誤って行えるかを減らします。6つの制御の全チェックリストを見る。
キルスイッチの発動または解除には、guard.killswitch.write 権限を持つセッショントークンが必要です——これはsuper_admin、platform_admin、tenant_admin、およびoperator のロールが保持しています。これは意図的にエージェント自身のAPIキーからは到達できません。侵害されたエージェント、あるいは悪い行動へと推論を進めているエージェントは、自分自身をキルすることも、キル解除することもできません。制御は外部から来る必要があります。
オペレーターが起動する上書きで、エージェント自身のコードパスや協力に依存することなく、特定のエージェントの行動能力を即座にブロックします。VeriSwarmでは、1回の呼び出し——POST /v1/suite/guard/kill/{agent_id}——がエージェントのレコード上のフラグを切り替えます。それ以降、そのエージェントに対するすべての信頼決定チェック(POST /v1/decisions/check)はreason_code: "agent_killed"とともにdenyを返し、そのエージェントの新しい認証情報の発行は完全に拒否されます。これは取り消し可能です。キル解除の呼び出し(POST /v1/suite/guard/unkill/{agent_id})が通常の動作を復元します。
はい——不十分です。システムプロンプトの指示は、モデルを言いくるめて外させることができる依頼にすぎません。それが核心的な違いです。本物のキルスイッチはエージェントに停止を依頼するのではなく、エージェントが行動しようとしたときに何が起こるかを変えます。チェックはモデル自身の推論ループの外側、決定層で行われるため、成功したプロンプトインジェクション、行き詰まったエージェント型ループ、あるいはモデルが単に以前の指示を無視することがあっても関係ありません——次の決定チェックはいずれにせよ拒否されて戻ってきます。
実際の決定パスに照らして確認された、3つのことです。そのエージェントに対するPOST /v1/decisions/checkへの以降のすべての呼び出しはdenyを返します(decision_preview.pyは他のどの分岐よりも先にagent.is_killedをチェックします)。そのエージェント向けの新しいポータブル認証情報の発行は403で拒否されます(routes/credentials.py)。そして、VeriSwarmのA2Aプロトコルおよびジャストインタイムのアクセスチェックが関わる場合、他のエージェントがキルされたエージェントにタスクを引き渡そうとしたり、アクセスを付与しようとしたりする試みもブロックされます。しないことは、エージェント自身のプロセスに入り込んで実行の途中で停止させることです——次の回答を参照してください。
いいえ、そしてこれが決定層のキルスイッチの正直な限界です。VeriSwarmに許可を求めるその後のすべてのチェックポイントで拒否します——決定、認証情報の発行、A2Aタスクの引き渡しです。エージェントがすでに発行済みで他の場所で使用できる認証情報を持っている場合、あるいはエージェントが行動する前にVeriSwarmに確認しないシステムで動作している場合、VeriSwarmでキルしてもそのパスには届きません。キルスイッチは、行動する前に決定をチェックするエージェントのためのポリシー層の制御です——だからこそ、セキュリティチェックリストの制御#2(最小権限のツール許可)と制御#4(インジェクションスキャン)は、キルスイッチのバックアップとしてではなく、キルスイッチに頼る必要が生じる前にエージェントが何を誤って行えるかを減らす制御として、独立して重要なのです。
いいえ——起動または解除には、guard.killswitch.write権限を持つセッショントークンが必要で、これはフルアクセス権限を持つロール(super_admin、platform_admin、tenant_admin、operator)が保持しています。これは設計上、エージェント自身のAPIキーには公開されていません。侵害されたエージェント、またはそれを侵害した何かは、自分の痕跡を消すために自分自身をキルすることはできず、キル解除することもできません。
キルスイッチはVeriSwarm Guardの一部であり、Maxプランの機能です。Vaultが有効な場合、すべての起動と解除は不変のVault台帳エントリ(agent.killed / agent.unkilled)を書き込み、さらに標準の監査ログエントリと危険度の高いワークスペース通知も記録します——そのため、エージェント自身が報告する内容とは独立して、誰がいつ、なぜそのエージェントをキルしたかの記録が残ります。
キルスイッチはMaxプランのGuard機能です。Gateの無料ティアは、まずそれが接続する決定層とイベントの可視性を提供します。