AIエージェントはどのように企業の新たなセキュリティリスクを生み出すのか：ツール呼び出しと権限境界を理解する

2026年11月3日、Binanceは10月29日に発生したセキュリティインシデントに関する暫定調査声明を公開しました。同声明によると、攻撃者はマルウェアを使ってエンジニアのデバイスを侵害し、内部AIツールを利用してアクセス範囲をさらに拡大しました。声明では、最終的に内部ウォレット署名サービスへの不正アクセスに至り、約63.4億ドル相当のデジタル資産に影響が及んだとされています。ただし、内部AIツールの完全なアーキテクチャは開示されておらず、大規模言語モデル自体の脆弱性が攻撃に悪用されたことや、プロンプトインジェクションが関与したことも確認されていません。

このインシデントは、企業のセキュリティに関する重要な問いを提起しています。AI Agentがより多くの内部ツールや機密システムにアクセスできる場合、企業は情報処理に関する権限と、実際の操作権限をどのように区別すべきでしょうか。本記事では、AI Agentによるツール呼び出しの仕組みから始め、権限境界、プロンプトインジェクション、認証情報の管理、ラテラルムーブメントのリスクについて解説し、企業が導入できるセキュリティ対策を分析します。

主なポイント

• AI Agentはテキストを生成するだけではありません。ツール呼び出しを通じて、コードの実行、ファイルの読み取り、APIへのアクセス、企業内部システムの操作なども行う場合があります。

• 2026年11月3日に公開されたBinanceの暫定調査声明では、攻撃者が侵害したエンジニアのデバイスと内部AIツールを利用し、他のエンジニアのデバイスや権限へのアクセスを拡大したとされています。

• AI Agentにおける主要なセキュリティリスクの一つは、外部環境や信頼性の低い環境から得た情報を、実際の実行権限を伴うアクションに変換してしまうことです。

• プロンプトインジェクション、悪意のあるツール出力、過剰な権限、認証情報の漏えいは、相互に影響し合って被害を拡大させる可能性があります。ただし、AIツールが関与する攻撃がすべてプロンプトインジェクション攻撃であるとは限りません。

• 企業はAI Agentを、固有のIDと権限を持つソフトウェア実行主体として扱う必要があります。最小権限、ツールの分離、操作承認、監査メカニズムによってリスクを管理することが重要です。

AI Agentは従来のAIチャットボットとどう違うのか？

従来のAIチャットボットは、主にユーザー入力を受け取り、テキスト形式の回答を生成することでタスクを完了します。モデルがコードを提示したり、ファイルを分析したり、操作手順を説明したりできる場合でも、通常は実際の実行環境に接続されていなければ、企業のデータベースを直接変更したり、アプリケーションをデプロイしたり、内部サービスを呼び出したりすることはできません。

AI Agentとの違いは、モデルが生成した判断を外部ツールに接続できる点にあります。例えば、開発者はAgentに、コード検索、ターミナル実行、データベースクエリ、Gitリポジトリ管理などのツールを設定できます。ユーザーがタスクを送信すると、Agentはまず関連ファイルを取得し、次にツールを呼び出して情報を収集し、その結果に基づいて次の処理を判断できます。適切な権限が付与されていれば、Agentはコードコミットの作成、テストの実行、デプロイプロセスの開始まで行う場合があります。

このモデルによって、AI Agentは単なる情報生成ツールから、一定の操作能力を持つソフトウェアシステムへと変わります。Agent自体が独立した管理者権限を持っていない場合でも、ユーザー認証、サービスアカウント、API Token、その他のID認証情報を通じて外部システムにアクセスできるようになります。

したがって、AI Agentのセキュリティは、モデルの回答が正確かどうかだけでは評価できません。モデルが生成した内容に明らかな誤りがない場合でも、ツール権限の設定が不適切であれば、Agentはユーザーの想定を超える操作を実行する可能性があります。企業はAIが何を生成できるかだけでなく、何を読み取れるか、何を呼び出せるか、そして実際にシステムの状態を変更できる操作はどれかにも注目する必要があります。

