AIエージェントを「人より強い権限」で動かさないためのZero Trust設計

確認基準日：2026年8月6日

【｜結論】

生成AIのセキュリティ対策は、「入力してはいけない情報を社員へ周知する」だけでは足りません。

AIエージェントは、文章を回答するだけでなく、API、プラグイン、業務システム、運用スクリプトを呼び出し、複数の処理を連続して実行できるからです。

これから企業が管理すべき対象は、

・人のID・端末の状態・データへのアクセス・AIエージェント固有のID・エージェントが利用できるツール・実行した操作の証拠・保存されたAIメモリ

まで広がります。

Microsoftは2026年8月4日、AIエージェントとAI支援型開発を対象とする「Zero Trust for AI」の新しい評価ツールと実装ガイダンスを公表しました。

【｜確認できた事実】

Microsoftが公表した主な更新は、次の3点です。

① Zero Trust AssessmentへAI、セキュリティ運用、インフラストラクチャの評価領域を追加② Zero Trust WorkshopへDevSecOps専用領域を追加③ AIエージェント、ツール、メモリ、データ、実行時制御に関する実装ガイダンスを追加

新しいDevSecOps領域には、15のコントロールグループと91のタスクが用意されています。

対象は、開発者用プラットフォーム、ソースコード、依存パッケージ、CI/CDパイプライン、成果物、Infrastructure as Codeなどです。

AIを導入する前提として、ID、端末、データ、ネットワークだけでなく、開発工程とAI固有の攻撃面まで継続的に評価する考え方です。

【｜AIエージェントには固有のIDが必要】

AIエージェントを、共有シークレットや担当者個人の権限で動かしてはいけません。

Microsoftのガイダンスでは、AIエージェントについて、

・固有の専用IDを割り当てる・責任を負う所有者と承認者を定める・利用目的、データ、ツール、動作環境を記録する・複数システムを通じた実効権限を確認する・未承認のツールや外部連携を原則拒否する・停止、資格情報変更、トークン失効を試験する

ことを推奨しています。

重要なのは、エージェントに「何ができるか」ではなく、

「その処理を実行すべきか」「どのデータに対して実行できるか」「誰の権限として実行したか」

を判定できる状態にすることです。

【｜広すぎるAzure権限を与えない】

検証を急ぐため、AIエージェントや自動化用IDへ、サブスクリプション全体のContributorやOwnerを付与する構成は避けるべきです。

Microsoftは、修復処理やスクリプトを実行するエージェントについて、

・JITによる一時的な権限昇格・実行前の承認・特定リソースグループやサービスへの限定・サブスクリプション全体の権限を与えない・削除や権限変更時の追加確認・ロールバック手順と変更履歴の整備

を示しています。

「読む権限」と「変更する権限」、「チケットを作る権限」と「削除する権限」も分ける必要があります。

AIだから特別な権限を与えるのではなく、人より厳密に最小権限を適用する設計が必要です。

【｜AIメモリは新しいセキュリティ境界】

AIエージェントのメモリは、単なる会話履歴ではありません。

保存された情報は、将来の回答、ツールの選択、拒否判断、処理の実行方法へ影響する可能性があります。

Microsoftは、攻撃者が一度のプロンプトで成功しなくても、メモリへ不正な内容を残すことにより、後のセッションでエージェントの動作を変化させる危険を示しています。

対策として、

・メモリへの書込み時に利用目的と情報源を確認・資格情報、APIキー、決済情報、公的識別番号を保存しない・ユーザー、エージェント、テナント単位で分離・保存情報を絶対的な事実として扱わない・読出し時にも悪意ある命令を再検査・閲覧、訂正、削除手段を利用者へ提供・作成、参照、変更、削除をすべて記録

することが示されています。

【｜ログは「回答文」だけでは不十分】

AIエージェントの監査では、チャット画面に表示された回答だけを保存しても、十分な証拠にはなりません。

最低限、次を追跡できる必要があります。

