Microsoft Entra の「Recommended policies for autonomous agents」は、AIエージェントにも条件付きアクセス（Conditional Access）を適用し、ゼロトラストの考え方を人間のユーザーだけでなく自律型エージェントにも広げるための推奨設定です。特に重要なのは、承認済みエージェントだけを許可すること、高リスクのエージェントをブロックすること、エージェントのユーザーアカウントにはデバイス準拠やネットワーク条件を正しく限定して適用することです。
管理者がまず確認すべき結論は明確です。Microsoft Entra Agent ID や AI エージェントを利用している組織は、エージェントを「アプリの裏側で動く例外的な存在」として扱うのではなく、明示的に識別・分類し、条件付きアクセスの対象に含める必要があります。Microsoft Learn の対象ページは、エージェントが自分自身の ID で認証する client credentials flow を前提に、承認済みエージェントの許可、高リスクエージェントのブロック、エージェント用ユーザーアカウントの保護方法を整理しています。なお、Microsoft Learn 上の対象ページは 2026年6月3日最終更新と表示されていますが、本記事では2026年7月上旬時点で確認できる関連公式情報も踏まえて解説します。(Microsoft Learn)
Microsoft Entra の自律型エージェント向け推奨ポリシーとは
Microsoft Entra の「Recommended policies for autonomous agents」は、ユーザーがサインインしていない状態で、エージェント自身の ID によって企業リソースへアクセスするケースを対象にした条件付きアクセス設定ガイドです。公式ドキュメントでは、このアクセスパターンを client credentials flow と説明しており、エージェントはユーザーの代理ではなく、クライアント ID と証明書、またはマネージド ID などの資格情報を使って認証します。(Microsoft Learn)
分かりやすく言えば、従来の「ユーザーがサインインしてアプリを使う」モデルではなく、「AIエージェントがスケジュール実行やイベント駆動で自動的にデータを取得・処理する」モデルを、Microsoft Entra ID の制御対象に入れるための推奨設定です。
たとえば、次のようなエージェントが該当します。
| 対象になるエージェント | 具体例 | 管理上のポイント |
|---|---|---|
| バックグラウンドで自律実行するエージェント | 毎朝レポートを生成して関係者へ送信するエージェント | 人間のサインインがないため、ユーザー条件付きアクセスでは守れない |
| ユーザーの代理ではない処理を行うエージェント | 社内APIやSMS送信サービスへ直接アクセスするバックエンドエージェント | OBOフローではなく、エージェント自身のIDで制御する |
| Web公開されるエージェント | ユーザー認証を行わない、または下流リソースにユーザー文脈を委任しないエージェント | 誰が使ったかではなく、どのエージェントがアクセスしたかを管理する |
この変更の本質は、「AIエージェントもアイデンティティとして扱う」という点にあります。エージェントが取得するアクセストークンの subject がユーザーではなく agent identity になるため、条件付きアクセスのスコープもユーザーではなくエージェント ID に適用されます。(Microsoft Learn)
何が変わるのか：ユーザー中心の条件付きアクセスからエージェント中心の制御へ
これまでの条件付きアクセス設計では、ユーザー、グループ、デバイス、場所、アプリを中心にポリシーを作ることが一般的でした。しかし、AIエージェントが業務データへ直接アクセスするようになると、ユーザーだけを見ていても十分ではありません。
Microsoft Entra の新しい考え方では、エージェントのアクセスを次の3つのパターンに分けて考えます。
| アクセスパターン | 誰がトークンの主体になるか | 条件付きアクセスで主に見る対象 |
|---|---|---|
| ユーザーの代理で動くエージェント | ユーザー | ユーザー、グループ、通常の条件付きアクセス |
| エージェント自身として動くエージェント | Agent identity | エージェント ID、エージェントリスク、対象リソース |
| ユーザーアカウントを持つエージェント | Agent user account | エージェント用ユーザーアカウント、実行環境、デバイス、ネットワーク |
特に注意したいのは、すべてのエージェントが同じ制御対象になるわけではない点です。OBO（on-behalf-of）フローではユーザーが主体になりますが、アプリケーション専用アクセスや自律型エージェントではエージェント自身が主体になります。Microsoft のドキュメントでも、アプリケーション専用アクセスでは条件付きアクセスのポリシーがユーザーではなく agent identity にスコープされると説明されています。(Microsoft Learn)
つまり、既存の「全ユーザー向けMFA必須」や「管理者向けアクセス制限」だけでは、自律型エージェントのアクセス制御としては不足する可能性があります。
影響範囲：確認すべき環境と対象サービス
今回の推奨ポリシーは、すべての Microsoft Entra 利用組織に即座に同じ影響を与えるものではありません。影響が大きいのは、Microsoft Entra Agent ID、Microsoft 365 Copilot 周辺のエージェント、Copilot Studio、独自AIエージェント、MCPサーバー、OpenAPIベースの社内ツールなどを、Microsoft Entra ID で保護されたリソースへ接続している組織です。
特に確認すべき対象は次の通りです。
| 確認対象 | 影響内容 | 優先度 |
|---|---|---|
| Microsoft Entra Agent ID を使うエージェント | 条件付きアクセスの対象として扱える | 高 |
| Agent identity blueprint | ブループリント配下のエージェントに一括でポリシー適用できる | 高 |
| Agent user account | ユーザーのようにメールボックスやグループを持つエージェントを保護する | 高 |
| Windows 365 Cloud PCs for Agents | デバイス準拠条件の対象になり得る | 中〜高 |
| Global Secure Access クライアントを使う実行環境 | 準拠ネットワーク条件を使える | 中 |
| カスタムMCPサーバーや社内API | Microsoft Entra ID にアプリ登録されていれば保護対象にできる | 高 |
一方で、Microsoft Entra ID のトークン発行経路を通らないアクセスは、条件付きアクセスで保護できません。たとえば、APIキーだけでアクセスする独自APIや、Microsoft Entra ID に登録されていない外部サービスは、条件付きアクセスの制御対象外になります。Microsoft の公式ドキュメントでも、条件付きアクセスは Microsoft Entra ID で保護されたリソースにのみ適用され、APIキーでアクセスするリソースは Entra ID の認証・トークン発行パイプラインを迂回すると説明されています。(Microsoft Learn)
管理者が押さえるべき更新ポイント
承認済みエージェントだけを許可する設計が推奨される
最も重要な推奨は、「すべてのエージェントを許可してから危険なものだけ止める」のではなく、「承認済みエージェントだけを除外し、それ以外をブロックする」設計です。
公式ドキュメントでは、承認済みエージェントだけにアクセスを許可する方法として、次の2つが示されています。(Microsoft Learn)
| 方法 | 向いているケース | 注意点 |
|---|---|---|
| enhanced object picker で個別選択 | エージェント数が少ない、急ぎで遮断したい | エージェントが増えると運用が属人化しやすい |
| custom security attributes で分類 | 部門別、用途別、承認状態別に管理したい | 属性設計と棚卸しルールが必要 |
小規模環境や検証段階では、enhanced object picker を使って「すべてのエージェントを対象にし、承認済みだけ除外する」構成でも十分です。しかし、本番運用でエージェント数が増える見込みがあるなら、custom security attributes を使った分類が現実的です。
たとえば、次のような属性設計にすると、運用に落とし込みやすくなります。
| 属性名 | 値の例 | 使い方 |
|---|---|---|
| AgentApprovalStatus | New、In_Review、IT_Approved、HR_Approved、Finance_Approved | 承認済みかどうかを判断する |
| Department | HR、Finance、IT、Marketing、Sales | 部門別のアクセス制御に使う |
| DataSensitivity | Public、Internal、Confidential | 触れるデータの機密度を分類する |
| OwnerTeam | SecOps、HR-IT、FinanceOps | 問題発生時の責任部署を明確にする |
公式例では、AgentApprovalStatus や Department のようなカスタムセキュリティ属性を作り、HR承認済みエージェントだけがHRタグ付きリソースへアクセスできるような設計が示されています。(Microsoft Learn)
高リスクエージェントをブロックできる
Microsoft Entra ID Protection for Agents により、エージェントのリスクシグナルを条件付きアクセスに利用できます。推奨ポリシーでは、Agent risk が High のエージェントをブロックする構成が示されています。(Microsoft Learn)
これは、AIエージェントが侵害された場合の被害拡大を抑えるうえで重要です。人間のユーザーであれば追加認証やパスワード変更といった自己修復の余地がありますが、エージェント ID では対話的な修復ができません。そのため、agent identity に対するアクセス制御では、基本的に「ブロック」が中心になります。
Microsoft Entra ID Protection for Agents の公式情報では、リスク検出の例として、初期ライフサイクルでの悪意ある活動、ディレクトリ偵察、許可されていないリソースへのアクセス失敗、サインイン急増、不審な資格情報利用、通常アクセスしないリソースへのアクセスなどが挙げられています。(Microsoft Learn)
管理者は、少なくとも次の設定を検討すべきです。
| 項目 | 推奨設定の考え方 |
|---|---|
| 対象 | All agent identities |
| 対象リソース | All resources、または重要リソースから段階適用 |
| 条件 | Agent risk = High |
| アクセス制御 | Block |
| 有効化方法 | 最初は Report-only、影響確認後に On |
エージェント用ユーザーアカウントも条件付きアクセスの対象になる
自律型エージェントの中には、人間のようにメールボックス、カレンダー、グループメンバーシップ、チーム参加権限を持つ「agent user account」として動作するものがあります。Microsoft のドキュメントでは、こうしたエージェント用ユーザーアカウントに対しても、条件付きアクセスの適用範囲が拡張されると説明されています。(Microsoft Learn)
ここで重要なのは、通常の「All users」ポリシーに agent user accounts が自動的に含まれるとは限らない点です。公式ドキュメントでは、すべてのユーザーを対象にするポリシーは agent’s user accounts を含まないと明記されています。(Microsoft Learn)
そのため、エージェント用ユーザーアカウントを保護するには、条件付きアクセスの割り当てで「Agents」を選び、All agent users または個別の agent users を対象にする必要があります。
デバイス準拠や準拠ネットワークは「実行環境」で絞る必要がある
エージェント用ユーザーアカウントに対しては、デバイス準拠や準拠ネットワークを要求できます。ただし、すべてのエージェントに一律で適用すると、クラウドネイティブなエージェントを意図せずブロックする危険があります。
Microsoft の公式ドキュメントでは、デバイス準拠や準拠ネットワークのシグナルはエンドポイントが提供するものであり、クラウド上で直接実行されるエージェントには関連デバイスがないため、準拠条件を満たす経路がないと説明されています。(Microsoft Learn)
そのため、デバイス準拠や準拠ネットワークを求める場合は、Agent execution environments 条件を使い、「Agent user sessions initiated from endpoints」に限定することが重要です。これにより、エンドポイントから開始されたエージェントセッションだけにポリシーを適用し、クラウドネイティブなエージェントを誤ってブロックするリスクを抑えられます。(Microsoft Learn)
推奨ポリシーの実装パターン
承認済みエージェントだけを許可する
まず作成したいのは、未承認エージェントを原則ブロックするポリシーです。基本方針は「全エージェントを対象にして、承認済みだけ除外する」です。
| 設定項目 | 設定例 |
|---|---|
| Assignments | Agents |
| Include | All agent identities |
| Exclude | 承認済みの agent identities、または承認済み属性を持つエージェント |
| Target resources | All resources |
| Grant | Block |
| Enable policy | Report-only から開始 |
この設計では、承認されていない新規エージェントが作られても、既定では企業リソースにアクセスできません。エージェントの作成速度が上がるほど、個別許可型よりも安全性が高くなります。
実務では、いきなり全リソースを対象にすると業務影響が読みにくい場合があります。その場合は、Microsoft Graph、SharePoint、Exchange、社内の重要APIなど、影響が大きいリソースから段階的に対象を広げるとよいでしょう。
カスタムセキュリティ属性で部門・用途ごとに制御する
エージェント数が増える組織では、個別選択では限界があります。おすすめは、エージェントとリソースの両方にカスタムセキュリティ属性を付け、条件付きアクセスで属性ベースに制御する方法です。
たとえば、人事部門向けのエージェントなら、次のように設計できます。
| オブジェクト | 属性 | 値 |
|---|---|---|
| HRレポート生成エージェント | AgentApprovalStatus | HR_Approved |
| HRレポート生成エージェント | Department | HR |
| 人事データAPI | Department | HR |
| 給与関連API | DataSensitivity | Confidential |
この構成なら、「HR_Approved のエージェントだけが HR リソースへアクセスできる」というルールを作りやすくなります。新しいHRエージェントが追加された場合も、属性を正しく付与すれば既存ポリシーに自然に乗せられます。
失敗しやすいのは、属性値を後から場当たり的に増やすことです。Approved、ITApproved、IT_Approved のような似た値が混在すると、条件付きアクセスの対象漏れが起きます。最初に命名規則と承認フローを決め、属性の変更権限を限定しておくことが重要です。
高リスクエージェントを自動的にブロックする
次に作成したいのが、ID Protection の Agent risk を使ったブロックポリシーです。
| 設定項目 | 推奨例 |
|---|---|
| Assignments | Agents |
| Include | All agent identities |
| Target resources | All resources |
| Conditions | Agent risk = High |
| Grant | Block |
| Enable policy | Report-only で検証後、On |
このポリシーは、すべての組織で検討価値があります。特に、エージェントに Microsoft Graph、SharePoint、Exchange、Teams、社内APIへの広い権限を与えている場合、侵害時の横展開を防ぐ最後の防波堤になります。
ただし、リスク検出は誤検知や運用上の例外もあり得ます。最初から本番ブロックにせず、Report-only で検出傾向を確認し、Risky Agents レポートやサインインログと突き合わせてから有効化するのが安全です。
エージェント用ユーザーアカウントのリスクをブロックする
agent user account を使う場合は、agent identity とは別にポリシーを作成します。公式ドキュメントでは、agent user accounts に対して Agent risk が Medium または High の場合にブロックする例が示されています。(Microsoft Learn)
| 設定項目 | 設定例 |
|---|---|
| Assignments | Agents |
| Include | All agent users |
| Target resources | All resources |
| Conditions | Agent risk = Medium and High |
| Grant | Block |
| Enable policy | Report-only から開始 |
ここでの注意点は、agent identity 向けポリシーと agent user account 向けポリシーを混同しないことです。公式情報では、agent identity を対象にした条件付きアクセスポリシーは agent user account には適用されず、agent identity blueprint を対象にしても agent user account はカバーされないと説明されています。(Microsoft Learn)
Windows 365 Cloud PCs for Agents ではデバイス準拠を要求する
Windows 365 Cloud PCs for Agents のように、Intune 管理されたエンドポイント上で動くエージェントには、デバイス準拠条件を使えます。公式ドキュメントでは、Windows 365 Cloud PCs for Agents は Intune 管理された Windows デバイスであり、従業員のPCと同様に条件付きアクセスで準拠状態を評価できると説明されています。(Microsoft Learn)
設定の考え方は次の通りです。
| 設定項目 | 設定例 |
|---|---|
| Assignments | Agents |
| Include | All agent users |
| Target resources | All resources、または対象業務アプリ |
| Conditions | Agent execution environments = Agent user sessions initiated from endpoints |
| Grant | Grant access + Require device to be marked as compliant |
| Enable policy | Report-only で影響確認後、On |
この設定を使うと、管理されていない端末や想定外の実行環境からエージェントが動作するリスクを抑えられます。
ただし、Agent execution environments 条件を付けずにデバイス準拠を要求すると、デバイス情報を持たないクラウド実行エージェントがブロックされる可能性があります。これは実務で特に起きやすいミスです。
Global Secure Access を使う環境では準拠ネットワークを要求する
Global Secure Access クライアントを導入している場合、エージェントが準拠ネットワークから接続しているかを条件にできます。公式ドキュメントでは、Global Secure Access クライアントがエンドポイントにインストールされている場合、そのネットワークロケーションシグナルを条件付きアクセスで評価できると説明されています。(Microsoft Learn)
| 設定項目 | 設定例 |
|---|---|
| Assignments | Agents |
| Include | All agent users |
| Conditions | Agent execution environments = Agent user sessions initiated from endpoints |
| Grant | Grant access + Require compliant network |
| 前提 | 対象エンドポイントに Global Secure Access クライアントがあること |
この設定は、エージェントが機密性の高い社内システムや業務データへアクセスする場合に有効です。特にグローバル企業では、国や地域ごとにネットワーク経路が異なるため、「どの拠点・どのネットワークからのエージェント実行を許可するか」を明確にしておく必要があります。
条件付きアクセステンプレートも確認する
Microsoft Entra の条件付きアクセステンプレートには、AI Agents カテゴリが用意され、Block high-risk agent identities、Configure policy for autonomous agent access、Configure policy for on-behalf-of agent access などのテンプレートが確認できます。テンプレートは Microsoft Entra admin center の「Conditional Access > Create new policy from templates」から利用でき、既定では Report-only mode で作成されます。(Microsoft Learn)
テンプレートを使うメリットは、初期設定の抜け漏れを減らせることです。一方で、そのまま本番適用すればよいわけではありません。対象リソース、除外対象、属性設計、緊急時の復旧手順は組織ごとに異なるため、テンプレート作成後に必ず自社環境へ合わせて調整してください。
ライセンスとプレビュー機能の注意点
Conditional Access for agents の利用には、Microsoft Entra ID P1 または P2 が必要です。公式ドキュメントでは、Conditional Access for agents には Microsoft Entra ID P1 または P2 と、各ユーザーに対する Microsoft Agent 365 ライセンスが必要であり、Agent 365 ライセンスの enforcement は今後予定されていると説明されています。また、エージェント向けネットワーク制御には Microsoft Entra Internet Access が必要です。(Microsoft Learn)
管理者は、次の点を必ず確認してください。
| 確認項目 | 理由 |
|---|---|
| Microsoft Entra ID P1/P2 の有無 | 条件付きアクセスの前提になる |
| Microsoft Agent 365 ライセンスの対象 | 今後のライセンス enforcement に備える |
| Microsoft Entra Internet Access の利用有無 | 準拠ネットワーク制御に関係する |
| Preview 表記の機能 | 仕様やUIが変わる可能性がある |
| テナントごとの提供状況 | グローバル展開ではリージョンやテナント差を考慮する |
特に「All agent users」や「Agent risk」「Agent execution environments」などは Preview と表示される箇所があります。プレビュー機能を本番運用に組み込む場合は、変更履歴を追跡し、設定を定期的に見直す運用が必要です。
移行期限はあるのか
対象の「Recommended policies for autonomous agents」ドキュメント自体には、既存の条件付きアクセスポリシーを特定日までに移行しなければならないという期限は示されていません。したがって、今回のポイントは「強制移行への対応」ではなく、「AIエージェント利用拡大に備えた条件付きアクセス設計の更新」と捉えるのが適切です。
ただし、何もしなくてよいという意味ではありません。AIエージェントが業務データにアクセスし始めると、従来のユーザー中心のポリシーだけではカバーできない経路が生まれます。さらに、Agent 365 ライセンス enforcement が今後予定されていることや、エージェント関連機能がプレビューから一般提供へ進む可能性を考えると、早めに棚卸しと Report-only 検証を始めるべきです。(Microsoft Learn)
実務での導入手順
まずエージェントを棚卸しする
最初にやるべきことは、ポリシー作成ではなく棚卸しです。どのエージェントが存在し、誰が所有し、どのリソースへアクセスし、どのID形態で動いているかを確認します。
最低限、次の項目を一覧化してください。
| 棚卸し項目 | 記録例 |
|---|---|
| エージェント名 | HR Daily Report Agent |
| ID種別 | agent identity / agent user account / OBO |
| 所有者 | HRシステム担当、SecOps |
| スポンサー | 人事部長、情報システム責任者 |
| 利用目的 | 人事レポート自動生成 |
| アクセス先 | SharePoint、Microsoft Graph、社内API |
| 権限範囲 | 読み取りのみ、更新あり、管理権限あり |
| 実行環境 | クラウド、Windows 365 Cloud PC、社内VM |
| 承認状態 | New、In_Review、Approved |
Microsoft Entra の管理ドキュメントでも、エージェント ID の表示、ブループリント管理、アクセス制御、アクティビティ監視、リスク対応が管理タスクとして整理されています。(Microsoft Learn)
次にリスク別に分類する
すべてのエージェントに同じ厳格なルールを適用すると、運用が止まる可能性があります。重要なのは、リスクに応じて段階を分けることです。
| リスク区分 | 例 | 推奨アクション |
|---|---|---|
| 高 | 個人情報、財務情報、管理APIへアクセスする | 承認済みのみ許可、高リスク即ブロック、ログ監視 |
| 中 | 社内文書や業務データを読み取る | 部門別属性制御、Report-only 検証後にブロック |
| 低 | 公開情報や限定されたテスト環境にアクセスする | 棚卸しと最小権限から開始 |
特に、書き込み権限を持つエージェント、外部送信を行うエージェント、複数システムをまたいで動くエージェントは優先的に制御対象にしてください。
Report-only で影響を確認する
Microsoft の推奨手順では、条件付きアクセスポリシーを作成した後、まず Report-only で影響を確認し、その後 On に切り替える流れが繰り返し示されています。(Microsoft Learn)
Report-only で見るべきポイントは次の通りです。
| 確認項目 | 見る理由 |
|---|---|
| ブロック対象になったエージェント | 未承認エージェントや想定外のアクセスを発見する |
| 対象リソース | 重要システムへの影響を確認する |
| リスク検出 | 誤検知と真のリスクを切り分ける |
| 実行環境 | クラウド実行とエンドポイント実行を区別する |
| 業務影響 | レポート生成、通知、連携処理が止まらないか確認する |
Report-only の結果を見ずに On にすると、業務で使っている自動処理が突然停止する可能性があります。特に、日次処理や月次処理のエージェントは、検証期間中に実行タイミングが来ないこともあるため、少なくとも主要なスケジュール処理が一巡する期間を確認するのが安全です。
失敗しやすいポイント
「All users」でエージェントも守れていると思い込む
最も危険なのは、既存の全ユーザー向け条件付きアクセスでエージェントも保護されていると思い込むことです。agent identity や agent user account は、人間のユーザーと同じ扱いにならないケースがあります。
特に agent user account は、通常の All users ポリシーに含まれない点を前提に設計する必要があります。(Microsoft Learn)
agent identity と agent user account を混同する
agent identity 向けポリシーを作っただけでは、agent user account は保護されません。逆に、agent user account 向けのデバイス条件を agent identity に適用しようとしても、期待した制御にはなりません。
設計時には、エージェントごとに「どのIDでトークンを取得しているか」を必ず確認してください。
デバイス準拠を一律適用してクラウド実行エージェントを止める
クラウド上で直接動作するエージェントは、Intune 管理デバイスの準拠状態を提示できません。Agent execution environments 条件でエンドポイント開始セッションに限定せず、デバイス準拠を一律要求すると、意図しないブロックが発生します。(Microsoft Learn)
APIキー経由のアクセスを見落とす
条件付きアクセスは、Microsoft Entra ID の認証とトークン発行を通るアクセスに効きます。APIキーや独自トークンで動く社内APIは、別途APIゲートウェイ、キー管理、ネットワーク制御、監査ログで守る必要があります。
AIエージェントのセキュリティでは、「Entra IDで守られる経路」と「Entra IDを通らない経路」を分けて棚卸しすることが重要です。
管理者向けチェックリスト
導入前に、次の項目を確認してください。
| チェック項目 | 対応状況 |
|---|---|
| すべての agent identities と agent user accounts を一覧化した | 未対応なら最優先 |
| エージェントごとの所有者・スポンサーを記録した | 責任所在を明確化 |
| アクセス先リソースを分類した | Microsoft Graph、SharePoint、社内APIなど |
| 未承認エージェントをブロックする方針を決めた | object picker または属性制御 |
| custom security attributes の設計を決めた | 部門、承認状態、機密度 |
| Agent risk を使うポリシーを Report-only で作成した | 高リスクブロックの準備 |
| agent user account 向けポリシーを別に設計した | All users 依存を避ける |
| デバイス準拠はエンドポイント実行に限定した | 誤ブロック防止 |
| Global Secure Access の対象環境を確認した | 準拠ネットワーク条件の前提 |
| テンプレートポリシーを確認した | AI Agents カテゴリを確認 |
| ライセンス要件を確認した | P1/P2、Agent 365、Entra Internet Access |
| 影響確認後に段階的に On へ切り替える手順を決めた | いきなり本番ブロックしない |
まとめ：AIエージェントを「例外」ではなく「管理対象のID」として扱う
Microsoft Entra の「Recommended policies for autonomous agents」は、AIエージェント時代の条件付きアクセス設計を見直すための重要なガイドです。ポイントは、エージェントを単なるアプリの裏側の処理ではなく、企業リソースへアクセスする明確なアイデンティティとして扱うことです。
管理者が次に取るべき行動は、まずエージェントの棚卸しを行い、agent identity、agent user account、OBOフローを分類することです。そのうえで、承認済みエージェントだけを許可するポリシー、高リスクエージェントをブロックするポリシー、エンドポイント実行エージェント向けのデバイス・ネットワーク条件を Report-only で検証してください。
AIエージェントの利用が進むほど、「誰がアクセスしたか」だけでなく「どのエージェントが、どのIDで、どのリソースへアクセスしたか」を制御できることが重要になります。Microsoft Entra の条件付きアクセスをエージェントまで拡張することは、今後のゼロトラスト運用における基本設計の一部として考えるべきです。
コメント