AI Agentはどのようにツールを呼び出すのか？

ツール呼び出しは、AI Agentが外部システムと連携するための重要な仕組みです。通常、開発者は利用可能なツールの名称、機能説明、パラメータ構造をモデルに提供します。モデルは現在のタスクに基づいて、特定のツールを呼び出すかどうかを判断します。実際の実行は、一般にAgentのランタイム環境またはアプリケーションが担い、その後、ツールの結果がさらなる処理のためにモデルへ渡されます。

例えば、企業内部の開発用Agentは、コードリポジトリの読み取り、エラーログの検索、テストの実行ができる場合があります。ユーザーがサービスの問題を調査するよう依頼すると、Agentはログ検索ツールを呼び出して問題箇所を特定し、関連コードを読み取り、その後に修正案を生成できます。企業がコードの書き込みやデプロイの権限も付与している場合、Agentは分析支援から実際の操作の実行へ移行する可能性があります。

ツール呼び出しのリスクは、主に2つの領域から生じます。

• Agentが過剰な実行権限を持つ可能性があります。例えば、ログの読み取りだけが必要なのに、本番環境の設定を変更する権限まで持っている場合があります。

• Agentが外部ウェブページ、コードコメント、メール、ツール出力などから信頼できないコンテンツを処理する可能性があります。システムがこのコンテンツとユーザーによる実際の承認を適切に区別できない場合、外部情報が後続のツール呼び出しに影響を与える可能性があります。

つまり、企業はモデルが生成したツール呼び出しを、単純に信頼できる操作として扱うことはできません。機密データやシステム変更に関わるすべてのツール呼び出しには、独立した権限検証が必要です。モデルは実行リクエストを送信できますが、そのリクエストを許可するかどうかは、明示的なセキュリティポリシーに基づいて判断すべきです。

AI Agentはなぜ企業の攻撃対象領域を拡大させるのか？

従来の企業セキュリティシステムは、一般に従業員のID、サーバー、アプリケーション、ネットワーク境界を中心にアクセス制御を構築しています。従業員ごとにシステム権限は異なり、重要なサービスでは、個別の認証情報やネットワークルールによってアクセスを制限する場合があります。AI Agentが企業システムに接続されると、新たな自動アクセス経路が実質的に形成されます。

例えば、開発用AgentがGitリポジトリ、社内ナレッジベース、クラウドプラットフォーム、タスク管理システムに同時に接続する場合があります。複数のシステムにまたがるタスクを完了するために、開発者は複数のAPI Tokenやサービスアカウントを設定することがあります。これらの認証情報が厳格に制限されていない場合、Agentのランタイム環境または関連するIDを掌握した攻撃者は、これらのアクセス機能を利用してより多くのシステムに到達できる可能性があります。

もう一つの問題は、操作のスピードです。従業員が一連の操作を完了するには、通常、複数のプラットフォームに手動でログインする必要があります。一方、AI Agentは短時間のうちにツールを連続して呼び出せます。自動化自体が安全でないわけではありません。しかし、レート制限、異常検知、高リスク操作に対する承認がなければ、誤った指示や悪意のある指示が短時間で実行される可能性があります。

したがって、AI Agentはソフトウェアインターフェースの数だけでなく、異なるシステムをつなぐ権限関係も増加させます。企業は、各Agentがアクセスできるリソース、異なるセキュリティドメインをまたいでアクセスできるかどうか、低リスクのツールから高リスクのシステムへ至る経路が存在するかどうかを評価する必要があります。

プロンプトインジェクションはなぜAI Agentのツール呼び出しに影響を与えるのか？

プロンプトインジェクションとは、モデルが読み取る可能性のあるデータに攻撃者が命令のような内容を埋め込み、モデルが本来実行すべきタスクを変更させようとする攻撃です。通常のチャットボットでは、このような攻撃によって誤った回答や情報漏えいが生じる可能性があります。ツール呼び出し機能を持つAI Agentの場合、実際の操作にも影響が及ぶ可能性があります。

