Microsoft Foundry の Entra エージェント ID を使用して MCP 認証を行う検証

Last updated at 2026-02-02Posted at 2026-02-02

Microsoft Foundry では、Model Context Protocol（MCP）を介してエージェントが外部リソースにアクセスする際、Entra エージェント ID による認証が標準でサポートされています（現在プレビュー中）。これにより、エージェントは Azure のセキュリティ基盤の上で安全に動作し、監査ログの記録や条件付きアクセスによる制御も可能になります。

本記事では、Entra エージェント ID を用いた MCP の2つの認証方式――エージェント ID（Agent Identity）と OAuth Identity Passthrough（OBO：On-Behalf-Of） ――の違いと使い分け、そして条件付きアクセス（Conditional Access）によるエージェント制御の実装方法について、実際の設定手順とともに詳しく解説します。また、デバッグに役立つ MCP サーバーのサンプルコードも GitHub で公開していますので、ぜひ実際に動かしながら理解を深めてください。

1. Entra エージェント ID による MCP 認証

1.1. エージェントが無人で実行する場合

Microsoft Foundry の MCP 連携では認証方式として Microsoft Entra エージェント ID がサポートされます。エージェントが MCP サーバーを呼ぶと、Agent Service が利用可能なエージェント ID で認可トークンを要求し MCP サーバーへ渡すため、MCP サーバー側は Entra トークンで保護できます。この方式はユーザーコンテキストは保持されません。つまり「ユーザーではなく“エージェントとして”実行」する用途に適します。

特徴

トークン主体：Agent Identity（サービスプリンシパル）
ユーザー情報：含まれない
権限管理：RBAC / App Role
シークレット：不要（Foundry がトークン取得）

用途

バックグラウンド処理
Azure リソースへのアクセス (Blob Storage、AI Search ...etc)
組織共通の業務ロジック自動化
エージェント間連携（A2A）

Agent Identity Blueprint の役割

Foundryでは、Agent Identity Blueprint（エージェント ID ブループリント）が重要な役割を果たします。

Blueprintとは

すべての Agent Identity を作成・管理する親テンプレート
Foundry プロジェクト作成時に自動的にプロビジョニングされる
未発行のエージェントはプロジェクト共有の Blueprint を使用
発行後のエージェントは専用の Agent Identity を取得

注意
検証時点では、Entra エージェント ID 認証の時だけ Failed to fetch agentic identity access token with status code: BadRequest となりクライアントから実行できない問題が発生している。そのため、プロジェクト共有のエージェント ID を使って検証している。

2段階認証プロセス

Foundry Agent Serviceは以下の2段階でトークンを取得します：

1. Agent Identity Blueprint → Managed Identity でトークン取得 (T1)
2. Blueprint Token (T1) → Agent Identity トークンに交換 (Impersonation)
3. Agent Identity Token → MCP Server へ渡す

処理フロー

セットアップ: エージェントに Azure リソースへのアクセス権を付与する

Step 1: エージェント ID を取得する
（エージェント用に作成されたサービスプリンシパル）

# Azure Portal → Foundry プロジェクト → JSON View
# 以下のキーを探します:
# "agentIdentityId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Step 2: エージェント ID に RBAC を割り当てる

# 例: エージェントに Blob の読み取り権限のみを付与（削除は不可）
az role assignment create \
  --assignee <agent-identity-id> \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>

Foundry Agent の作成

①ツールの作成

Microsoft Foundry の左メニューから「ツール」を選択し、「ツールを接続」ボタンを押下します。次にカスタムタブを選択し、モデルコンテキストプロトコル (MCP)をチェックして「作成」をクリックします。「接続の編集」では以下のように入力します。

認証: Microsoft Entra
種類: エージェント ID
対象ユーザー: アクセスする対象のサービスのスコープ URI(aud) を入力

Azure Service	Audience URI
Azure Storage	`https://storage.azure.com`
Azure Logic Apps	`https://logic.azure.com`
Microsoft Foundry	`https://ai.azure.com`
Microsoft Graph	`https://graph.microsoft.com`
Azure Key Vault	`https://vault.azure.net`
Azure Cosmos DB	`https://cosmos.azure.com`
Azure AI Search	`https://search.azure.com`

Azure AI Search のセキュリティフィルターとしてファイルを出し分けるデモでもよかったのですが、今回は Azure Blob Storage にアクセスするエージェントをテストするので、https://storage.azure.com を設定します。

② MCP Debug サーバーの起動

Microsoft Foundry からの MCP リクエストをすべて可視化するためのデバッグ用 MCP サーバーを立ち上げておきます。Foudry Agent で指定できる MCP Tool はリモート MCP サーバーである必要があるため、どこかにホスティングする必要があります。私は LIVE で開発したかったので、Azure VM 上で起動しています。

デバッグ用 MCP サーバーには、get_user_info ツールと read_blob_with_token ツールが用意されていますので、それぞれ「ユーザー情報を取得してください」と「●●●.pdfを取得してください」と送信することで実行されます。

③ Agent の作成

この時、どのようなトークンが送信されてきているのか、正しくバックエンド処理が実行されたかどうかなどを確認してください。

④サインインログの確認

Microsoft Entra 管理センターの条件付きアクセスまたはエージェントID->サインインログ　を開き、「サービスプリンシパルのサインイン」からエージェント ID が特定リソース（Azure Blob Storage）へアクセスしたログを確認できます。

これが Entra エージェント ID の強みってわけですね。

1.2. OAuth Identity Passthrough（ユーザー代理 / OBO）

この仕組みではエージェントがユーザーからの認可を受けて MCP サーバーにアクセスする際、ユーザーの資格情報を安全に格納し、ユーザーの資格情報で MCP サーバーやその背後のサービスを呼び出すことができます。

