ほとんどのオンチェーンAgentのセキュリティ設計は「事後対応型」です——まず素早くデプロイし、問題が発生したら修正します。このアプローチはWeb2アプリでは辛うじて機能しますが（バグはロールバック・補償可能）、オンチェーンAgentシナリオでは危険です：オンチェーン操作は不可逆で、問題が発生してもロールバックはなく、修復コストは極めて高いです。
より良い設計戦略は「最悪ケース思考」（Worst-Case Thinking）です：デプロイ前に系統的に「もしXが同時に発生したら、Agentに何が起きるか？」と自問します——Xはハルシネーション・Prompt Injection・秘密鍵漏洩・外部APIクラッシュ、またはこれらの組み合わせです。この記事は5つの最悪ケースシナリオから始まり、各シナリオの攻撃面・防御設計・複数の防御層が協調して機能する方法を分析します。
最悪ケース思考のコア原則：防御が完璧に機能すると仮定せず、「ある防御層が失敗しても損失が依然として有界」なシステムを設計します。オンチェーンAgentシナリオでの最悪ケース設計の5つのコア質問：LLMが重要な意思決定で完全にハルシネーションを起こした場合、何が起きるか？AgentがPrompt Injectionに完全に制御された場合、攻撃者は何ができるか？Agentの操作秘密鍵が漏洩した場合、損失の上限はいくらか？すべての外部APIが同時にクラッシュした場合、Agentの動作は何か？上記4つが同時に発生した場合、資金が清空されるのを防げるか？
シナリオ1：LLMがリバランス決定時に完全にハルシネーション：縦深防御は3つのレベルでこれを阻止すべきです：グラウンディング層（ツール返却値とLLM引用値の整合性検証、5%超の偏差で阻止）；ホワイトリスト層（書き込みツール呼び出しのターゲットアドレスがホワイトリストになければBLOCKED）；金額上限層（最悪ケースでも損失が有界）。
シナリオ2：Prompt InjectionがAgentの推論を完全に制御：ツール返却データの数値合理性フィルタリング；バックエンドの書き込みツールホワイトリスト検証；Safeマルチ署名アーキテクチャ（操作アドレスが完全に制御されても、資金移動にはSafeマルチ署名の第2の署名が必要）。
シナリオ3：Agentの操作秘密鍵が漏洩：操作ウォレットと資金ウォレットの分離（操作秘密鍵アドレスはGas用の少量ETHのみ保持）；Safeマルチ署名アーキテクチャ；ERC-20承認の最小化（定期的に取り消して再承認、漏洩した古い秘密鍵の悪用可能時間ウィンドウを有界に）。
シナリオ4：すべての外部APIが同時にクラッシュ：ツール失敗サーキットブレーカー（重要ツールが3回連続失敗でサーキットブレーカー発動）；グラウンディング失敗の中止（System Promptで規定：ツール呼び出しが失敗した場合、古いデータで推論を続けてはならない）；デグレードした操作モード（主要ツールが使用不可の場合、最も保守的なモードに切り替え：リバランスなし、モニタリングのみ）。
シナリオ5：複数の問題が同時発生（複合最悪ケース）：すべてのセキュリティメカニズム（ホワイトリスト・金額上限・マルチ署名要件）はサーキットブレーカー状態でも完全に有効で、LLMの推論出力より優先度が高い——サーキットブレーカーは「推論を一時停止する」ではなく「推論が何を出力しても、すべての書き込み操作がコードレベルで強制阻止される」ことです。
縦深防御（Defense in Depth）は軍事とサイバーセキュリティの設計パターンです：単一の防御メカニズムに依存せず、複数の独立した防御層を設計して攻撃者がすべての層を同時に突破しなければ損失を引き起こせないようにします。オンチェーンAgentには5層の縦深防御アーキテクチャがあります：第1層（感知層防御）・第2層（推論層防御）・第3層（実行層防御）・第4層（資金アーキテクチャ層防御）・第5層（モニタリング層防御）。5層防御のキー設計原則：各層は独立して動作し；各層の実装はコードレベルで強制実行され；最内層（資金アーキテクチャ）は最後の保証——他のすべての層が失敗しても、損失の絶対上限を制限できます。
すべてのセキュリティメカニズムの中で、人間の監視は最後かつ最も信頼できる防衛線です——技術的な仮定に依存せず、「監視している人が異常に気づく」ことだけに依存します。効果的な人間監視設計は3つのレベルで介入すべきです：閾値トリガー式確認（設定金額以上の操作はTelegram確認が必要）；サーキットブレーカー後の必須確認（自動回復なし）；定期的なレビュー（週次の操作レポート）。閾値設計原則：「人間の確認が必要」の閾値を「操作が戦略に重大な影響を与えるレベル」に設定します。実用的な初期設定：$500超の操作はTelegram確認が必要；$500以下は自動実行。
最悪ケース設計思考の最大の障壁は技術ではなく心理です：「まずデプロイして問題が出たら対応する」という開発者の傾向。DeFi Agentでのこの傾向のコストは、問題が発生してから数分以内に資金が清空される可能性があることです。本番デプロイ前に1時間かけて最悪ケースのレビューを行ってください。3つの質問に明確に答えられれば、Agentは最悪ケース思考の基本テストに合格しています。