MENU

Foundry AgentがサインインユーザーとしてMCPツールを実行する委任設定｜ToolboxesとOAuth2

Azure

Foundry AgentにMCPツールをサインイン中のユーザー権限で実行させるには、MCPサーバーへのプロジェクト接続をoauth2で作成し、その接続をMicrosoft Foundry Toolboxへ登録して、エージェントからToolboxのMCPエンドポイントを呼び出します。

この構成では、OAuth 2.0の認可コード交換、ユーザーごとのトークン分離、アクセストークンの更新、初回同意をFoundry側へ集約できます。エージェントごとにトークンキャッシュや更新処理を実装する必要はありません。(Microsoft for Developers)

ただし、認証が完全に不要になるわけではありません。エージェントからToolboxへの接続にはMicrosoft Entra ID認証が必要です。そのうえで、Toolboxから各MCPサーバーへの呼び出しが、接続ごとに設定されたOAuth2資格情報を使ってサインインユーザーの代理で実行されます。

本記事では、Microsoft Foundry Toolboxesによるユーザー委任の仕組み、azdを使ったOAuth2接続の作成、同意画面の処理、トークン更新、ユーザー間の分離を検証する方法まで解説します。

目次

Microsoft Foundry Toolboxesでユーザー委任を安全に実装する方法

ユーザー委任で重要なのは、エージェント全体をユーザー権限で動かすのではなく、必要なツール呼び出しだけをユーザー権限で実行することです。

たとえば、社内向けの従業員エージェントが次の処理を行うケースを考えます。

  • サインインユーザーが閲覧できる受注情報を検索する
  • ユーザー本人のメールや予定表を参照する
  • ユーザー本人の権限でGitHub Issueを作成する
  • ユーザーがアクセスできるSharePointファイルを検索する

これらをプロジェクトのマネージドIDや共通サービスアカウントで実行すると、すべての利用者が同じ権限で外部サービスへ接続することになります。ユーザーごとのアクセス範囲や監査境界を維持したい場合は、OAuth2によるユーザー委任が必要です。

Foundry Toolboxでは、認証方式をエージェントコードではなく、各ツールの「プロジェクト接続」に設定します。エージェント側は複数の認証方式を意識せず、1つのToolbox MCPエンドポイントを呼び出せます。(Microsoft for Developers)

Toolboxは認証を集約するが、すべてを同じIDで実行するわけではない

1つのToolboxには、異なる認証方式を使うツールをまとめられます。

認証方式ツールへ届く主体主な用途
oauth2同意したサインインユーザーGitHub、SaaS、独自OAuth対応MCP
user-entra-tokenサインインユーザーのEntraトークンFabricなど特定のEntraオーディエンスを受け付けるサービス
agentic-identityエージェント固有のIDエージェント単位のサービス間アクセス
project-managed-identityFoundryプロジェクトのマネージドIDプロジェクト内で共有するサービス間アクセス
custom-keys接続に保存したAPIキーAPIキー方式のSaaSや社内API
none匿名公開MCPサーバー

同じToolboxの中で、受注MCPにはoauth2、Azureリソースにはproject-managed-identity、公開ドキュメント検索にはnoneを使う、といった構成が可能です。Foundryはツールごとの接続設定を見て、適切な資格情報を実行時に注入します。(Microsoft for Developers)

ユーザー委任は2段階の認証として理解する

Foundry Toolboxを使う場合、認証経路は大きく2段階に分かれます。

サインインユーザー
    ↓ ユーザーコンテキストを保持
Hosted Agent／MCPクライアント
    ↓ Foundry向けMicrosoft Entraトークン
Toolbox MCPエンドポイント
    ↓ ユーザー別のOAuth2アクセストークン
MCPサーバー／外部サービス

エージェントからToolboxへの認証

エージェントやMCPクライアントは、ToolboxのMCPエンドポイントへ接続します。Toolboxエンドポイント自体はMicrosoft Entra IDで保護されており、通常は次のスコープでトークンを取得します。

