エージェントの条件付きアクセス

エージェントの条件付きアクセスは、エージェントがMicrosoft Entra IDによって保護されているリソースにアクセスする方法を制御する条件付きアクセス ポリシー エンジンの拡張機能です。 これにより、ユーザーとエージェントのコンテキスト、デバイス、場所、リスク情報などのリアルタイムシグナルがまとめられ、アクセスを許可、ブロック、または制限するタイミングを決定したり、より多くの検証手順が必要になったりします。

エージェントのアクセス パターンを理解することは、正しい ID をターゲットにするのに役立ちます。 エージェントは、サインインしているユーザーの代わりに動作するか、独自のエージェント ID を使用するか、独自のエージェント ユーザー アカウントを使用できます。

エージェントの条件付きアクセスについて説明します。

• 条件付きアクセスの概要: 条件付きアクセスとは
• 組織全体でエージェント ID を管理するためのガイド: 組織内のエージェント ID を管理します。
• 条件付きアクセスでエージェント ID をターゲットにする方法
• 条件付きアクセスを使用して自律エージェントをセキュリティで保護する
• Microsoft Entra 条件付きアクセスを使用してエージェント ユーザーをセキュリティで保護する

要件とライセンス

エージェントの条件付きアクセスMicrosoft Entra IDには、次のいずれかのライセンス プランが必要です。

• Microsoft 365 E7。エージェント 365 とMicrosoft Entra スイートが含まれます。
• Microsoftエージェント 365 ライセンスは、少なくとも Microsoft Entra P1 または Microsoft 365 E3 とペアリングされています。

詳細については、「Microsoft Agent 365 のプランと価格」を参照してください。

条件付きアクセスによるエージェント アクセスの評価方法

SharePoint ファイル、MCP サーバー、Open API サービスなどのリソースにアクセスするには、ユーザーまたはエージェントがMicrosoft Entra IDからアクセス トークンを要求します。

条件付きアクセス ポリシーが適用されると、Microsoft Entra IDはトークンを発行する前にポリシー要件を評価します。 要件が満たされている場合、Microsoft Entra IDはトークンを発行します。 ターゲット リソースはトークンを検証し、その要求を使用して承認の決定を行います。

各アクセス トークンには、1 つのサブジェクトと 1 人の対象ユーザーがあります。

• 件名: トークンを受け取る ID。
  • 委任されたアクセスでは、トークンはユーザーを表し、呼び出し元のアプリケーションまたはエージェントも識別します。
  • アプリケーションのみのアクセスでは、エージェント ID がサブジェクトです。
  • エージェント ユーザー アクセスでは、エージェントのユーザー アカウントがサブジェクトです。
• 対象ユーザー: トークンの対象となるターゲット リソース。Entra IDに登録する必要があります。 サブジェクトが複数のリソースにアクセスする場合、通常はリソースごとに個別のトークンが必要です。

条件付きアクセスは、アクセスを要求するサブジェクトとアクセスする対象ユーザーの両方を評価します。 Microsoft Entra IDがアクセス トークンを発行または更新すると、ポリシーが評価されます。 一部のリソースでは、特定のイベントに対するほぼリアルタイムの適用をトリガーできる継続的アクセス評価もサポートされています。

条件付きアクセスに関する決定の方法

条件付きアクセス ポリシーは、if-then ステートメントとして動作します。

• ポリシーで定義されている条件が満たされている場合は、構成されたアクセス制御が適用されます。
• 必要なコントロールが満たされている場合は、アクセス権が付与されます。
• 必要な制御が満たされていない場合、アクセスは拒否されます。

たとえば、ユーザーがエージェントに電子メールへのアクセスを承認する前に、組織で多要素認証が必要になる場合があります。 同様に、組織は、リスクが高いエージェントからのアクセスをブロックするポリシーを構成できます。

条件付きアクセスが評価される場合

条件付きアクセスは、Microsoft Entra IDがアクセス トークンを発行または更新するたびに評価されます。 一部のリソースでは、特定のイベントに対するほぼリアルタイムの適用をトリガーできる継続的アクセス評価もサポートされています。

エージェントのアクセス パターン

エージェントは、次のいずれかのパターンを使用して、Microsoft Entra保護されたリソースにアクセスできます。

エージェントは複数のアクセス パターンを使用できます。 エージェントが使用するトークンサブジェクトごとに個別のポリシーを作成します。 エージェント ID を対象とするポリシーはエージェントのユーザー アカウントには適用されません。また、エージェントのユーザー アカウントを対象とするポリシーはエージェント ID には適用されません。

ユーザーに代わって動作するエージェント

