ほとんどの人がクリプトAIエージェントのセキュリティ設計について「Agentが攻撃されないようにするにはどうすればいいか？」と尋ねます。それは間違った質問です。正しい質問は「Agentのすべての防御が失敗した場合——Prompt Injectionが成功し、MCPサーバーが汚染され、LLMの推論が完全に乗っ取られた場合——攻撃者が最悪できることは何か？」です。この質問に明確に答えられない場合、System Promptがどれほどうまく書かれていても、Agentのセキュリティ設計は完成していません。この記事は「最悪のケース」から出発し、設計目標は攻撃を不可能にすることではなく、攻撃が成功した場合でも結果をあなたの許容範囲内に収めることです。
従来のセキュリティ設計の考え方は「ドアに鍵をかける」——より多くのセキュリティチェックを追加し、攻撃の成功を難しくすることです。この考え方はクリプトAgentには不十分です。なぜなら攻撃成功の可能性は常に存在するからです：LLMのPrompt Injectionには100%の防御がなく、MCPサーバーのソーシャルエンジニアリング攻撃を完全に防ぐことは難しく、使用するすべてのツールのベンダーが侵害されていないことを保証することはできません。クリプトAgentのセキュリティ設計は「縦深防御（Defense in Depth）」のアーキテクチャ思想から始まるべきです：一部の防御層が必ず失敗することを前提とし、各層の外にさらに次の層があり、各層が失敗した場合の最悪の結果が受け入れられるものであることを確認します。
最小限必要な認可は防御システム全体の基盤です——他のすべての防御が失敗した場合でも、この層が攻撃者が「得られるもの」の上限を決定します。設計原則：
Agent操作ウォレットには数日分の運転資金のみ保持します。Agent操作ウォレットの資金量は「これらの資金をすべて失っても財務的なストレスを感じない金額」に等しくすべきです。Agentは戦略資金全体を直接管理する必要はありません——Agentは「数回の操作を実行するための燃料」だけが必要で、ほとんどの資金はAgentが直接アクセスできないメインウォレットに保持します。推奨比率：操作ウォレット（ホット）に戦略資金の5〜10%、残りはコールドストレージに。
ERC-20承認は正確に制限します。各プロトコル・各トークンに具体的な最大のapprove金額を設定します（`approve(AaveV3, 500_USDC)`）。無制限の承認（`type(uint256).max`）は付与しません。毎月未使用の承認を確認して取り消します（revoke.cashで迅速に操作できます）。Agentのラベルが汚染されても、転送したい金額はapprove上限によってハードに制約されます。
操作タイプのホワイトリスト。Agentが呼び出せるツールはタスクに必要な最小セットに正確に制限されなければなりません。DeFiの利率最適化Agentは「特定のホワイトリストプロトコルのUSDCの預け入れ/引き出し」だけが必要で、「任意のアドレスへの転送」は必要ありません。不要なツールをAgentのツールリストから削除し、「念のため」残さないでください。
攻撃者がAgentのLLM推論の汚染に成功しても、読み書きの隔離は汚染された推論が直接資金操作をトリガーすることを防ぎます。読み取りツールと書き込みツールは厳格に隔離された実行環境で動作します。すべての書き込み操作はバックエンドで二次的なパラメータ検証を行います——ツール関数のバックエンド実装（LLMが見られる説明層ではなく）で、すべての書き込み操作パラメータをハードに検証します：金額が上限内か、ターゲットアドレス/プロトコルがホワイトリストにあるか、操作タイプが許可されているか。高額操作のための独立した確認チャネル——閾値（例：$100）を超えるすべての書き込み操作は、Agentの推論フローとは完全に独立したチャネル（Telegram Botがあなたに通知し、あなたの返信を待ち、その後実行する）で確認が必要です。
サーキットブレーカーは「Agentがすでに異常なことをしている場合、どのように損失の拡大を自動的に停止するか」を前提とします：
日次支出上限サーキットブレーカー。バックエンドロジックに日次累計支出カウンター（Gas代+A2A支払い手数料+資金操作金額）を維持します。設定した日次上限を超えると、すべての後続の書き込み操作が自動的に一時停止され、緊急通知が送られ、手動リセットを待ちます。このカウンターはバックエンドコードで維持され、LLMのContextにはありません——LLMはそれを読んだり変更したりできません。日次上限の80%に達したときに「警告」通知を送り（判断して必要なら手動で一時停止する時間を持てる）、100%に達したときに「サーキットブレーカートリガー」通知を送り操作を停止します。
市場異常サーキットブレーカー。いくつかの市場異常条件を設定します：Agentが操作する資産が15分以内にX%以上下落・Gas代が通常値の10倍超・DEXの実際のスリッページが設定上限を超える。いずれかがトリガーされると、すべての書き込み操作が自動的に一時停止されます——通常の市場向けに設計された戦略をブラックスワン市場イベント時にAgentが実行し続けることを防ぎます。
4層の完全な操作ログ。完全な操作ログは事後の根本原因分析の唯一の手段です。4つの必要なログ層：LLM推論ログ（各ThoughtステップのAgentの意思決定理由を含む完全な出力）；ツール呼び出しログ（どのツールを呼び出し・どのパラメータを入力し・ツールが返した生データ）；決定認可ログ（どの操作が提出され・どれがバックエンド検証で遮断され・どれが確認チャネルに入ったか）；オンチェーン実行ログ（トランザクションハッシュ・Gas代・約定価格・実行時間）。4つのログ層を暗号化ストレージに保存し、最低90日間保持します。
攻撃後の緊急対応は事前に設計しておく必要があります。標準的な緊急対応フロー：第1ステップ（0〜5分）：Agentが予期しない操作を実行していることを確認したら、すぐにAgentサービスプロセスを停止します——これが最も速い「緊急ブレーキ」です。第2ステップ（5〜15分）：AgentアドレスからすべてのプロトコルへのERC-20承認を取り消します。サービスを停止しても承認が残っている場合、攻撃者はコードレベルでコントラクトを呼び出してトークンを直接転送できます。メインウォレットから各トークンコントラクトに`approve(agentAddress, 0)`を呼び出してすべての承認を取り消します。第3ステップ（15〜60分）：すべてのログを隔離されたストレージに保存し、根本原因分析を開始します。第4ステップ：セキュリティの脆弱性を修正し、テストネットで攻撃パスを完全に再現して修正が有効なことを確認し、再デプロイします。
縦深防御の目標はAgentシステムを「攻撃不可能」にすることではありません——それは非現実的な目標です。現実的な目標は：攻撃が成功しても、攻撃者が得られるものは最大でも操作ウォレットの数日分の運転資金（あなたのすべての資産ではなく）であり、事後に攻撃パスと根本原因を追跡できる完全なログがある、ということです。よく設計されたオンチェーンAgentシステムは「Agentが今日完全に侵害されても、明日もこのビジネスを続けられる」と自信を持って答えられるようにします。そう答えられなければ、セキュリティ設計はまだ完成していません。