https://ai.azure.com/.default

この認証は、FoundryプロジェクトとToolboxを呼び出すためのものです。

ToolboxからMCPサーバーへの認証

Toolboxは、対象ツールに紐づくプロジェクト接続を参照します。接続がoauth2であれば、そのユーザーが同意したOAuth資格情報を使ってMCPサーバーを呼び出します。

つまり、Toolboxが集約するのは下流ツールごとの認証処理です。エージェントからToolboxへのMicrosoft Entra認証まで不要になるわけではありません。(Microsoft Learn)

ローカルテストと本番のユーザー委任は区別する

ローカル環境でDefaultAzureCredentialを使ってToolboxを呼び出すと、Azure CLIや開発環境にサインインしている開発者の資格情報が利用されます。

これは疎通確認には便利ですが、Webアプリの利用者がブラウザでサインインしたというだけで、そのユーザーコンテキストが自動的にToolboxへ渡るわけではありません。

複数ユーザー向けの本番環境では、サインイン済みユーザーのコンテキストをリクエスト単位で維持できるHosted Agent構成を使用します。Work IQなどユーザー委任を必須とするツールでも、公式ドキュメントはHosted Agent統合によってリクエストごとのユーザーコンテキストを保持する構成を案内しています。(Microsoft Learn)

OAuth2委任を構成するための前提条件

実装を始める前に、次の項目を準備します。

項目確認内容
Foundryプロジェクト利用するリージョンでToolboxと対象ツールがサポートされていること
MCPエンドポイントStreamable HTTPなど、Foundryが接続できるリモートMCPサーバーであること
OAuthアプリクライアントID、必要に応じてクライアントシークレットを取得済みであること
OAuthエンドポイントAuthorization URL、Token URL、必要に応じてRefresh URLを確認していること
スコープMCPツールに必要な最小限の委任スコープを定義していること
Foundry RBAC開発者、ランタイムID、利用者に必要なロールを割り当てていること
対象サービスの権限各ユーザーがMCPの背後にあるサービスへアクセスできること
テナントユーザーとFoundryプロジェクトが同じMicrosoft Entraテナントにあること

一般的なOAuth identity passthroughでは、利用者に少なくともFoundry Agent Consumerロールが必要と案内されています。Foundry Userでも動作しますが、これは主にエージェントを開発する利用者向けです。一方、Toolboxやツール固有の前提条件では、OAuthフローに関係するユーザーへFoundry Userを求める場合があります。対象ツールの公式ドキュメントを優先してください。(Microsoft Learn)

また、OAuth identity passthroughでは、ユーザーのMicrosoft EntraテナントとFoundryプロジェクトのテナントを一致させる必要があります。クロステナントのトークン交換はサポートされていません。(Microsoft Learn)

oauth2とuser-entra-tokenの選び方

ユーザー本人の権限で実行したい場合でも、必ずoauth2を選ぶとは限りません。

oauth2を選ぶケース

次の情報を持つ一般的なOAuth 2.0対応サービスでは、oauth2を使用します。

  • Authorization URL
  • Token URL
  • クライアントID
  • クライアントシークレット
  • OAuthスコープ
  • ユーザー同意画面

GitHubなどのSaaSや、独自に構築したOAuth対応MCPサーバーが該当します。

user-entra-tokenを選ぶケース

MCPサーバーがMicrosoft Entra IDで保護され、特定のオーディエンス向けに発行されたユーザートークンを直接受け付ける場合は、user-entra-tokenを使用します。

たとえば、対象サービスが次のようなオーディエンスを要求するケースです。

https://analysis.windows.net/powerbi/api

この場合はAuthorization URLやクライアントシークレットではなく、--audienceで対象リソースを指定します。(Microsoft Learn)

azdでOAuth2接続を作成する手順

以下は、独自のOAuthアプリ登録を使用して、リモートMCPサーバーへ接続する構成例です。