最も一般的なアクセス パターンは、代理アクセス (OBO) フローです。 OBO フローでは、ユーザーはエージェント アプリケーションにサインインします。 エージェントは、ユーザーの ID と委任されたアクセス許可を使用してダウンストリーム リソースにアクセスします。 たとえば、エージェントが電子メールを読み取ると、ユーザー に代わってメールボックスにアクセスします。 エージェントに対して OBO フローがどのように機能するかの詳細については、「Agent OAuth flows: On-behalf-of」を参照してください。

このフローでは、エージェントは別の対象ユーザーに対して発行されたため、ユーザーの元のトークンを再利用できません。 代わりに、エージェントは OBO フローを使用してトークンをMicrosoft Entra IDと交換し、ターゲット リソースをスコープとする新しいトークンを取得します。 このトークン交換は条件付きアクセスによっても評価され、管理者は、エージェントがユーザーに代わってアクセスできるリソースをきめ細かく制御できます。

サインインしているユーザーはこのフローのトークンのサブジェクトであるため、条件付きアクセスは、そのユーザーが直接、グループ経由、またはその他のサポートされているユーザー ターゲティング メカニズム経由で対象となっているかどうかにかかわらず、そのユーザーに割り当てられているポリシーを評価します。 ポリシーのサブジェクトとしてエージェント ID を選択しても、ユーザーに代わって行われたエージェント要求はカバーされません。

アプリケーションとして機能するエージェント

エージェントは、サインインしているユーザーなしでリソースにアクセスする場合があります。 この場合、エージェントは独自の ID を使用してリソースにアクセスします。 このフローは、クライアント資格情報フローまたはアプリのみのアクセスとも呼ばれます。 すべての種類のエージェントがこのフローを使用する場合があります。 エージェントが独自の ID を使用して認証する方法の詳細については、「 エージェント OAuth フロー: 自律型アプリ」を参照してください。

このフローは、次の一般的なシナリオに適用されます。

• 独立して動作する自律エージェントは 、バックグラウンドで実行したり、イベントに応答したり、スケジュールに従って実行したりします。
  • たとえば、日次レポートを生成し、結果を従業員のグループに送信するエージェントです。
  • このシナリオでは、ユーザーは存在せず、エージェントは単独で動作します。
• 独自の ID を使用する対話型エージェント は、常にユーザーの代わりにリソースにアクセスするとは限りません。場合によっては、独自の ID を使用します。
  • たとえば、ユーザーがアクセスできないバックエンド SMS サービスをエージェントが呼び出した場合、OBO フローは適用されません。エージェントはそれ自体として直接認証されます。
• 一般に使用するために Web 上で公開されたエージェント は、ユーザーを認証しないか、ユーザーのコンテキストを企業リソースに委任することをサポートしていません。

これらのシナリオでは、エージェントは、エージェント ID ブループリントで管理される独自のエージェント ID と資格情報を使用してアクセス トークンを要求します。 トークンは、(ユーザーではなく) エージェント ID に発行されます。 そのため、条件付きアクセス ポリシーのスコープは、ユーザーではなくエージェント ID になります。 詳細なポリシー構成については、「 条件付きアクセスによる自律エージェントのセキュリティ保護」を参照してください。

ユーザーとして機能するエージェント

エージェントがユーザーに代わってタスクを実行したり、独自の ID で操作したりするには不十分な場合があります。 特定のシナリオでは、エージェントには、独自のメールボックス、チャットへのアクセス、チーム メンバーとして共同作業ワークフローに参加する機能を持つデジタル ワーカーとして機能する独自の エージェントのユーザー アカウント があります。

このモデルでは、管理者がディレクトリにユーザー アカウントを作成し、エージェントの ID にリンクします。 そこから、他のユーザー アカウントと同じです。 ライセンスは、メールボックスや予定表などのMicrosoft 365リソースにアクセスするために割り当てることができます。 このアカウントは、人間のユーザー アカウントと同様に、管理単位とセキュリティ グループに追加できます。

このフローを使用するエージェントは、人間の操作にユーザー インターフェイスを含まないため、自律エージェントとも見なされます。 このモデルでは、アクセス トークンはエージェントのユーザー アカウント (トークンのサブジェクト) に発行され、ポリシーはエージェント ID ではなくエージェントのユーザー アカウントに対して評価されます。 詳細なポリシー構成については、「 自律エージェントの条件付きアクセス」を参照してください。 エージェント ユーザー OAuth フローの詳細については、「 エージェント ユーザーの OAuth フロー」を参照してください。

