SlowMist × Bitget AIセキュリティレポート：「ロブスター」などのAIエージェントに資金を預けるのは本当に安全なのか？
TechFlow厳選深潮セレクト
SlowMist × Bitget AIセキュリティレポート：「ロブスター」などのAIエージェントに資金を預けるのは本当に安全なのか？
本報告は、セキュリティ研究および取引プラットフォームの実践という2つの観点から、AIエージェントの複数のシナリオにおけるセキュリティ問題を体系的に整理しています。
Web3業界の深掘り報道に専念し潮流を洞察執筆：SlowMist および Bitget
一、背景
大規模言語モデル（LLM）技術の急速な発展に伴い、AI Agent は単なるスマートアシスタントから、自律的にタスクを実行可能な自動化システムへと進化しつつあります。Web3 エコシステムにおいては、この変化が特に顕著です。多くのユーザーが、AI Agent を市場動向分析、取引戦略の生成、さらには自動取引に活用し始めています。「7×24 時間稼働する自動取引アシスタント」という概念が、現実へと少しずつ近づきつつあるのです。Binance や OKX が複数の AI Skills をリリースし、Bitget が Skills リソースステーション「Agent Hub」およびインストール不要のロブスター型ツール「GetClaw」を提供したことで、Agent は取引プラットフォームの API、オンチェーンデータ、市場分析ツールなどに直接接続可能となり、もともと人手で行っていた取引判断および実行作業の一部を担えるようになりました。
従来の自動化スクリプトと比較して、AI Agent はより高度な自律的判断能力と、より複雑なシステム間相互作用能力を備えています。例えば、リアルタイムの市場データへのアクセス、取引 API の呼び出し、アカウント資産の管理などに加え、プラグインや Skill を通じた機能拡張も可能です。このような能力の向上により、自動取引の利用ハードルが大幅に低下し、一般ユーザーにも自動取引ツールの導入・活用が広がりつつあります。
しかし、能力の拡張は、攻撃面の拡大を意味します。
従来の取引シーンでは、セキュリティリスクは主にアカウント認証情報や API キーの漏洩、フィッシング攻撃などに集中していました。一方、AI Agent アーキテクチャでは、新たなリスクが浮上しています。例えば、プロンプトインジェクション（Prompt Injection）によって Agent の意思決定ロジックが操作される可能性、悪意あるプラグインや Skill がサプライチェーン攻撃の新たな入り口となる可能性、また実行環境の設定ミスによって機密データや API 権限が不正に利用される可能性などです。こうした問題が自動取引システムと結びつくと、潜在的な影響は情報漏洩にとどまらず、実際の資産損失を引き起こす可能性があります。
さらに、AI Agent を取引アカウントに接続するユーザーが増えていることに伴い、攻撃者も迅速にこの変化に対応しています。Agent ユーザーを標的とした新型詐欺、悪意あるプラグインによる「投毒（Poisoning）」、API キーの乱用などは、すでに新たなセキュリティ脅威として現れ始めています。Web3 の世界では、資産操作は高価値かつ不可逆であることが多く、自動化システムが誤って操作されたり、誤導されたりした場合、そのリスクの影響はさらに拡大します。
こうした背景を踏まえ、SlowMist と Bitget は共同で本レポートを作成しました。セキュリティ研究と取引プラットフォームの実務経験という二つの視点から、AI Agent が関与するさまざまなシナリオにおけるセキュリティ課題を体系的に整理しました。本レポートが、ユーザー、開発者、プラットフォーム運営者にとって有用なセキュリティ参考資料となり、AI Agent エコシステムがセキュリティとイノベーションのバランスを保ちながら、より堅固に発展していく一助となれば幸いです。
二、AI Agent の現実的なセキュリティ脅威｜SlowMist
AI Agent の登場により、ソフトウェアシステムは「人間主導の操作」から「モデルが意思決定と実行に参加する」構造へと移行しています。このようなアーキテクチャの変化は、自動化能力を大きく高めますが、同時に攻撃面も拡大します。現在の技術構造から見ると、典型的な AI Agent システムは、ユーザインタラクション層、アプリケーション論理層、モデル層、ツール／スキル呼び出し層（Tools / Skills）、メモリシステム（Memory）、および基盤となる実行環境など、複数のコンポーネントから構成されています。攻撃者は単一モジュールを標的とするのではなく、多段階のパスを経て、Agent の動作制御権を徐々に奪おうと試みます。
1. 入力操作およびプロンプトインジェクション攻撃
AI Agent アーキテクチャでは、ユーザー入力および外部データが通常、モデルのコンテキストに直接組み込まれるため、プロンプトインジェクション（Prompt Injection）は重要な攻撃手法の一つとなっています。攻撃者は特定の指示を巧妙に構成することで、本来実行すべきでない操作を Agent に誘導できます。例えば、ある事例では、単なるチャットメッセージのみで、Agent が危険なシステムコマンドを生成・実行するように誘導できました。
より複雑な攻撃手法は「間接的インジェクション」であり、攻撃者が悪意ある命令をウェブページのコンテンツ、ドキュメントの説明文、コードのコメントなどに隠蔽するものです。Agent がタスク実行中にこれらのコンテンツを読み込むと、それを正当な命令と誤認して実行してしまう可能性があります。たとえば、プラグインのドキュメント、README ファイル、または Markdown ファイルに悪意あるコマンドを埋め込むことで、Agent が環境初期化や依存関係のインストール時に攻撃コードを実行してしまうことがあります。
この攻撃パターンの特徴は、伝統的な脆弱性に依存せず、モデルがコンテキスト情報を信頼する仕組みを利用して、その行動ロジックに影響を与える点にあります。
2. Skills／プラグインエコシステムにおけるサプライチェーン投毒
現在の AI Agent エコシステムにおいて、プラグインおよびスキルシステム（Skills / MCP / Tools）は、Agent の機能拡張のための重要な手段です。しかし、こうしたプラグインエコシステムは、新たなサプライチェーン攻撃の入り口にもなりつつあります。
SlowMist は、OpenClaw 公式プラグインセンター「ClawHub」の監視を通じて、開発者数の増加に伴い、悪意ある Skill が既に混入し始めていることを確認しました。SlowMist は、400 件を超える悪意ある Skill の IOC（Indicator of Compromise）をマージ・分析した結果、多数のサンプルが少数の固定ドメインや同一 IP 上の複数ランダムパスを指しており、明確なリソース再利用の特徴が見られ、これは組織的・量産的な攻撃行動である可能性が高いと判断しました。
OpenClaw の Skill 体系では、主要なファイルは通常「SKILL.md」です。従来のコードとは異なり、このような Markdown ファイルは「インストール手順」と「初期化エントリーポイント」の役割を果たすことが多いですが、Agent エコシステムでは、ユーザーが直接コピー・実行することが多いため、完全な実行チェーンが形成されます。攻撃者は、悪意あるコマンドを依存関係のインストール手順に偽装すればよく、例えば `curl | bash` や Base64 エンコーディングで実際の命令を隠すことで、ユーザーに悪意あるスクリプトの実行を誘導できます。
実際のサンプルでは、いくつかの Skill が典型的な「2段階ロード」戦略を採用しています。第1段階のスクリプトは、第2段階のペイロードをダウンロード・実行するだけの役割を果たし、静的検出の成功率を下げています。ダウンロード数の多い「X（旧Twitter）トレンド」Skill を例にとると、その SKILL.md 内に Base64 エンコードされたコマンドが隠されていました。
デコードすると、それはリモートスクリプトをダウンロード・実行する命令であることが明らかになります：
そして第2段階のプログラムは、システムのポップアップを偽装してユーザーのパスワードを盗み取り、システムの一時ディレクトリ内からローカルマシンの情報、デスクトップ上のドキュメント、およびダウンロードディレクトリ内のファイルを収集し、最終的にそれらを攻撃者が支配するサーバーへとアップロードします。
この攻撃手法の核心的な優位性は、Skill の外装部分を比較的安定させたまま、攻撃者はリモートのペイロードを差し替えるだけで、攻撃ロジックを継続的に更新できる点にあります。
3. Agent の意思決定およびタスク編成層におけるリスク
AI Agent のアプリケーション論理層では、タスクは通常、モデルによって複数の実行ステップに分割されます。もし攻撃者がこの分割プロセスに干渉できれば、Agent が正当なタスクを実行している際にも異常な挙動を示す可能性があります。
例えば、マルチステップ操作を含む業務フロー（自動デプロイやオンチェーン取引など）において、攻撃者は重要なパラメータを改ざんしたり、ロジック判断を妨害したりすることで、Agent の実行フロー内で宛先アドレスを置き換えたり、余分な操作を実行させたりすることが可能です。
SlowMist の過去のセキュリティ監査事例では、MCP から悪意あるプロンプトを返すことでコンテキストを汚染し、Agent がウォレットプラグインを呼び出してオンチェーン送金を実行するよう誘導したことがあります。
こうした攻撃の特徴は、エラーがモデルが生成したコード由来ではなく、タスク編成ロジックが改ざんされたことにある点です。
4. IDE／CLI 環境におけるプライバシーおよび機密情報の漏洩
AI Agent が開発支援および自動運用補助に広く活用されるようになった後、多数の Agent が IDE、CLI、またはローカル開発環境上で実行されるようになりました。こうした環境には、`.env` 設定ファイル、API トークン、クラウドサービスの認証情報、秘密鍵ファイル、各種アクセスキーなど、大量の機密情報が含まれることが多いです。Agent がタスク実行中にこれらのディレクトリやプロジェクトファイルを読み取れる場合、無意識のうちに機密情報がモデルのコンテキストに取り込まれてしまう可能性があります。
ある自動開発フローでは、Agent がデバッグ、ログ分析、依存関係のインストールなどの過程でプロジェクトディレクトリ内の設定ファイルを読み取ることがあります。明確な除外ポリシーまたはアクセス制御がなければ、これらの情報はログに記録されたり、リモートのモデル API へ送信されたり、悪意あるプラグインによって外部へ送信されたりする可能性があります。
さらに、一部の開発ツールは、Agent がコードリポジトリを自動スキャンしてコンテキストメモリ（Memory）を構築することを許可しています。これにより、機密データの露出範囲がさらに拡大する可能性があります。例えば、秘密鍵ファイル、助記詞バックアップ、データベース接続文字列、第三者 API トークンなどが、インデックス作成の過程で読み取られる恐れがあります。
Web3 開発環境では、この問題が特に深刻です。なぜなら、開発者はローカル環境にテスト用の秘密鍵、RPC トークン、デプロイスクリプトなどを保存することが多いからです。こうした情報が悪意ある Skill、プラグイン、またはリモートスクリプトによって取得されれば、攻撃者は開発者のアカウントやデプロイ環境をさらに制御できるようになります。
したがって、AI Agent と IDE／CLI の統合シナリオにおいて、明確な機密ディレクトリ除外ポリシー（例：`.agentignore`、`.gitignore` に相当する仕組み）および権限分離措置を確立することは、データ漏洩リスクを低減する上で極めて重要です。
5. モデル層の不確定性および自動化リスク
AI モデル自体は完全に決定論的なシステムではなく、出力には一定の確率的な不安定性が伴います。「モデルの幻覚（Hallucination）」とは、情報が不足している状況で、一見妥当に見えるが実際には誤った結果を生成する現象です。従来のアプリケーションでは、こうした誤りは通常、情報の質にしか影響しませんが、AI Agent アーキテクチャでは、モデルの出力が直接システム操作をトリガーする可能性があります。
例えば、ある事例では、モデルがプロジェクトをデプロイする際に実際のパラメータを照会せず、誤った ID を生成してそのままデプロイフローを続行しました。同様の状況が、オンチェーン取引や資産操作の場面で発生した場合、誤った意思決定により、不可逆的な資金損失を招く可能性があります。
6. Web3 シナリオにおける高価値操作リスク
従来のソフトウェアシステムとは異なり、Web3 環境における多くの操作は不可逆です。例えば、オンチェーン送金、トークン交換（Swap）、流動性追加、スマートコントラクトの呼び出しは、一旦署名されネットワークへブロードキャストされると、通常は取り消しやロールバックが困難です。したがって、AI Agent がオンチェーン操作の実行に使われる場合、そのセキュリティリスクはさらに拡大します。
いくつかの実験的プロジェクトでは、開発者がすでに Agent をオンチェーン取引戦略の実行に直接活用し始めています。例えば、自動裁定取引（アービトラージ）、資金管理、DeFi 操作などです。しかし、Agent がタスクの分解やパラメータ生成の過程で、プロンプトインジェクション、コンテキスト汚染、プラグイン攻撃などの影響を受けると、取引中に宛先アドレスを置き換えたり、取引金額を改ざんしたり、悪意あるコントラクトを呼び出したりする可能性があります。さらに、一部の Agent フレームワークでは、プラグインがウォレット API や署名インターフェースに直接アクセスできるようになっています。署名の分離や人手による確認メカニズムがなければ、攻撃者は悪意ある Skill を通じて自動取引をトリガーすることさえ可能です。
したがって、Web3 シナリオにおいて、AI Agent を資産制御システムと完全に結合することは、非常に高いリスクを伴う設計です。より安全なアプローチは、Agent に取引提案や未署名の取引データの生成のみを担当させ、実際の署名プロセスは独立したウォレットや人手による確認で行うことです。また、アドレスの評判検知、AML（マネーロンダリング防止）リスク管理、取引シミュレーションなどのメカニズムを併用することで、自動取引に起因するリスクを一定程度まで軽減できます。
7. 高権限実行に起因するシステムレベルのリスク
多くの AI Agent は実際のデプロイメントにおいて、ローカルファイルシステムへのアクセス、シェルコマンドの実行、さらには Root 権限での実行など、高いシステム権限を持っています。もし Agent の挙動が乗っ取られた場合、その影響範囲は単一アプリケーションをはるかに超える可能性があります。
SlowMist は、OpenClaw を Telegram などのインスタントメッセージングソフトと連携させ、リモート制御を実現するテストを行ったことがあります。もし制御チャネルが攻撃者に掌握された場合、Agent は任意のシステムコマンドの実行、ブラウザデータの読み取り、ローカルファイルへのアクセス、他のアプリケーションの制御などを行う可能性があります。プラグインエコシステムおよびツール呼び出し能力と相まって、こうした Agent は、ある意味で「スマート型遠隔制御ツール」としての特徴を既に備えていると言えます。
総合的に見て、AI Agent のセキュリティ脅威は、もはや従来のソフトウェア脆弱性に限定されるものではなく、モデルとのインタラクション層、プラグインサプライチェーン、実行環境、資産操作層など、複数の次元にまたがっています。攻撃者は、プロンプトを介して Agent の挙動を操ることも可能ですし、悪意ある Skills や依存パッケージをサプライチェーン層にバックドアとして埋め込み、さらに高権限の実行環境で攻撃の影響を拡大させることも可能です。Web3 シナリオでは、オンチェーン操作の不可逆性および実際の資産価値に関わる特性ゆえに、こうしたリスクはさらに拡大します。したがって、AI Agent の設計および利用においては、従来のアプリケーションセキュリティ戦略のみに頼っていては、新しい攻撃面を十分にカバーできません。権限制御、サプライチェーンガバナンス、取引セキュリティメカニズムなど、より体系的なセキュリティ対策体制を構築する必要があります。
三、AI Agent 取引セキュリティ実践｜Bitget
AI Agent の能力が強化されるにつれ、その役割は単なる情報提供や意思決定支援にとどまらず、システム操作やオンチェーン取引の実行といった直接的なアクションへと拡大しています。暗号資産取引の現場では、この変化が特に顕著です。多くのユーザーが、AI Agent を市場動向分析、戦略実行、自動取引に活用し始めています。Agent が取引インターフェースを直接呼び出し、アカウント資産にアクセスして自動注文を出すことができるようになった今、そのセキュリティ課題は「システムのセキュリティリスク」から「実際の資産リスク」へと一段と深化しています。AI Agent を実際に取引に使う際、ユーザーは自身のアカウントおよび資金をいかに守るべきでしょうか？
この観点から、本節では Bitget セキュリティチームが、取引プラットフォームにおける実務経験をもとに、アカウントセキュリティ、API 権限管理、資金の分離、取引監視など、AI Agent を用いた自動取引において特に注目すべきセキュリティ戦略を体系的に紹介します。
1. AI Agent 取引シナリオにおける主なセキュリティリスク
2. アカウントセキュリティ
AI Agent の登場により、攻撃経路が変わりました：
- あなたのアカウントにログインする必要はありません——API キーを入手すれば十分です
- あなたが気づく必要はありません——Agent は 7×24 時間自動稼働するため、異常な操作は数日間にわたって継続する可能性があります
- 出金する必要はありません——プラットフォーム内で直接取引を行い、資産をすべて失わせるだけでも、攻撃の目的は達成されます
API キーの作成、変更、削除はすべて、ログイン済みのアカウントから行う必要があります——アカウントが乗っ取られれば、API キーの管理権も同時に失われます。アカウントのセキュリティ水準は、API キーのセキュリティ上限を直接決定します。
あなたがすべきこと：
- SMS（SIM カードは乗っ取り可能）ではなく、Google Authenticator を主な二要素認証（2FA）として有効化する
- パスキー（Passkey）によるパスワード不要ログインを有効化：FIDO2/WebAuthn 標準に基づき、公開鍵・秘密鍵暗号化で従来のパスワードを代替。フィッシング攻撃はアーキテクチャレベルで無効化されます
- フィッシング防止コードを設定する
- 定期的にデバイスマネージャーを確認し、見知らぬデバイスを即座に切断してパスワードを変更する
3. API セキュリティ
AI Agent 自動取引アーキテクチャにおいて、API キーは Agent の「実行権限証明書」に相当します。Agent 自体はアカウントの制御権を直接保持しておらず、実行可能なすべての操作は、API キーに付与された権限範囲に依存します。したがって、API 権限の境界線は、Agent が何ができるかを決めると同時に、セキュリティインシデント発生時の損失拡大範囲も決定します。
権限設定マトリクス——最小権限原則、利便性重視の権限ではありません：
多くの取引プラットフォームでは、API キーに対して複数のセキュリティ制御メカニズムがサポートされています。これらを適切に活用すれば、API キーの不正使用リスクを大幅に低減できます。代表的なセキュリティ設定の推奨事項は以下の通りです：
ユーザーが犯しがちな誤り：
- メインアカウントの API キーをそのまま Agent の設定に貼り付け——メインアカウントの全権限が完全に暴露されます
- 業務タイプを「すべて選択」して利便性を優先——実際にはすべての操作範囲が開放されます
- パスフレーズ（Passphrase）を設定していない、あるいはアカウントパスワードと同じものを設定している
- API キーをコード内にハードコードし、GitHub に公開してしまい、3 分以内にクローラーに発見・収集されます
- 1 つのキーを複数の Agent やツールに同時に許可——どれか 1 つが侵害されれば、すべてが完全に暴露されます
- キーが漏洩した後に即座に無効化しない——攻撃者はこの猶予期間を継続的に悪用します
キーのライフサイクル管理：
- API キーは 90 日ごとにローテーションし、古いキーは即座に削除する
- Agent を停止する際には、対応するキーを即座に削除し、残存する攻撃面を残さない
- 定期的に API 呼び出し履歴を確認し、見知らぬ IP アドレスや異常な時間帯のアクセスを発見した場合は即座に無効化する
4. 資金セキュリティ
攻撃者が API キーを入手した後にどれだけの損害を及ぼせるかは、そのキーが操作可能な金額に依存します。したがって、AI Agent の取引アーキテクチャを設計する際には、アカウントセキュリティおよび API 権限制御に加えて、資金の分離メカニズムを導入し、潜在的なリスクに対する明確な損失上限を設定する必要があります。
サブアカウント分離メカニズム：
- Agent 専用のサブアカウントを作成し、メインアカウントと完全に分離する
- メインアカウントから、Agent が実際に必要とする金額のみを振り込む——全資産ではない
- たとえサブアカウントのキーが盗まれても、攻撃者が操作可能な最大金額＝サブアカウント内の資金であり、メインアカウントは影響を受けません
- 複数の Agent 戦略にはそれぞれ異なるサブアカウントを割り当て、相互に分離する
資金パスワードを第二のロックとして活用：
- 資金パスワード（Fund Password）はログインパスワードと完全に分離されており、たとえアカウントにログインされても、資金パスワードがなければ出金を実行できません
- 資金パスワードとログインパスワードは異なるパスワードに設定する
- 出金ホワイトリストを有効化：あらかじめ登録されたアドレスのみが出金可能。新規アドレスは 24 時間の審査期間が必要
- 資金パスワードを変更すると、システムが自動的に出金を 24 時間凍結——これはあなたのための保護機能です
5. 取引セキュリティ
AI Agent 自動取引のシナリオでは、セキュリティ問題は単発の異常行動として表れるのではなく、システムが継続的に稼働する過程で徐々に進行する可能性があります。したがって、アカウントセキュリティおよび API 権限制御に加えて、継続的な取引監視および異常検知メカニズムを確立し、問題の初期段階で早期に検出し介入することが不可欠です。
必須となる監視体制：
異常サインの識別——以下のような状況が発生した場合は、直ちに停止して確認してください：
- Agent が長期間何も操作していないのに、アカウントに新規注文やポジションが発生している
- API 呼び出しログに、Agent のサーバー IP 以外からのリクエストが記録されている
- 設定したことがない取引ペアの約定通知を受信した
- アカウント残高に説明できない変動が生じている
- Agent が繰り返し「実行するにはさらに権限が必要」と表示する——まず理由を突き止め、その後に権限付与を判断する
Skill およびツールの出所管理：
- 公式がリリースし、審査済みのチャネルから提供される Skill のみをインストールする
- 出所不明または未検証のサードパーティ拡張機能のインストールを避ける
- 定期的にインストール済みの Skill リストをレビューし、不要になったものは削除する
- コミュニティで配布される「強化版」「日本語化版」などの Skill には注意——非公式版はすべてリスクです
6. データセキュリティ
AI Agent の意思決定は、大量のデータ（アカウント情報、保有ポジション、取引履歴、市場動向、戦略パラメータなど）に依存します。こうしたデータが漏洩または改ざんされた場合、攻撃者はあなたの戦略を推測したり、取引行動を操作したりする可能性があります。
あなたがすべきこと
- 最小データ原則：Agent には取引実行に絶対に必要なデータのみを提供する
- 機密データの匿名化：ログやデバッグ情報には、完全なアカウント情報、API キーなどの機密データを出力させない
- 完全なアカウントデータをパブリックな AI モデル（例：パブリック LLM API）にアップロードしない
- 可能であれば、戦略データとアカウントデータを分離する
- Agent による取引履歴データのエクスポートを無効化または制限する
ユーザーのよくある誤り
- 完全な取引履歴を AI にアップロードし、「戦略を最適化してくれ」と依頼する
- Agent のログに API キー／シークレットを出力する
- 公開フォーラムに取引記録のスクリーンショット（注文 ID、アカウント情報含む）を貼り付ける
- データベースのバックアップを AI ツールにアップロードして分析させる
7. AI Agent プラットフォーム層のセキュリティ設計
ユーザー側のセキュリティ設定に加えて、AI Agent 取引エコシステムの安全性は、プラットフォーム層のセキュリティ設計に大きく依存します。成熟した Agent プラットフォームは、アカウント分離、API 権限制御、プラグイン審査、基本的なセキュリティ機能など、多角的な防護メカニズムを体系的に構築し、ユーザーが自動取引システムを利用する際の全体的なリスクを低減する必要があります。
実際のプラットフォームアーキテクチャでは、一般的なセキュリティ設計は以下の通りです。
1．サブアカウント分離システム
自動取引環境では、プラットフォームは通常、異なる自動化システムの資金および権限を分離するためのサブアカウントまたは戦略アカウントシステムを提供します。この方法により、ユーザーは各 Agent や取引戦略に独立したアカウントおよび資金プールを割り当てることができ、複数の自動化システムが同一アカウントを共有することによるリスクを回避できます。
2．細かい粒度の API 権限設定
AI Agent のコア操作は API インターフェースに依存するため、プラットフォームの API 権限設計では、取引権限の細分化、IP ソース制限、追加のセキュリティ検証メカニズムなど、細かい粒度での制御が通常サポートされます。このような権限モデルにより、ユーザーは Agent にタスク遂行に必要な最小限の権限範囲のみを付与できます。
3．Agent プラグインおよび Skill の審査メカニズム
一部のプラットフォームでは、プラグインや Skill の公開・登録プロセスに審査メカニズム（コード審査、権限評価、セキュリティテストなど）を設けており、悪意あるコンポーネントがエコシステムに流入するリスクを低減しています。セキュリティの観点からは、こうした審査メカニズムは、プラグインサプライチェーンにプラットフォームレベルのフィルターを追加するものであり、ユーザー自身もインストールする拡張機能に対して基本的なセキュリティ意識を維持する必要があります。
4．プラットフォームの基本セキュリティ機能
Agent 固有のセキュリティメカニズムに加えて、取引プラットフォーム自体のアカウントセキュリティ体制も、Agent ユーザーに大きな影響を与えます。例えば：
8. Agent ユーザーを標的とした新型詐欺
偽装カスタマーサポート
「あなたの API キーにはセキュリティリスクがあります。すぐに再設定してください。」と伝え、フィッシングリンクを送りつけます。
→ 公式は、API キーを求めるためにユーザーに直接メッセージを送ることはありません。
投毒 Skill パッケージ
コミュニティで「強化版取引 Skill」が共有され、実行時に静かにあなたのキーを送信します。
→ 公式審査済みチャネルからのみ Skill をインストールしてください。
偽装アップグレード通知
「再承認が必要です」と表示され、クリックすると偽のページへ遷移します。
→ メールのフィッシング防止コードを確認してください。
プロンプトインジェクション攻撃
市場データ、ニュース、K ラインの注釈などに命令を埋め込み、Agent に意図しない操作を実行させます。
→ サブアカウントの資金上限を設定しておくと、万が一インジェクションを受けても、損失は明確な上限内で抑えられます。
「セキュリティ診断ツール」を装った悪意あるスクリプト
「あなたのキーが漏洩していないかチェックできます」と謳い、実際にはキーを窃取します。
→ 公式プラットフォームが提供するログまたはアクセス記録機能を用いて、API 呼び出し状況を確認してください。
9. 異常時の調査手順
何らかの異常を発見した場合
↓
直ちに疑わしい API キーを無効化または削除する
↓
アカウントの異常注文／ポジションを確認し、キャンセル可能なものは即座にキャンセルする
↓
出金記録を確認し、資金がすでに送金されたかを確認する
↓
ログインパスワードおよび資金パスワードを変更し、すべてのログイン済みデバイスを強制ログアウトする
↓
プラットフォームのセキュリティサポートに連絡し、異常が発生した時間帯および操作記録を提供する
↓
キー漏洩の経路を調査（コードリポジトリ／設定ファイル／Skill のログなど）
基本原則：疑わしい事象が発生した際には、まずキーを無効化し、その後原因を調査すること。この順序は絶対に逆にしてはいけません。
四、提言およびまとめ
本レポートでは、SlowMist および Bitget が実際の事例とセキュリティ研究を踏まえ、現在の Web3 シナリオにおける AI Agent の典型的なセキュリティ課題について分析しました。具体的には、Agent の挙動を操作するプロンプトインジェクションのリスク、プラグインおよび Skill エコシステムにおけるサプライチェーンリスク、API キーおよびアカウント権限の乱用問題、自動実行に起因する誤操作および権限の拡大といった潜在的脅威です。こうした問題は、単一の脆弱性が原因ではなく、Agent のアーキテクチャ設計、権限制御戦略、実行環境のセキュリティが複合的に作用して生じるものです。
したがって、AI Agent システムを構築または利用する際には、全体的なアーキテクチャレベルでセキュリティ設計を行うべきです。例えば、Agent に API キーおよびアカウント権限を割り当てる際には最小権限原則を遵守し、不要な高リスク機能は無効化する；ツール呼び出し層においては、プラグインおよび Skill に対する権限分離を実施し、単一コンポーネントがデータ取得・意思決定生成・資金操作のすべての能力を兼ね備えないようにする；Agent が重要な操作を実行する際には、明確な行動境界およびパラメータ制限を設定し、必要に応じて人手による確認メカニズムを導入して、自動実行に起因する不可逆的リスクを低減する。また、Agent の実行に必要な外部入力については、適切なプロンプト設計および入力分離メカニズムを用いてプロンプトインジェクション攻撃を防ぎ、外部コンテンツをシステム命令として直接モデル推論プロセスに組み込まないようにする必要があります。実際のデプロイおよび運用フェーズでは、API キーおよびアカウントのセキュリティ管理を強化し、必要な権限のみを有効化し、IP ホワイトリストを設定し、キーを定期的にローテーションし、コードリポジトリや設定ファイル、ログシステム内に機密情報を平文で保存しないようにする必要があります。開発プロセスおよび運用環境においては、プラグインのセキュリティ審査、ログ内の機密情報制御、行動監視および監査メカニズムなどの対策を講じることで、設定情報の漏洩、サプライチェーン攻撃、異常操作によるリスクを低減できます。
より広域的なセキュリティアーキテクチャの観点から、SlowMist は AI および Web3 エージェントのシナリオに特化した多層セキュリティガバナンスの考え方を関連研究において提示しています。この考え方は、高権限環境におけるエージェントのリスクを体系的に低減するために、階層化された防護体制を構築するものです。このフレームワークでは、L1 セキュリティガバナンスが、開発ツール、Agent フレームワーク、プラグインエコシステム、実行環境をカバーする包括的なセキュリティ基準を基礎とし、AI ツールチェーンを導入する際の統一的な方針源および監査基準をチームに提供します。その上に、L2 では Agent の権限境界の収束、ツール呼び出しの最小権限制御、および重要な行動に対する人間と機械の共同確認メカニズムを設けることで、高リスク操作の実行範囲を効果的に制限します。さらに、L3 では、URL、依存リポジトリ、プラグインの出所などの外部リソースを事前検査することで、悪意あるコンテンツやサプライチェーン投毒が実行チェーンに侵入する確率を低減します。オンチェーン取引や資産操作を伴うシナリオでは、L4 でオンチェーンリスク分析および独立署名メカニズムを導入し、追加のセキュリティ分離を実現します。これにより、Agent は取引を構築できますが、秘密鍵には直接アクセスできません。これによって、高価値資産操作に起因するシステム全体のリスクを軽減します。最終的に、L5 では継続的な巡回点検、ログ監査、定期的なセキュリティ再評価などの運用メカニズムを通じて、「実行前には事前検査可能、実行中には制約可能、実行後には再検討可能」な閉ループ型セキュリティ能力を構築します。この階層型セキュリティアプローチは、単一の製品またはツールではなく、AI ツールチェーンおよびエージェントエコシステム全体を対象としたセキュリティガバナンスのフレームワークであり、その核心的な目標は、開発効率および自動化能力を著しく低下させることなく、体系的な戦略、継続的な監査、セキュリティ能力の連携を通じて、持続可能で、監査可能で、進化可能な Agent セキュリティ運用体制をチームが構築できるようにすることにあります。これにより、AI と Web3 の深層融合という変化の激しいセキュリティ課題に、より柔軟かつ効果的に対応できるようになります。
総括すると、AI Agent は Web3 エコシステムに高度な自動化および知能化の能力をもたらしましたが、そのセキュリティ課題もまた無視できません。システム設計、権限管理、運用監視など、多層にわたるセキュリティメカニズムを整備することで、AI Agent 技術の革新を推進しつつ、潜在的なリスクを効果的に低減することが可能です。本レポートが、開発者、プラットフォーム運営者、ユーザーの皆様が AI Agent システムを構築・利用する際の有益な参考資料となり、技術の発展を促進するとともに、より安全で信頼性の高い Web3 エコシステムの形成に貢献できれば幸いです。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