microsoft.foundry拡張や一部のFoundry機能は更新が続いているため、実行時には最新版のazdを利用し、azd ai connection create --helpも確認してください。現行ドキュメントではazd 1.25系以降が前提とされています。(Microsoft Learn)

azdとFoundry拡張を準備する

PowerShellで次のコマンドを実行します。

azd version
azd auth login

azd ext install microsoft.foundry

$env:PROJECT_ENDPOINT = "https://<account>.services.ai.azure.com/api/projects/<project>"
azd ai project set $env:PROJECT_ENDPOINT

PROJECT_ENDPOINTには、Foundryプロジェクトの概要画面に表示されるプロジェクトエンドポイントを指定します。

すでに旧版の個別拡張をインストールしている場合は、現在の統合拡張との競合を避けるため、拡張の一覧とバージョンを確認してください。

OAuthアプリのスコープを設計する

OAuthスコープは、MCPサーバーが実際に必要とする権限だけに限定します。

たとえば、MCPサーバーが受注情報の参照だけを提供する場合、読み取り専用スコープを定義します。

api://<mcp-api-app-id>/Orders.Read

更新機能も必要な場合でも、最初から読み書き可能な大きなスコープを与えるのではなく、次のように分離した方が安全です。

api://<mcp-api-app-id>/Orders.Read
api://<mcp-api-app-id>/Orders.Write

OAuthスコープを複数指定するときは、カンマではなく半角スペースで区切ります。トークンを自動更新するため、可能であればoffline_accessも含めます。(Microsoft Learn)

OAuth2のプロジェクト接続を作成する

Microsoft Entra IDで保護した独自MCPサーバーを例にすると、接続作成コマンドは次のようになります。

$TenantId = "<tenant-id>"
$ClientId = "<oauth-client-id>"
$ClientSecret = $env:FOUNDRY_MCP_CLIENT_SECRET
$McpEndpoint = "https://orders.example.com/mcp"

azd ai connection create orders-mcp-oauth `
  --kind remote-tool `
  --target $McpEndpoint `
  --auth-type oauth2 `
  --authorization-url "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/authorize" `
  --token-url "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" `
  --client-id $ClientId `
  --client-secret $ClientSecret `
  --scopes "api://<mcp-api-app-id>/Orders.Read offline_access"

各オプションの意味は次のとおりです。

オプション内容
--kind remote-toolリモートツール接続として登録する
--targetMCPサーバーのエンドポイント
--auth-type oauth2OAuth2のユーザー委任を使用する
--authorization-urlユーザーを認可画面へ誘導するURL
--token-url認可コードや更新トークンを交換するURL
--client-idOAuthクライアントのID
--client-secretConfidential Clientで使用するシークレット
--scopesユーザーに要求する委任権限

公開されているazdのOAuth2例でも、--authorization-url、--token-url、--client-id、--client-secret、--scopesを指定します。(Microsoft Learn)

クライアントシークレットをソースコード、toolbox.yaml、Gitリポジトリへ直接記載してはいけません。CI/CDではシークレットストアから環境変数へ渡し、コマンド出力やデバッグログにも残さないようにします。

Refresh URLを確認する

カスタムOAuth設定では、FoundryがRefresh URLを求める場合があります。OAuthプロバイダーが独立した更新用エンドポイントを提供していない場合は、Token URLと同じURLを使用できます。

offline_accessをスコープに含めても、OAuthプロバイダー側が更新トークンを発行しない構成では自動更新できません。アプリ登録、同意設定、OAuthプロバイダーの仕様を併せて確認してください。(Microsoft Learn)

接続の作成結果を確認する

azd ai connection show orders-mcp-oauth --output json

少なくとも次の点を確認します。

  • 接続先が意図したMCPエンドポイントである
  • 認証方式がOAuth2になっている
  • 誤ったテナントのAuthorization URLを指定していない
  • 想定したスコープが設定されている
  • 別のテスト用接続を上書きしていない

