Microsoftのセキュリティ部門が、12ヶ月にわたるエージェントAIシステムへのレッドチーミングを通じて新たに7つの失敗モードを特定し、実環境での攻撃急増を受けてリスク分類体系を大幅に更新した。

エージェントAIへの攻撃が「実害」のステージへ

これまでエージェントAIのセキュリティリスクは「将来の懸念」として扱われることが多かったが、状況は変わった。Microsoftのレッドチームによれば、実環境においてエージェントAIを標的にした攻撃が急増しており、もはや理論的なシナリオではない。

エージェントAIとは、目標を設定されると自律的にツールを呼び出し、複数のステップを踏んで課題を解決するシステムだ。Microsoft 365 CopilotやAzure AI Foundryで構築されるカスタムエージェントがその代表例で、メール処理・ドキュメント生成・コード実行・外部API呼び出しなど広範な操作を自律的にこなす。その「自律性」こそが新たな攻撃面を生んでいる。

新たに特定された7つの失敗モード

1. サプライチェーン侵害（Supply Chain Compromise）

エージェントが参照する外部ツール・ライブラリ・モデルが改ざんされるリスク。人間のコードと同様に、AIが呼び出すコンポーネントも検証が必要になった。

2. ゴールハイジャック（Goal Hijacking）

エージェントが処理中のデータや環境内の悪意ある入力によって、本来の目標から逸脱した行動を取らされる攻撃。プロンプトインジェクションの進化形と捉えるとわかりやすい。

3. 記憶の汚染（Memory Poisoning）

エージェントが参照する長期記憶やベクターデータベースに偽情報を埋め込み、将来の判断を歪める手法。RAG（Retrieval-Augmented Generation）を活用するシステムで特に危険。

4. クロスエージェント攻撃（Cross-Agent Attacks）

マルチエージェント構成において、あるエージェントを経由して別のエージェントを操作する攻撃。エージェント間の信頼モデルを悪用する。

5. 権限の過剰付与（Excessive Agency）

エージェントに必要以上の権限が与えられることで、誤動作や攻撃時の被害が拡大する。最小権限原則の適用がここでも必須になる。

6. ツールの誤用誘発（Tool Misuse Induction）

エージェントが持つツール（メール送信・ファイル操作・APIコールなど）を悪意ある入力によって不正に実行させる攻撃。

7. 観測回避（Observability Evasion）

エージェントの動作ログや監査証跡を意図的に回避・改ざんし、攻撃の痕跡を消す手法。

Microsoftが示す実践的な緩和策

レッドチームの知見をもとに、Microsoftはいくつかの具体的な対策を提示している：

  • 入力検証の厳格化：エージェントが処理するすべての外部入力（ユーザー入力・ツール出力・外部API応答）を信頼しない設計
  • 最小権限の徹底：エージェントへの権限付与はタスクに必要な最小限に留め、Just-In-Time（JIT）アクセスを活用する
  • エージェント間の信頼境界の明示：マルチエージェント環境では、エージェント同士が無制限に信頼し合わない設計にする
  • 可観測性の確保：すべてのエージェント動作を詳細にロギングし、異常行動を検知できる仕組みを入れる
  • サプライチェーン検証：エージェントが呼び出すツール・モデル・ライブラリの整合性を定期的に確認する

日本のエンジニア・IT管理者への影響

このレポートが示すリスクは、「エージェントAIを本番導入しているなら今すぐ対応が必要」というレベルの話だ。

日本企業でも、M365 Copilotのカスタムエージェントや、Azure AI Foundryを使った業務自動化の導入事例が急速に増えている。特に注意すべきは以下の点だ：

Non-Human Identities（NHI）の管理が急務：エージェントAIはサービスプリンシパルやマネージドIDとして動作する。これらの権限管理が甘いと、エージェントが侵害された際の被害が組織全体に及ぶ。Entra IDでのJITアクセス設定と定期的な権限棚卸しを実施すること。

社内RAGシステムの汚染対策：SharePointや社内ドキュメントをベースにしたRAG構成を持つ場合、そのナレッジベースへの不正書き込みが記憶汚染攻撃の起点になりうる。ドキュメントの書き込み権限と読み取り権限を分離し、変更監査ログを有効にする。

マルチエージェント設計時の信頼境界定義：複数エージェントを連携させるフローでは、各エージェントが受け取る入力の信頼レベルを設計段階で明示する。「上位エージェントからの指示だから信頼する」という設計は危険だ。

筆者の見解

このレポートは、Microsoftのセキュリティ組織が1年間の実戦的なレッドチーミングから得た知見をまとめたもので、内容の質は高い。エージェントAIのリスクを「ベンダーがよく言う将来の脅威」ではなく「今起きている問題」として体系化した点は、現場にとって価値がある。

私がここで強調したいのは、このリスクはCopilotだけの話ではないということだ。Azure AI FoundryでカスタムエージェントをPythonで実装していても、LangChainや他のフレームワークを使っていても、エージェントが外部ツールを呼び出す構造を持っている時点で同じリスクを抱えている。

とりわけ気になるのはNHIの権限管理だ。「エージェントを動かすためにグローバル管理者権限のサービスプリンシパルを使う」という実装を、今もゼロにはなっていないと思う。エージェントAIの登場で、Non-Human Identitiesの数は今後さらに爆発的に増える。ここを甘く見ていると、エージェントが侵害された際の被害範囲がそのまま組織全体になる。

Microsoftにはこのような知見を、ドキュメントだけでなく製品側の「デフォルト設定」に反映してほしい。最小権限でエージェントを動かすのが「難しい選択肢」ではなく「一番簡単な選択肢」になるような設計を、Foundryやその周辺ツールで実現できるはずだ。力があるからこそ、そこまで踏み込んでほしいと思う。

出典: この記事は Updating the taxonomy of failure modes in agentic AI systems: What a year of red teaming taught us の内容をもとに、筆者の見解を加えて独自に執筆したものです。