例えば、企業がコードリポジトリ内の課題報告をAI Agentで自動的に整理しているとします。攻撃者が報告内容を操作できる場合、システムメンテナンス要件を装った指示を挿入し、Agentに追加ファイルの読み取りや無関係なツールの呼び出しを促す可能性があります。本当のリスクは、Agentが報告を読み取ることではなく、報告内の信頼できないコンテンツを実行権限を伴う指示として扱うかどうかにあります。

このような攻撃は、一般に間接的プロンプトインジェクションと呼ばれます。攻撃者はAgentのユーザーに直接コマンドを送る必要はありません。ウェブページ、ドキュメント、コードコメント、検索結果、ツール出力などを通じて、Agentに影響を与えることができます。OWASPは、プロンプトインジェクション、ツールの悪用、権限昇格、機密情報の開示を、AI Agentに関する重要なセキュリティリスクとして挙げています。

ただし、プロンプトインジェクションは従来型のマルウェア攻撃と区別する必要があります。攻撃者がすでに悪意のあるコードによってエンジニアのコンピューターを掌握し、その後、既存の認証情報を使って内部システムにアクセスした場合、攻撃経路にAIツールが関与していたとしても、必ずしもプロンプトインジェクションが発生したことを意味しません。両方のメカニズムが同時に現れることはありますが、技術的には異なるものです。

Binanceのセキュリティインシデントから、AIツールと権限管理に関してどのようなリスクが明らかになったのか？

Binanceは、2026年11月3日に公開した暫定調査声明で、従業員のデバイスの侵害から内部ウォレット署名システムの悪用に至る多段階の攻撃を明らかにしました。同声明によると、9月、攻撃者は偽の採用面接を通じて、ソフトウェアエンジニアに悪意のあるコードを含むリポジトリをダウンロードさせました。悪意のあるコードは環境設定中に実行され、開発ツールのコンポーネントを置き換えるなどの手法によって、攻撃者が制御する通信チャネルを確立しました。

10月20日、攻撃者は侵害したエンジニアのコンピューターと内部AIツールを利用し、他のエンジニアのデバイスを制御しました。また、ウォレット運用担当エンジニアのデバイスから、コンテナのデプロイ権限を持つTokenを発見しました。10月29日、攻撃者は関連する認証情報を使ってコンテナをデプロイし、悪意のあるスクリプトを実行した結果、最終的にウォレット署名の操作プロセスに到達しました。

セキュリティアーキテクチャの観点から見ると、このインシデントには少なくとも3つの検討すべき問題が表れています。第一に、開発者のデバイスが高価値の内部システムへの侵入口になる可能性があります。第二に、内部AIツール、デプロイ環境、従業員の権限が接続されている場合、攻撃者はこれらの接続を悪用してアクセス範囲を拡大できる可能性があります。最後に、高リスクの操作に対する独立した権限検証が不十分であれば、攻撃者は取得した内部権限を、実際の資産操作を行う能力へと変換できる可能性があります。

Binanceは内部AIツールの具体的な実装を開示していない点を強調することが重要です。そのため、これらのツールが自律的な計画能力を持つAI Agentであったかどうか、また攻撃にMCP、プロンプトインジェクション、特定モデルの脆弱性が関与していたかどうかを確認することはできません。このインシデントは、AIツールが複雑な攻撃経路の一部となる可能性を示していますが、それだけでAI Agentが攻撃の根本原因であったことを証明するものではありません。

AI Agentの権限境界とは何か？なぜ最小権限が重要なのか？

権限境界とは、ソフトウェア実行主体がアクセスできるリソース、実行できる操作、追加の権限を取得できる条件を定義するものです。AI Agentの場合、権限境界にはモデル自体だけでなく、Agentのランタイム環境、ツールインターフェース、ユーザーID、サービスアカウント、外部システムも関係します。