接続の一覧は次のコマンドで確認できます。

azd ai connection list

FoundryのリダイレクトURIをOAuthアプリへ登録する

カスタムOAuth接続を作成すると、FoundryがOAuthコールバックに使用するリダイレクトURLが表示されます。

Microsoft Entraのアプリ登録では、次の流れで登録します。

  1. Microsoft Entra管理センターで対象のアプリ登録を開く
  2. 「認証」を開く
  3. Webプラットフォームを追加する
  4. Foundryが表示したリダイレクトURIを登録する
  5. 保存後にOAuth接続を再確認する

リダイレクトURIが一致していないと、ユーザーが認可画面で同意してもFoundryへ制御を戻せません。(Microsoft Learn)

管理コネクタのOAuth2とは混同しない

Foundry Tools CatalogにあるBox、Outlook、GitHubなどの管理コネクタは、独自MCPサーバーとは作成手順が異なります。

管理コネクタでは、次のようにコネクタ名を指定するフローがあります。

azd ai connection create my-box-conn `
  --connector-name box

その後、ユーザー同意と、MCPツールとして公開するアクションの登録が必要です。独自OAuthアプリを使う--authorization-url方式と、カタログの--connector-name方式を混在させないようにしてください。(GitHub)

OAuth2接続をToolboxへ登録する

接続を作成しただけでは、エージェントからToolboxとして利用できません。接続名を参照するtoolbox.yamlを作成します。

description: Employee tools with delegated user authentication

connections:
  - name: orders-mcp-oauth

YAMLにはクライアントシークレットやアクセストークンを記載しません。資格情報はプロジェクト接続が保持し、Toolboxは接続名だけを参照します。

次のコマンドでToolboxを作成します。

azd ai toolbox create employee-toolbox `
  --from-file .\toolbox.yaml `
  --no-prompt

作成結果を確認します。

azd ai toolbox show employee-toolbox --output json

Toolboxへ別のOAuth2接続、マネージドID接続、APIキー接続を追加しても、エージェントが参照するのは同じToolboxエンドポイントです。認証設定を各エージェントへ複製する必要はありません。(Microsoft Learn)

Foundry AgentからToolboxを呼び出す

Toolboxには、バージョン固定の開発用エンドポイントと、既定バージョンを参照する利用者向けエンドポイントがあります。

エンドポイント用途
/toolboxes/{name}/versions/{version}/mcp新バージョンのテスト
/toolboxes/{name}/mcpエージェントからの通常利用

本番のエージェントでは、原則として既定バージョンを参照するコンシューマーエンドポイントを使います。

https://<account>.services.ai.azure.com/api/projects/<project>/toolboxes/employee-toolbox/mcp?api-version=v1

新しいToolboxバージョンをテストしてから既定バージョンへ昇格すれば、エージェントコードや接続先URLを変更せずにツール構成を更新できます。(Microsoft Learn)

Microsoft Agent Frameworkでの構成は、概念的には次のようになります。

PROJECT_ENDPOINT = "<foundry-project-endpoint>"

TOOLBOX_ENDPOINT = (
    f"{PROJECT_ENDPOINT}"
    "/toolboxes/employee-toolbox/mcp?api-version=v1"
)

toolbox = MCPStreamableHTTPTool(
    name="employee_toolbox",
    url=TOOLBOX_ENDPOINT,
)

agent = Agent(
    client=FoundryChatClient(
        project_endpoint=PROJECT_ENDPOINT,
        credential=credential,
    ),
    tools=[toolbox],
)

エージェントコードは受注MCPやGitHubなど、下流ツールごとのAuthorization URL、Token URL、アクセストークンを扱いません。Toolboxを1つのMCPサーバーとして利用します。(Microsoft for Developers)

初回同意をアプリケーションで処理する

OAuth2接続を作成しても、管理者や開発者のトークンが全利用者に共有されるわけではありません。

各ユーザーは、そのFoundryプロジェクト内で新しいOAuth接続を初めて利用するときに、自分のアカウントで同意する必要があります。OAuthの同意単位は、基本的に「Foundryプロジェクト、接続名、ユーザー」の組み合わせです。(Microsoft Learn)

MCPエンドポイントを直接呼ぶ場合

ToolboxのMCPエンドポイントは、同意が必要な場合にCONSENT_REQUIREDを返すことがあります。

{
  "error": {
    "code": -32006,
    "message": "User consent is required. Please visit: <consent-url>"
  }
}

アプリケーションはエラーとして終了するのではなく、URLをユーザーへ表示し、認可完了後に同じ処理を再実行します。(Microsoft Learn)

Responses API経由の場合

Responses APIでは、次のようなoauth_consent_requestが出力に含まれます。

{
  "type": "oauth_consent_request",
  "consent_link": "<consent-url>"
}

実装側では次の流れが必要です。

  1. oauth_consent_requestを検出する
  2. consent_linkをボタンやリンクとしてユーザーへ表示する
  3. ユーザーが同意を完了する
  4. 元のレスポンスIDを使って処理を継続するか、同じツール呼び出しを再試行する
  5. 同意を拒否した場合は、そのツールを利用できないことを明確に伝える

通常は一度同意すれば、同じユーザーが同じ接続を利用するたびに再同意する必要はありません。(Microsoft Learn)

同意URLは機密情報として扱う

同意URLには、OAuth処理を継続するための状態情報が含まれることがあります。

次の扱いは避けてください。

  • アプリケーションログへの無制限な記録
  • 分析基盤への送信
  • 他ユーザーとの共有
  • 長期間の保存
  • チャット履歴への平文保存

ユーザーへ表示する必要はありますが、アクセストークンと同様に慎重に扱います。

トークン更新をFoundryへ任せるための設定

Toolboxは、ユーザーごとの資格情報を安全に保持し、アクセストークンの取得や更新をサーバー側で処理します。

自動更新を成立させるため、OAuthプロバイダーが対応している場合はスコープにoffline_accessを含めます。

api://<mcp-api-app-id>/Orders.Read offline_access

これにより、短時間で期限切れになるアクセストークンをアプリケーション側で保存、更新する処理を省けます。(Microsoft Learn)

ただし、次の場合は再同意が必要になる可能性があります。

  • 管理者が同意を取り消した
  • ユーザーがアプリへの許可を削除した
  • OAuthスコープを変更した
  • クライアントシークレットやアプリ登録を変更した
  • 条件付きアクセスや組織ポリシーが変わった
  • 更新トークンを利用できなくなった

「初回同意しか発生しない」と決めつけず、実行時には常にCONSENT_REQUIREDまたはoauth_consent_requestを処理できるようにします。

ユーザー別トークン分離はどのように行われるか

Toolboxを使わずにユーザー委任を実装する場合、アプリケーション側で次の情報を正しく組み合わせてトークンキャッシュを分離する必要があります。

  • ユーザーID
  • テナントID
  • OAuthクライアント
  • 対象リソース
  • スコープ
  • 接続先
  • トークンの有効期限

キャッシュキーの設計を誤ると、ユーザーAのトークンをユーザーBの処理で再利用する重大な事故につながります。

Foundry Toolboxでは、ユーザーごとのトークン分離をFoundryが管理します。エージェント開発者が独自のトークンキャッシュを持つ必要はありません。新しいユーザーが接続を初めて使う場合は、そのユーザー専用の同意フローが開始されます。(Microsoft for Developers)

ただし、Toolboxがユーザー分離を行っても、ホストアプリケーションがすべてのリクエストを同じサービスIDで呼び出していれば、正しいユーザー委任にはなりません。複数ユーザー環境では、呼び出し元ユーザーのコンテキストがHosted Agentまで維持されていることを必ず検証してください。

実装時に守るべきセキュリティ設計

読み取りと更新の権限を分ける

検索や一覧取得だけを行うツールと、作成・更新・削除を行うツールは、可能であれば接続やスコープを分けます。

たとえば、通常の質問応答ではOrders.Readだけを使い、注文変更を行う専用フローでのみOrders.Writeを要求します。これにより、エージェントが意図せず更新操作を選んだ場合の影響を抑えられます。

書き込みツールには承認を要求する

メール送信、Issue作成、ファイル削除、データ更新などの操作には、require_approval="always"を設定するのが安全です。

注意したいのは、Toolbox MCPエンドポイントが承認設定のメタデータを返しても、tools/call自体を自動的に停止するわけではない点です。承認画面を表示し、ユーザーの確認後に呼び出す処理は、エージェントランタイム側で実装する必要があります。(Microsoft Learn)

公式サンプルにrequire_approval="never"が記載されていても、業務データを書き換えるツールへそのまま適用しないでください。

カスタムMCPへMicrosoft向けトークンを流用しない

Managed OAuthでは、既知のMicrosoftオーディエンス向けトークンを、信頼されていないカスタムMCPエンドポイントへ送ることが制限されています。

次のエラーが出る場合があります。

Cannot pass Microsoft token to untrusted MCP endpoint.

独自MCPサーバーでは、自組織が管理するオーディエンスを設定し、独自のMicrosoft Entraアプリ登録を使うカスタムOAuth構成にします。MCPが受け取ったMicrosoft向けトークンを、そのまま別のMicrosoftサービスへ転送する設計も避けてください。(Microsoft Learn)

Toolboxのバージョンを直接本番へ出さない

新しいツールやスコープを追加するときは、バージョン固定エンドポイントで先に検証します。

/toolboxes/employee-toolbox/versions/<version>/mcp?api-version=v1

次の項目を確認してから既定バージョンへ昇格します。

  • 想定外のツールが公開されていない
  • ツール名と説明がモデルに誤解されない
  • 必要以上のOAuthスコープを要求していない
  • 書き込み操作に承認が設定されている
  • ユーザーAとユーザーBの結果が分離されている
  • 同意拒否時にエージェントがループしない

サードパーティ製MCPのデータ送信先を確認する

Toolbox自体は組織が管理するFoundryリソースですが、接続先のMCPサーバーやSaaSまでMicrosoftが管理しているとは限りません。

プロンプト、ツール引数、検索語、取得したデータが外部サービスへ送信される可能性があります。利用規約、データ保存場所、ログ保持期間、料金、接続先の発行元を確認してください。(Microsoft Learn)

無人実行にはユーザー委任を使わない

スケジュール実行やバックグラウンド処理では、サインイン中のユーザーが存在しません。

FoundryのRoutineも、エンドユーザーIDを実行時に必要とするエージェントを呼び出せません。無人処理では、agentic-identityやproject-managed-identityなど、実行主体が明確なサービス用IDを使用します。(Microsoft Learn)

よくあるエラーと対処方法

症状主な原因対処
CONSENT_REQUIRED、コード-32006初回同意が未完了同意URLをユーザーへ表示し、完了後に再試行する
oauth_consent_requestが出ないOAuth2接続でない、またはツールが呼ばれていない接続のauthTypeと、モデルが実際にMCPツールを選択したか確認する
同意後も401になるToken URL、クライアントID、シークレット、リダイレクトURIの不一致OAuthアプリ登録とFoundry接続を照合する
Toolboxへの呼び出しが401になるFoundry向けトークンのスコープが違うhttps://ai.azure.com/.defaultでトークンを取得する
同意後に403になるユーザーが対象サービスのデータへアクセスできないMCPの背後にあるサービスの権限、ライセンス、管理者同意を確認する
毎回同意を求められるoffline_access不足、更新失敗、接続名やプロジェクトが変わっているスコープ、Refresh URL、OAuthプロバイダーの更新トークン設定を確認する
クロステナントユーザーだけ失敗するFoundryのOAuth identity passthroughはクロステナント交換に非対応Foundryプロジェクトと同じテナントのユーザーを利用する
Microsoftトークンを送信できないMicrosoft向けトークンをカスタムMCPへ送ろうとしている自組織管理のオーディエンスとカスタムOAuthアプリを使う
書き込みが確認なしで実行されるrequire_approval未設定、またはランタイムが承認を実装していないToolbox設定とエージェント側の承認ループを両方確認する
全ユーザーが同じデータを取得する共通IDでToolboxを呼んでいる、ユーザーコンテキストが失われているHosted Agentまでの認証経路を見直し、複数ユーザーで分離テストする

OAuth同意、401、403の切り分けでは、Toolboxへの認証と、ToolboxからMCPへの認証を分けて確認することが重要です。(Microsoft Learn)

ユーザー委任が正しく動いているか確認するテスト

本番公開前には、最低でも2人のテストユーザーを用意します。

ユーザーAの初回実行

  1. ユーザーAでエージェントへサインインする
  2. OAuth2を使うMCPツールを呼び出す
  3. 同意URLがユーザーAへ表示されることを確認する
  4. 同意後にツール呼び出しが成功することを確認する
  5. 2回目の呼び出しでは再同意が発生しないことを確認する

ユーザーBの初回実行

  1. ユーザーBで同じエージェントへサインインする
  2. ユーザーBにも別の同意フローが表示されることを確認する
  3. ユーザーAの同意がユーザーBへ流用されないことを確認する
  4. ユーザーBが閲覧できないデータを取得できないことを確認する

公式ドキュメントでも、別ユーザーを使ってユーザー単位の同意フローを検証することが推奨されています。(Microsoft Learn)

権限差を使った分離テスト

ユーザーAには全受注データ、ユーザーBには自部門の受注データだけを付与します。

同じプロンプトを実行し、返される結果がユーザー権限に応じて変化することを確認します。

今月の未処理注文を一覧にしてください

両ユーザーに同じ結果が返る場合は、次を調査します。

  • エージェントがサービスアカウントで呼び出していないか
  • OAuth2ではなくマネージドID接続を使っていないか
  • Hosted Agentがユーザーコンテキストを保持しているか
  • MCPサーバーがアクセストークンのユーザー情報を無視していないか
  • MCPの背後にあるAPIが独自の共通権限で再接続していないか

書き込み操作の承認テスト

ユーザーの代理で更新を行うツールでは、次の項目も確認します。

  • 実行前に操作内容が表示される
  • 対象、変更内容、送信先を確認できる
  • キャンセルした場合はツールが呼ばれない
  • 承認者、実行時刻、ツール名、結果を監査できる
  • ログにアクセストークンやクライアントシークレットが記録されない

まずは読み取り専用MCPから導入する

Foundry Agentのユーザー委任は、次の順序で導入すると安全です。

  1. 読み取り専用のMCPツールを1つ選ぶ
  2. 最小限の委任スコープを定義する
  3. offline_accessを含むOAuth2接続をazdで作成する
  4. 接続名だけを記載したToolboxを作成する
  5. Hosted AgentからToolboxのコンシューマーエンドポイントへ接続する
  6. 初回同意をユーザーへ表示する処理を実装する
  7. 権限の異なる2ユーザーでトークン分離を確認する
  8. 書き込みツールを追加する前に承認処理と監査を整備する

Microsoft Foundry Toolboxesを使う最大の利点は、OAuth2認証を各エージェントへ重複実装せず、接続単位で集約できることです。ユーザー別トークンの分離、同意、更新をFoundryへ任せつつ、エージェント側ではユーザーコンテキストの保持、最小権限、操作承認、監査に集中できます。

Azure
OAuth 2.0 MCP Microsoft Foundry Azure Developer CLI Foundry Toolboxes

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次