2026.03.16 (更新: 2026.03.16 04:43)

AIエージェントにゼロトラストを適用する — OWASP Agentic Top 10と実装アプローチ

シ

シンジ

既にAIエージェントは「新しい労働主体」だそうです。となれば、人間にも適用されるゼロトラストなセキュリティ方針は、AIエージェントにも適用されるべきだということをMicrosoftさんが言い出したので、今日はそんなお話です。

IDCは2028年までにAIエージェントが13億に達すると予測しています（Microsoft 365 Blog「Microsoft Agent 365—The control plane for AI agents」2025年11月18日公開にて引用）。また、Fortune 500企業の80%以上がローコード/ノーコードツールで構築されたAIエージェントを利用していると報告されています（Microsoft Security Blog「80% of Fortune 500 use active AI agents」2026年2月10日公開）。

AIエージェントは、単なる補助ツールではなく、権限を持って業務フローを実行する「デジタル労働主体」として扱う必要が出てきています。Microsoftも、エージェントを人の管理に近い形で統制する方向を打ち出しています。

そして統制の対象であるならば、既存のIAM、監査、DLP、脅威検知、可観測性、つまりゼロトラストの枠組みをエージェントにも拡張することが求められます。

本記事では、まずAIエージェント時代の脅威モデル（OWASP）を整理し、次に必要な制御要件を導出した上で、その実装例としてMicrosoftのAgent Governance ToolkitとAgent 365を取り上げます。最後に、マルチベンダー環境での実務的な示唆を述べます。

AIエージェント時代の脅威モデル — OWASP Top 10 for Agentic Applications 2026

OWASPのGenAI Security Projectは、2025年12月9日に Top 10 for Agentic Applications（2026年版） を公開しました。100名以上の業界専門家がピアレビューに参加し、AIエージェント特有のリスクを10項目に整理したフレームワークです。

以下は、OWASP公式公開と周辺技術解説をもとに整理したリスク一覧です。正式な名称・記述は、OWASP公開資料を参照してください。

ID	リスク名	概要
ASI01	Agent Goal Hijack	エージェントの目的を外部入力（メール、文書、RAGデータ等）から書き換える攻撃
ASI02	Tool Misuse & Exploitation	エージェントが正規ツールを悪用・誤用する問題
ASI03	Identity & Privilege Abuse	エージェントのID・継承された認証情報を悪用した権限昇格
ASI04	Agentic Supply Chain Vulnerabilities	MCP/ツール/プラグインのサプライチェーン汚染
ASI05	Unexpected Code Execution	意図しないコード生成・実行
ASI06	Memory & Context Poisoning	エージェントの記憶・RAGストア・コンテキストへの悪意あるデータ注入
ASI07	Insecure Inter-Agent Communication	エージェント間通信の暗号化・認証不足
ASI08	Cascading Failures	1つのエージェント障害がマルチエージェントワークフロー全体に波及
ASI09	Human-Agent Trust Exploitation	人間がエージェントの出力を過信し、安全でない承認や意思決定を行う問題
ASI10	Rogue Agents	侵害または整合性が崩れたエージェントが意図した動作から逸脱する状態

出典: OWASP GenAI Security Project「Top 10 for Agentic Applications 2026」（2025年12月9日公開）

https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

このリストを見て気づくことがあります。ASI02（ツール悪用）、ASI03（ID悪用）、ASI07（通信の安全性）は、従来のゼロトラストアーキテクチャが人間のユーザーに対して解決してきた問題と本質的に同じです。新しいのはリスクの種類ではなく、その適用対象がAIエージェントに広がったという事実です。

エージェントに必要な制御要件

上記の脅威モデルから導かれる制御要件は、ベンダーに依存しない一般論として整理できます。

ID管理と認証: エージェントに検証可能なIDを付与し、毎回認証する（ASI03対策）
最小権限: エージェントが使えるツール・データ・アクションを宣言的に定義し、それ以外をブロックする（ASI02対策）
実行隔離: エージェントの実行環境を分離し、異常時に個別停止できる仕組みを持つ（ASI04, ASI05対策）
通信の安全性: エージェント間通信を暗号化・認証し、なりすましを防ぐ（ASI07対策）
監査証跡: エージェントの全アクション（ツール呼び出し、ポリシー判定結果、入出力）を記録する（ASI09対策）
可観測性: エージェントの挙動をリアルタイムで監視し、異常を検知する（ASI08, ASI10対策）
サプライチェーン管理: 導入するツール・スキル・プラグインの出所と完全性を検証する（ASI04対策）

これらはゼロトラストの3原則、Never Trust, Always Verify、Least Privilege、Assume Breachをエージェントに適用したものです。

ではこの要件に対して、具体的な実装はどうなるのでしょうか。

実装例: Microsoft Agent Governance Toolkit