最小権限の原則では、システムは現在のタスクを完了するために必要な権限だけを付与します。例えば、サーバーログの分析を担当するAgentは、通常、特定のログデータにアクセスできれば十分です。データベースの削除、本番環境の変更、デジタル資産の移転まで自動的に実行できるべきではありません。タスク上、高リスクの操作が本当に必要な場合、Agentは独立した承認メカニズムを通じて一時的な権限を取得すべきです。

OWASPは、大規模言語モデルを利用するアプリケーションにおける重要なリスクとして、過剰な自律性を挙げています。核心となる問題は、モデルがツール呼び出し機能を持つことではなく、システムがモデルに不要な機能、過剰な権限、または制約のない自律的な操作能力を与えていることです。モデルが誤った入力、プロンプトインジェクション、悪意のあるツール結果の影響を受けた場合、これらの権限によって被害が拡大する可能性があります。

したがって、企業は危険な操作を実行しないようシステムプロンプトでAgentに指示するだけでなく、信頼できる実行環境に権限チェックを配置する必要があります。モデルが誤って機密ツールへのアクセスを要求した場合でも、バックエンドサービスは、ID、リソースの範囲、操作の種類に基づいて不正なリクエストを拒否できるようにすべきです。

MCPなどのツール接続プロトコルは、どのような新たなセキュリティ課題を生むのか？

Model Context Protocol（MCP）は、AIアプリケーションを外部ツールやデータリソースに接続するためのオープンプロトコルです。MCPを通じて、開発者はツールごとにまったく異なる統合方法を設計することなく、AI Agentをファイルシステム、データベース、コードリポジトリなどのサービスに接続できます。

この標準化された接続方式は開発効率を高められる一方で、Agentが複数の外部システムにより容易にアクセスできることも意味します。企業がMCP Server、ツール定義、アクセス権限を管理しなければ、過剰なツール権限、悪意のあるツール説明、侵害された第三者サービス、機密情報の意図しない露出などの問題に直面する可能性があります。

例えば、開発用Agentにはコードリポジトリの読み取りが必要でも、企業の決済システムへのアクセスは必要ない場合があります。両方の種類のツールが同じランタイム環境に設定され、高い権限を持つ共有認証情報を使用していると、もともと開発を支援する目的のAgentが、タスクとは無関係な操作能力を得る可能性があります。

OWASPは、AIコーディングツールに接続されたMCP Serverについて監査メカニズムを構築し、呼び出し可能なツールを制限し、ツール定義に悪意のある指示が含まれていないか確認することを推奨しています。コードを実行するAgentでは、サンドボックス化、ネットワークアクセス制限、独立した認証情報管理などの対策も使用すべきです。

MCP自体がセキュリティ脆弱性を構成するわけではありません。評価すべきなのは、プロトコル接続後のツール実装、認証、権限設定、そして外部コンテンツがAgentの動作に与える影響です。

企業はAI AgentのIDとアクセス権限をどのように保護すべきか？

企業はまず、AI Agentの識別可能で監査可能なIDシステムを構築すべきです。従来のアプリケーションは通常、サービスアカウントやAPI Keyを使って他のシステムにアクセスします。しかし、AI Agentの操作には、ユーザーによる承認、自動化されたタスク、複数のツールが同時に関与する可能性があります。そのため企業は、ユーザーのID、AgentのID、実際の実行権限を明確に区別する必要があります。

例えば、従業員がAgentに社内レポートの取得を依頼したからといって、Agentがその従業員にはアクセス権のない他のファイルをサービスアカウントで読み取れることを意味するわけではありません。適切な認証設計では、リクエストしたユーザーが対象リソースへのアクセス権を持っているかどうかと、Agentが該当する操作を実行できるかどうかの両方を検証する必要があります。これにより、プロキシサービスがより高い権限を持っていることを理由に、Agentが既存のアクセス制御を迂回することを防ぎやすくなります。