特徴

トークン主体：ユーザー
ユーザー情報：保持される
権限管理：ユーザーの Delegated Permission
シークレット：必要（MCP Server側で必須）

用途

ユーザー固有のデータアクセス・権限制御 (メール送信、OneDrive、Teams)
データの行レベル制御
「誰が実行したか」を厳密に残したい操作

処理フロー

セットアップ

アプリ登録ガイドに従って Microsoft Entra アプリを作成し、クライアント ID とクライアントシークレットを取得します。以下の記事にもフロントエンド App＋ MCP Server App を作成する手順を書いています。

Foundry Agent の作成

①ツールの作成

Foundry ポータルに戻り、MCP サーバーを構成します。ツールを接続し、「カスタム」に移動し、「MCP」を選択します。名前と MCP サーバーエンドポイントを指定し、 OAuth ID パススルーを選択します。

フロントエンド App のクライアント ID とクライアントシークレット
トークン URL: https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token
認証 URL: https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/authorize
更新 URL: https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token
スコープ： api://MCP Server の App ID/access_as_user

② Agent の作成

OAuth ID パススルーが必要な MCP ツールをコールする必要がある場合、「同意を開きます」のようにユーザーのサインインを求めるダイアログが表示されます。

ここで「Allow access」を押下すると、「サインインが成功しました」と表示されます。

段階的にテストするために、「Azure Blob Storage 用の OBO トークンを取得してください」と送信して get_azure_blob_storage_token を実行させてから「●●●.pdfを取得してください」と送信して read_blob_with_token を実行させています。

デバッグ用 MCP Server のログで aud: https://storage.azure.com/ のトークンが表示されていればトークン交換成功です。

🧠 認証フローまとめ

観点	エージェント ID	OAuth Passthrough
実行主体	エージェント	ユーザー
ユーザー文脈	❌	✅
OBO	❌（単体では不可）	✅
条件付きアクセス	可	可
RBAC	エージェントに付与	ユーザーに依存
Foundry 管理	完全マネージド	OAuth 連携

3. 条件付きアクセス（CA）

エージェント ID 向け条件付きアクセスは、AI エージェントをゼロトラストセキュリティポリシーの対象として保護するための比較的新しい機能です。Microsoft Entra ID がこれまで人間ユーザーやサービスプリンシパルに適用してきた条件付きアクセスの原則を、AI エージェントの ID（Agent Identity）とエージェントユーザー（Agent User） にも拡張します。

エージェント ID 向け条件付きアクセスでできること

1. Agent ID / Agent Users を対象にした CA ポリシーの適用

エージェント ID（AI agents）のトークン取得に対して条件付きアクセスを評価し、許可/ブロックが可能。

2. 特定のエージェント ID を “含め/除外” して制御できる

ポリシーの対象に含める/除外することができ、
→ 例えば「承認されたエージェントのみ許可」「特定エージェントをブロック」といった制御が可能。

3. トークン取得時のブロック制御

現時点で唯一の “Grant control” は Block access（アクセスブロック） です。
設定したポリシーに一致する場合、エージェント ID によるトークン発行を停止できます。

4. エージェントに対するリスクベースの制御（プレビュー）

Microsoft Entra のリスク検出シグナルを使って、
→ リスクの高いエージェントのトークン発行をブロックすることが可能です（Preview 状態）。

5. サインインログで評価状況が確認できる

サインインログで CA の診断ができ、
→ なぜ適用された/されなかったかを確認できる（agentType = agent ID/user など）

現時点でサポートされていない制御（機能制限）

エージェント ID の CA は 限定的で、以下の制御は適用されない。

多要素認証（MFA）
認証強度評価
デバイス準拠/ネットワーク条件
承認済みクライアント（Approved client apps）
セッション制御や利用規約
ロケーションベース条件
クライアントアプリ種別条件
これらは 人間ユーザー向けの CA 機能であり、エージェントのフローには適用されません。

条件付きアクセスの影響部分

条件付きアクセスは、トークンを要求した時点で評価され、ブロックされた場合はトークンが返りません。

条件付きアクセスの設定手順

特定のエージェントのみにリソースへのアクセスをブロックする

今回は、特定のエージェントで Azure Blob Storage へのアクセスをブロックする CA ポリシーを作成します。

Microsoft Entra 管理センターに、少なくとも条件付きアクセス管理者および属性割り当て閲覧者としてサインインし、Entra ID -> 条件付きアクセス -> ポリシーに移動して「新しいポリシー」を押下します。
「割り当て」で、ユーザー、エージェント (プレビュー) またはワークロード ID を選択します。ここでは特定のエージェント ID を検索して選択します。
「ターゲットリソース」で、「特定のリソースを選択する」にして、Azure Storage に対するリソース ID を検索します。※ここが重要：ターゲットリソースの ID がわからないので、事前に「サインインログ」からコピーしておく必要がありました。確認方法は後述。
条件付きアクセス->サインインログ　を開き、「サービスプリンシパルのサインイン」からエージェント ID が特定リソースへアクセスしたログを特定し、リソース ID をコピーしておきます。
「アクセス制御」->「許可」で「アクセスのブロック」を選択し、「ポリシーの有効化」を「オン」にして「保存」を押下します。
ある程度時間をおいてから再度メッセージを送信すると以下のようなエラーが返り MCP サーバーにアクセスできなくなります。
サインインログに条件付きアクセスポリシーによる失敗ログが出ていることを確認します。

GitHub: デバッグ用 MCP Server

Microsoft Agent Framework による MCP Client 認証サンプル

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up