Microsoftが microsoft/agent-governance-toolkit としてGitHubに公開したOSSツールキットは、上記制御要件に対応する実装の一例です。GitHub上のREADMEでは、OWASP Agentic Top 10の10カテゴリすべてをカバーすると説明されています。もっとも、各カテゴリに対する実装の成熟度や、外部システムとの統合が前提の部分は分けて読む必要があります。

https://github.com/microsoft/agent-governance-toolkit

（MITライセンス、2026年3月公開）

https://github.com/microsoft/agent-governance-toolkit/releases

GitHub READMEで確認できる主要な機能軸は以下の通りです。

1. Agent OS — ポリシーエンジン

エージェントが実行するすべてのアクションの前に、ポリシーエンジンが許可/拒否を判定します。Capability Modelで「このエージェントが使えるツール」を宣言的に定義し、それ以外の操作をブロックします。

これはゼロトラストの最小権限の原則そのものです。人間のユーザーに対してOktaやEntra IDのConditional Accessで実現していることを、エージェントに対しても適用する考え方です。

2. AgentMesh — ゼロトラストID基盤

エージェントに暗号学的に検証可能なIDを付与し、エージェント間通信をTrust Scoreに基づいてゲート制御します。READMEではEd25519鍵やSPIFFE/SVID証明書への対応が挙げられています。

3. Agent Runtime — 実行監督

エージェントの実行環境を分離し、キルスイッチでエージェントを即時停止できるようにします。リソース制限やサンドボックスも含まれます。

人間の世界でいえば、EDR/XDRの隔離機能やネットワークセグメンテーションに相当します。CrowdStrikeが感染端末をネットワークから隔離するように、Agent Runtimeが異常なエージェントだけを隔離します。

4. Agent SRE — 信頼性エンジニアリング

SLO（Service Level Objective）とエラーバジェットでエージェントの信頼性を管理します。サーキットブレーカーやカオステストも含まれます。

実装成熟度に関する注意

Agent RuntimeやAgent SREにはappend-only audit logやflight recorderの考え方が含まれていますが、監査証跡の完全性保護については一部が実装途上です。GitHub READMEでは、監査ログや実行記録の考え方は示されている一方、外部ログ基盤との連携や監査証跡の完全性確保は、実運用では別途検討すべき領域として読むのが安全です。

したがって、本番環境での監査要件を満たすには、このToolkit単体ではなく、外部のSIEM/ログ基盤との組み合わせが前提になります。

具体的なユースケース — 誰が、どんな場面で使うのか

Agent Governance Toolkitは、Pythonベースでアプリケーション実装や運用基盤に組み込んで使うことを想定したOSSツールキットです。Python系のエージェント実装・運用基盤に組み込んで使うことが想定されています。現時点では関数レベルのアダプタが中心で、より深いフレームワーク統合は今後の計画とされています。

ケース 1：社内向けAIエージェントを本番投入したい開発チーム

想定人物: LangChainやAutoGenで社内向けのAIエージェントを開発しているエンジニア。

課題: 社内FAQボットを作ったが、エージェントが外部APIを叩いたり、意図しないファイルに書き込んだりするリスクがあり、セキュリティチームの承認が得られない。

使い方: Agent OSのPolicyEngineで「このエージェントが使えるツールは web_search と file_read のみ、file_write と shell_exec は禁止」と宣言的に定義します。エージェントのすべてのアクションは実行前にポリシーエンジンを通過し、許可された操作のみ実行されます。これにより「エージェントはこれ以外のことは絶対にしません」とセキュリティチームに説明できるようになります。

ケース 2：複数エージェントが連携するワークフローを運用したいプラットフォームチーム

想定人物: 複数のAIエージェントが連携する業務基盤を構築中のSRE/プラットフォームエンジニア。

課題: エージェントAがエージェントBに「この注文をキャンセルして」と指示したとき、それが正当なリクエストなのか、プロンプトインジェクションで注入された不正な指示なのか、区別できない。

使い方: AgentMeshで各エージェントに暗号学的IDを発行し、エージェント間通信をTrust Scoreでゲート制御します。Agent SREのサーキットブレーカーも併用すれば、1つのエージェントの障害時に自動でそのエージェントを切り離し、全体への波及を防げます。

ケース 3：金融・医療など規制産業でAIエージェントを導入したいCISO

想定人物: 金融機関や医療機関のITセキュリティ責任者。

課題: 「そのAIエージェントは何をしたのか」を後から証明できないと、監査に通らない。

使い方: Agent OSの監査ログ機能で、エージェントのツール呼び出し、ポリシー判定結果、入出力、参照先、実行結果など、再現可能性に必要な監査イベントを記録します。ただし前述の通り、監査証跡の完全性保護は実装途上の要素もあるため、外部のSIEM/追記専用ログ基盤との組み合わせが必要です。

ケース 4：エージェントの暴走を止める手段が必要な運用チーム

想定人物: AIエージェントを本番稼働させているが、「もしエージェントがおかしな動きをしたらどうするのか」という問いに答えられていない運用担当者。