2026年2月、National Institute of Standards and Technology（NIST）傘下のNational Cybersecurity Center of Excellence（NCCoE）は、ソフトウェアおよびAI AgentのIDと認証に関するコンセプトペーパーを公開しました。同ペーパーでは、AgentのID認識、認証、承認、一時的な認証情報、委任された権限、監査などの問題が取り上げられています。これは、AI Agentのセキュリティがモデル出力の制御から、IDおよびアクセス管理の包括的なフレームワークへと広がっていることを示しています。

実際の導入では、企業は短期間のみ有効なアクセス認証情報を使用し、権限を特定のタスク、リソース、期間に制限できます。本番環境へのデプロイ、金融操作、権限変更などの高リスク活動には、独立した承認と二次検証も必要です。これにより、Agentのランタイム環境が侵害された場合でも、攻撃者が長期間有効な高権限の認証情報を直接取得することを防ぎやすくなります。

企業はAI Agentのツール呼び出しに伴うセキュリティリスクをどのように軽減できるか？

企業は、ツール権限、実行環境、機密操作、動作監視の4つの領域で保護対策を構築できます。

• 企業は、業務上の要件に基づいてAgentが使用できるツールを制限すべきです。情報の取得だけを行うAgentに任意のコード実行機能は必要なく、コードレビューに使用するAgentに本番環境へのデプロイ権限を自動的に付与すべきでもありません。書き込み機能を持つツールについては、ファイルパス、データベーステーブル、API操作の種類、アクセス範囲をさらに制限できます。

• 高リスクのツールは、分離された環境で実行すべきです。コード実行、第三者パッケージのインストール、外部ウェブページの処理では、信頼できないコンテンツが持ち込まれる可能性があります。そのため企業は、コンテナやその他のサンドボックス技術を利用して、ファイルシステム、ネットワーク、システムリソースへのアクセスを制限できます。分離によって、単一のツールへの攻撃が他のシステムに影響を及ぼす可能性を低減できます。

• 企業は、取り消しが困難な操作について人による承認を必須にすべきです。重要なデータの削除、権限の変更、本番サービスのデプロイ、資産の移転などの操作は、Agentがタスクを合理的だと判断しただけで自動的に完了させるべきではありません。MicrosoftのAgent Frameworkセキュリティガイダンスでも、操作の影響、データの機密性、可逆性に基づいて、人による確認が必要かどうかを判断することが推奨されています。

• 最後に企業は、Agentが使用したツール、アクセスしたリソース、異常な権限リクエストの有無、実際の実行結果が承認されたタスクと一致しているかどうかを記録する、継続的な監査メカニズムを構築する必要があります。ツール呼び出しの失敗が繰り返される場合、異常なデータアクセスが発生した場合、短時間に大量の操作が行われた場合には、ルールベースの検知と行動分析を組み合わせて、潜在的なリスクを特定できます。

これらの対策によって、AI Agentのセキュリティリスクを完全に排除できるわけではありません。しかし、攻撃が成功した後の影響範囲を抑え、異常な動作が検知・対処される可能性を高めることができます。

Web3インフラにおいて、AI Agentのセキュリティが重要な問題になっているのはなぜか？

AI Agentとブロックチェーンインフラの組み合わせは、ツール呼び出しと権限管理を資産セキュリティにより直接的に関係させます。従来の企業環境では、Agentがコードを実行したり、メールを送信したり、データベースを変更したりする場合があります。Web3環境では、Agentがウォレットに接続し、オンチェーン資産を照会し、スマートコントラクトを呼び出し、トランザクションリクエストを開始する場合もあります。

例えば、オンチェーン資産を自動管理するAgentは、残高の照会、市場分析、ユーザー設定に基づく取引提案を行う必要がある場合があります。さらにトランザクション署名やスマートコントラクト呼び出しの機能も付与する場合、企業はどの操作を自動実行できるか、どの操作にユーザー確認が必要か、1回のトランザクション当たりの金額、対象資産の範囲、承認の有効期間をどのように制限するかを明確に定義する必要があります。