・エージェントのID・実行時のロール・有効だった権限範囲・呼び出したツール・実行した操作・対象リソース・代理元となった利用者・承認者・相関ID・メモリの参照・更新履歴・下流システムでの実行結果

Microsoftは、ログへID、ロール、スコープ、操作、リソース、相関IDなどを残し、オーケストレーターから下流サービスまで追跡可能にすることを推奨しています。

「AIが実行した」という記録だけでは、責任主体や被害範囲を説明できません。

【｜クラウド法務では契約前に決める】

デジタル庁は2026年6月12日、「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン第2.0版」を公表しました。

政府向けガイドラインですが、民間企業がAIサービスの調達条件や委託契約を検討する際にも参考になる項目が含まれています。

契約チェック項目には、

・入力情報が学習へ利用されるか・入力情報と生成途中データの保存方法・第三者提供の有無・出力結果と成果物の権利帰属・期待品質を確保するための義務・インシデント発生時の事業者の対応範囲・原因特定に必要な情報とデータの提供

などが示されています。

AI導入後に確認するのではなく、契約締結前に責任分界を明文化する必要があります。

【｜個人情報を入力できるか】

個人情報保護委員会は、個人情報を含むプロンプトを生成AIサービスへ入力する場合、特定された利用目的を達成するために必要な範囲内であることを確認するよう注意喚起しています。

本人の同意なく個人データを入力し、そのデータが回答生成以外の目的で取り扱われる場合には、個人情報保護法に違反する可能性があります。

そのため、少なくとも次を確認します。

・入力データがモデル学習に使われるか・サービス改善や品質評価へ使われるか・人間によるレビュー対象になるか・保存期間と削除方法・保存場所と国外移転・再委託先やサブプロセッサー・契約終了時のデータ削除・AIメモリへ残る情報の範囲

「企業向けサービスだから安全」と推測せず、契約、設定、技術仕様を個別に確認する必要があります。

【｜侵害時に止める対象】

AIエージェントの不正動作が疑われた場合、利用者のパスワード変更だけでは止まらない可能性があります。

確認・封じ込めの対象は、

・エージェントIDの無効化・アクセストークンの失効・シークレットと証明書の変更・付与されたAzure・Microsoft Entra権限の削除・接続済みツールとプラグインの停止・自動実行ジョブとスケジュールの停止・共有メモリとベクトルデータの隔離・下流システムで実行された変更の特定・不正なメモリの削除またはロールバック・ログとプロンプト、操作履歴の保全

まで広げる必要があります。

Microsoftも、エージェントの停止、資格情報の変更、トークン失効、権限削除を含む「キルスイッチ」の試験を推奨しています。

【｜企業が今行うべきこと】

AIエージェントの本格導入前に、次の7点を整備してください。

① 稼働中・検証中のAIエージェント台帳② エージェントごとの所有者、目的、利用データ③ 固有IDと最小権限RBAC④ 利用可能なツールと操作の許可リスト⑤ 人の承認が必要な高リスク操作⑥ ログ、保存期間、証拠保全方法⑦ 停止、失効、復旧、報告の手順

デジタル庁の第2.0版ガイドラインでは、AIガバナンスの枠組みが2026年7月1日から対象となり、同版の内容は2026年9月1日から施行されます。政府向けの基準ですが、AIの利用促進とリスク管理を同時に進める考え方は、民間企業の実務にも有用です。

山崎行政書士事務所では、

・Azure上のAI基盤とネットワーク構成の確認・Microsoft EntraによるエージェントID・権限設計・機密情報、個人情報、AIメモリの管理設計・監査ログとインシデント対応手順の整備・AI利用規程、委託契約、責任分界の確認・ベンダー向け調達・契約チェックシート・顧客、委託元、行政機関への説明資料

を、Azure技術支援とクラウド法務の両面から支援します。

AIに仕事を任せるなら、権限だけでなく、

「誰の責任で動いたのか」「何を根拠に判断したのか」「どの操作を実行したのか」「問題発生時に直ちに止められるか」

まで説明できる状態にすることが重要です。