課題: エージェントが無限ループに陥ったり、意図しない操作を繰り返したりしたときに、「サービスを止める」以外の手段がない。

使い方: Agent Runtimeのキルスイッチで、問題のあるエージェントだけを即時停止・隔離できます。これはCrowdStrikeが感染端末だけをネットワークから隔離するのと同じ発想です。

実装例: Microsoft Agent 365

OSSのAgent Governance Toolkitがアプリケーション実装に組み込むためのランタイム寄りの部品群だとすれば、Agent 365はMicrosoft 365/Entra/Defender/Purviewと結びついたエンタープライズ運用・統制のコントロールプレーンに近い存在です。

Microsoft公式ブログ（2026年3月9日公開）によると、Agent 365は2026年5月1日にGA（一般提供）を予定しており、価格は1ユーザーあたり月額15ドルとされています（GA前に変更される可能性があります）。

GA日・価格の出典:

https://blogs.microsoft.com/blog/2026/03/09/introducing-the-first-frontier-suite-built-on-intelligence-trust/

Microsoft Learnによると、Frontier program（早期アクセス）ではAgent 365ライセンスはエージェントインスタンス単位で割り当てられます。一方、一般提供（GA）ではユーザー単位ライセンスとなり、ライセンス済みユーザーの代理として動作するエージェントは、そのユーザーのAgent 365またはMicrosoft 365 E7ライセンスでカバーされます。

公式ブログでは、Agent 365の主要機能を以下の5本柱で説明しています。

Registry: エージェントの登録・発見・棚卸し
Access Control: エージェントへのアクセス制御
Visualization: エージェントの挙動・接続の可視化
Interoperability: マルチフレームワーク/マルチベンダーとの相互運用
Security: Entra ID / Defender / Purviewとの統合

ただし、AvePointのレビュー（2026年1月）が指摘するように、プレビュー段階ではCopilot Studioで公開されたエージェントが中心で、開発中や非Microsoft系エージェントの可視性にはギャップがあります。また、ガバナンスの実際の制御はEntra ID / Purview / SharePoint Advanced Managementの各UIに分散しています。Agent 365の現状は「方向性としては正しいが、まだ完成されたコントロールプレーンではない」というのが公平な評価でしょう。

実務上の示唆。マルチベンダー環境で何から始めるべきか

ここまではMicrosoftの実装を見てきましたが、実務ではMicrosoftだけでなく、Claude Code、GitHub Copilot、Cursor、OpenAI、Google等のエージェントが混在する環境が一般的です。ベンダーに依存しない形で、何から始めるべきかを整理します。

1. エージェントインベントリの作成

自社環境でどれだけのAIエージェントが稼働しているかを可視化します。実務上は、CASBのネットワーク観測だけでは把握しきれず、SaaS管理コンソール、API監査ログ、IdP、SIEMの相関が必要になることが多いです。エージェントはブラウザ通信だけでなく、SaaS内のネイティブ機能やAPI経由で動く場合があるためです。

2. エージェントID管理の設計

エージェントに対して「誰が作ったか」「何にアクセスできるか」「いつまで有効か」を定義する仕組みが必要です。現時点では、以下のアプローチが現実的でしょう。

Okta / Entra ID: 一例として、エージェントをサービスアカウントとして登録し、OAuth 2.0のClient Credentialsフローで認証
SPIFFE/SVID: コンテナ化されたエージェントにはワークロードIDを発行するアプローチ
Agent 365: Microsoft 365環境ではAgent 365のレジストリに登録

3. 最小権限ポリシーの適用

エージェントが必要とするツール・データ・アクションを明示的に定義し、それ以外をすべてブロックします。

一例として、Claude Codeの文脈では settings.json のPermissions（Bash(npm run *) 等のワイルドカード許可 + 明示的拒否）やPreToolUseフックが、このレイヤーに相当します。

4. 監査証跡の確保

エージェントのツール呼び出し、ポリシー判定結果、入出力、参照先、実行結果など、再現可能性に必要な監査イベントを記録します。

ゼロトラストは人間だけのものではない

ゼロトラストアーキテクチャの3原則を振り返ります。

Never Trust, Always Verify — エージェントのIDを毎回検証します。
Least Privilege — エージェントには最小限の権限のみ付与します。
Assume Breach — エージェントが侵害された前提で監視・隔離の仕組みを設計します。

これらは人間のユーザーに対して、私たちが何年もかけて構築してきた原則です。AIエージェントの爆発的増加は、既存のIAM・監査・DLP・脅威検知・可観測性をエージェントにも拡張する必要があることを突きつけています。

MicrosoftのAgent Governance ToolkitとAgent 365は、その実装の一つの形を示しています。ベンダーロックインの懸念もありますし、実装成熟度にも差があります。しかし「エージェントを独立した統制対象として扱い、ゼロトラスト原則を適用する」というコンセプト自体は、ベンダーを問わず今後のエンタープライズセキュリティの必須要件になるでしょう。