Agent Kill Switch

What is an agent kill switch, and how does it differ from execution boundaries like spending caps or whitelists mentioned earlier?

An execution boundary (a per-transaction spending cap, a whitelist of contracts) is a preventive restriction — it frames what an agent can and can't do before it starts acting, part of the permission-scope design. A kill switch is a responsive mechanism instead — it assumes that even with a carefully designed execution boundary, an unexpected anomaly can still occur (an unknown bug in the agent's logic, or extreme market conditions that suddenly make a previously reasonable strategy dangerous), and in that moment you need a button that can immediately halt all automated activity, rather than waiting for the anomaly to run its course within the authorized scope and finish playing out whatever loss it's going to cause.

The relationship between the two is complementary, not a substitute: execution boundaries reduce both the probability of an anomaly occurring and the ceiling on any single loss; a kill switch puts the speed of response in the user's hands the moment an anomaly actually happens, rather than passively waiting for the agent to finish whatever decision cycle it's currently running.

DeFAI製品にはなぜ緊急停止スイッチが必要なのですか？実行境界だけでは不十分ですか？

どれだけ厳密に設計された実行境界であっても、本質的には「事前に想定できる状況」に対する保護である——1取引あたりの金額上限は単発の巨額損失を防げるが、もしエージェントがプログラムロジックのバグにより、短時間で連続して「1取引あたりの金額は上限内」だが実際には全て誤った判断である取引を発生させた場合、実行境界自体はこのような継続的な損失の累積を止められない。なぜなら各取引を個別に見ればいずれも承認範囲内に収まっているからだ。

実行境界だけでは解決できないもう一つのシナリオは、開発者が事前に全く予想していなかった市場の極端な状況である——例えば特定の取引ペアの流動性が突然枯渇したり、あるプロトコルでこれまでにないセキュリティインシデントが発生したりする場合、元々合理的に設計されていた戦略ロジックが一瞬にして適用不能になる可能性があるが、エージェント自体は「現在の市場環境がもともとの設計上の前提を超えている」ことを自ら認識することはできない。人間の介入が必要であり、緊急停止スイッチで即座に停止させる必要がある。古いロジックのままエージェントに実行を続けさせるべきではない。

緊急停止スイッチは実際どのように設計され、トリガー方式にはどんな一般的な形式がありますか？

最も基本的な形式は、ユーザーによる手動トリガーである——アプリケーションのインターフェース上に明確な「一時停止」ボタンを設け、ユーザーがいつでもクリックできるようにすることで、スマートアカウントコントラクトがそのエージェントから今後送信される全ての取引リクエストを即座に拒否するようにする。この仕組みは技術的には通常、そのエージェントに対応するセッションキーの承認を取り消すか凍結し、取引に署名する能力を失わせることで実現される。

より高度な設計では、システムが自動的にトリガーする異常検知メカニズムが追加される——連続損失の回数を監視する、単位時間あたりの異常な取引頻度を監視する、あるいはエージェントの実行スリッページが継続的に合理的な範囲を超えていないかを監視するなどである。事前に設定された異常の閾値がトリガーされると、システムは自動的にそのエージェントの実行権限を一時停止する。ユーザーが問題に気づいて手動で介入するのを待つ必要はない。このような自動トリガー機構の鍵は、閾値の設計が合理的かどうかにある——閾値を敏感に設定しすぎると頻繁に誤トリガーが発生し正常な戦略運用を妨げる。緩く設定しすぎると早期警告としての意味を失う。

緊急停止スイッチは一般ユーザーにどのような実際の影響を与えますか？製品を評価する際に何に注意すべきですか？

DeFAI製品に緊急停止メカニズムが全く提供されていない場合、エージェントが異常な挙動を示し始めた際、ユーザーができることは待つことだけである——異常が承認範囲内で発生し得る損失を全て出し尽くすまで待つか、あるいはより手間のかかるオフチェーンの方法（プラットフォームのサポートに連絡するなど）でしか介入できない。このような製品はユーザーにとって実質的なコントロール権が明らかに低い。

評価する際に確認する価値がある点には、この一時停止ボタンが本当に即座に有効になるか（一部の設計には遅延があり、一時停止の指示が次のブロックまで実際には有効にならない場合がある）、一時停止が既に送信済みだが未確定の取引に影響を与えるか（一時停止は通常、将来の新規取引をブロックできるだけで、既にオンチェーンでキュー待ちの取引を取り消すことはできない）、手動介入以外の第二の防衛線として自動異常検知メカニズムがあるかが含まれる。成熟したDeFAI製品は通常、ユーザーが能動的にトリガーできる緊急一時停止ボタンと、システムレベルの自動異常監視の両方を備えている。どちらか一方だけでは不十分である。