Windows 365 エージェント用クラウド PC などのマネージド エンドポイントで実行されているエージェントは、デバイスのコンプライアンスと準拠したネットワーク制御の対象となる場合もあります。 エージェント実行環境 (プレビュー) 条件を使用して、これらのポリシーのスコープをエンドポイントベースのセッションのみに限定します。 詳細については、「 エージェントのユーザー アカウントに準拠しているデバイスを要求する」を参照してください。

条件付きアクセス ポリシーとエージェント ID ブループリント

特定のエージェント アクセス パターンに加えて、 エージェント ID ブループリント を選択して、条件付きアクセス ポリシーをエージェントのクラスに適用することもできます。 エージェント ID ブループリントは、そこから作成されたエージェント ID の構成とガバナンス モデルを定義します。 ブループリントを対象とするポリシーは、後で作成されたエージェント ID を含め、そのブループリントから作成されたすべてのエージェント ID に適用されます。

次の図は、ブループリント "A" に関連付けられているエージェント ID にのみアクセス権が付与されることを示しています。他のすべてのエージェントは除外され、ブロックされます。

たとえば、複数のエージェントがあり、それぞれが独自の目的を持つプロジェクトがあるとします。 一部は独立して動作し、他のエージェント (A2A) と共同作業してタスクを完了するものもあります。 すべてが同じブループリントで作成されている場合、そのブループリントに適用される 1 つのポリシーによって、コレクション全体で一貫したアクセス制御が適用されます。

属性駆動型の条件付きアクセス

エージェント ID の数が増えるにつれて、すべてのポリシーで各 ID を個別に管理することは持続できなくなります。 カスタム セキュリティ属性を 使用すると、ビジネス固有のラベルを持つエージェント ID とリソースを分類し、条件付きアクセス ポリシーでそれらの属性をターゲットにできます。 ポリシーは、将来追加されたものも含め、一致する属性を持つすべてのエージェントに自動的に適用されます。

ポリシーの例については、「 カスタム セキュリティ属性を使用して承認されたエージェントを許可する」を参照してください。

境界と制限事項

条件付きアクセス ポリシーは、次の場合には適用されません。

• エージェント ID ブループリントは、エージェント ID またはエージェントのユーザー アカウントを作成するためのMicrosoft Graphのトークンを取得します。
  • エージェント ブループリントの機能は限られています。 リソースにアクセスするために独立して動作することはできないため、エージェント ID とエージェントのユーザー アカウントの作成にのみ関係します。
  • エージェント タスクは、常にエージェント ID によって実行されます。
• エージェント ID ブループリントまたはエージェント ID は、AAD Token Exchange Endpoint: Public エンドポイント (リソース ID: fb60f99c-7a34-4190-8149-302f77469936) で中間トークン exchangeを実行します。
  • AAD Token Exchange Endpoint: Public スコープのトークンは、Microsoft Graphを呼び出すことはできません。
  • 条件付きアクセスは、エージェント ID またはエージェントのユーザー アカウントからトークンの取得を保護するため、エージェント フローは保護されます。
• セキュリティの既定値 が有効になっています。
• 条件付きアクセスは、Microsoft Entra IDによってセキュリティ保護されたリソースのみを保護します。 たとえば、エージェントが API キーを使用してリソースにアクセスすると、Microsoft Entra ID認証とトークン発行パイプラインが完全にバイパスされ、条件付きアクセス ポリシーは適用されません。

現在、次の構成はサポートされていません。

• "Users" 割り当ての対象となるポリシーは、エージェント ユーザー アカウントには適用されません。 この境界は、ポリシーの対象がすべてのユーザー、選択したユーザー、グループ、ディレクトリ ロール、または外部ユーザーであっても適用されます。 エージェント ユーザー アカウントを保護するには、"エージェント ユーザー" を対象とするポリシーを作成します。
• グループ メンバーシップに基づいて、エージェントのユーザー アカウントを含めたり除外したりするための条件付きアクセス ポリシーのスコープを設定します。
• エージェント ID を対象とする条件付きアクセス ポリシーは、エージェントのユーザー アカウントには適用されません。
• エージェント ID ブループリントを使用してエージェント ID を対象とする条件付きアクセス ポリシーでは、エージェントのユーザー アカウントではなく、エージェント ID のみが対象となります。

代わりに、ポリシーのスコープをエージェント ユーザーに設定するには、[ 割り当て>ユーザー、エージェント、またはワークロード ID] で [ エージェント] を選択し、すべてのエージェント ユーザーまたは特定のエージェント ユーザーを対象とします。

関連するコンテンツ

• 条件付きアクセス ポリシーのターゲット エージェント ID
• 条件付きアクセスを使用して自律エージェントをセキュリティで保護する
• 条件付きアクセスを使用してユーザーとして機能するエージェントをセキュリティで保護する