このプロセスでは、Session Keys、スマートアカウント、きめ細かな承認メカニズムによって、さまざまな形態の権限管理を実現できます。ただし、具体的なセキュリティは実装方法に依存します。Session Keysは特定の操作権限を一定の期間または範囲に制限でき、スマートアカウントはコントラクトルールを通じてトランザクションの動作を制限できます。それでも、承認条件が広すぎる場合、検証ロジックに欠陥がある場合、実行環境が侵害された場合には、セキュリティリスクが生じる可能性があります。

したがって、Web3 AI Agentの開発では、自動取引やオンチェーン決済の効率だけに注目すべきではありません。ID検証、権限委任、トランザクション承認、承認の取り消しにも対応する必要があります。実際の資産に接続されたAIシステムでは、セキュリティ境界をモデルの判断からツール呼び出し、トランザクションの構築、署名検証、オンチェーン実行に至る一連のプロセス全体にわたって設定すべきです。

結論

AI Agentは、企業による人工知能の利用方法を変えつつあります。モデルがコードリポジトリ、内部API、データベース、自動化ツールに接続されるにつれて、AIシステムは単なる情報処理の窓口ではなくなっています。実際の操作能力を持つソフトウェア実行主体へと変わりつつあります。

2026年11月3日に公開されたセキュリティインシデントに関するBinanceの暫定調査では、内部AIツールが複雑な攻撃経路の一部となった可能性が示されています。ただし、入手可能な情報だけでは、インシデントがAI Agentの脆弱性やプロンプトインジェクションによって直接引き起こされたことを証明するには不十分です。より重要な教訓は、企業が開発環境、自動化ツール、高権限システムの間に存在するアクセス関係を再評価する必要があるという点です。

今後、AI Agentのセキュリティは、モデルが悪意のある指示を識別できるかどうかだけでなく、企業が信頼できるID認証、最小権限、ツール分離、独立した承認メカニズムを構築できるかどうかにも左右されます。AIによる意思決定能力と実際の実行権限を適切に分離して初めて、企業は自動化の効率を高めながら、潜在的なリスクを管理できます。

FAQ

AI Agentはなぜ通常のチャットボットよりセキュリティリスクが高いのですか？

AI Agentは、ツール呼び出しを通じて企業データにアクセスしたり、コードを実行したり、システムを変更したりする可能性があります。テキストを生成するだけのチャットボットと比べて、誤動作や操作された動作が実際の操作上の結果につながる可能性があります。

AI Agentのツール呼び出しとは何ですか？

ツール呼び出しとは、AI Agentがタスクの要件に基づき、データベースの検索、ファイルの読み取り、APIの呼び出し、コードの実行などの操作を外部プログラムやサービスに依頼することです。

プロンプトインジェクションは必ずAI Agentを制御できますか？

必ずしもそうではありません。プロンプトインジェクションが成功するかどうかは、システム設計、モデルの動作、セキュリティ対策によって異なります。攻撃者がモデルの出力に影響を与えた場合でも、独立した権限検証によって不正なツール操作を防止できます。

Binanceのセキュリティインシデントは、AI Agentに脆弱性があることを証明していますか？

いいえ。Binanceの暫定調査では、攻撃経路に内部AIツールが関与していたことが確認されていますが、AI Agentの脆弱性やプロンプトインジェクションの存在を立証するのに十分な技術的証拠は開示されていません。

MCPはAI Agentのセキュリティリスクを高めますか？

MCPはAIアプリケーションによる外部ツールへの接続を支援しますが、主なセキュリティリスクは、ツールの実装、アクセス権限、信頼できないコンテンツの処理から生じます。適切な認証、ツールの監査、権限制限によって、これらのリスクを低減できます。

企業はAI Agentの権限をどのように制限すべきですか？

企業は、最小権限、タスクに限定した一時的な認証情報、独立した操作承認、サンドボックス分離、ツール呼び出しの監査を利用し、Agentが明示的に承認された操作だけを実行できるようにする必要があります。