.NETでMCPサーバーを使ってAIエージェントや社内Copilot型アプリを作っている場合、今回の「Agent Governance Toolkit MCP Extensions for .NET」は早めに確認すべき更新です。結論から言うと、MCPサーバーにポリシー制御、起動時のツール検査、フォールバック時のガバナンス、レスポンスのサニタイズをまとめて追加できるPublic Previewパッケージが登場しました。既存のMCPサーバーに大きな設計変更を入れるというより、IMcpServerBuilderにWithGovernance(...)を追加して、危険なツール公開や不適切なツール実行を防ぎやすくするための更新です。(Microsoft for Developers)
特に管理者や開発者が見るべきポイントは、既定で安全側に倒す設計になっていることです。設定によっては、これまで起動できていたMCPサーバーがツール検査で止まったり、認証済みエージェントIDがない呼び出しがブロックされたりする可能性があります。公開前に、ポリシー、認証、監査ログ、レスポンス加工の影響をステージング環境で確認しておきましょう。
.NETのAI/Copilot開発で何が変わるのか
今回発表されたMicrosoft.AgentGovernance.Extensions.ModelContextProtocolは、公式MCP C# SDK向けのPublic Preview companion packageです。Microsoftの説明では、IMcpServerBuilderに対して1回の拡張呼び出しを追加することで、MCPサーバーにガバナンス機能を組み込めるようになります。(Microsoft for Developers)
MCPは、AIアプリケーションを外部のデータソース、ツール、ワークフローにつなぐためのオープンな標準です。ファイル、データベース、検索、社内APIなどをAIエージェントから扱いやすくする一方で、エージェントに実行権限を渡す範囲が広がるため、ツール登録や実行結果をどう安全に制御するかが重要になります。(Model Context Protocol)
今回の更新を実務目線で整理すると、次のようになります。
| 変更点 | 何ができるか | 実務上の確認ポイント |
|---|---|---|
WithGovernance(...)の追加 | MCPサーバーのbuilderパイプラインにガバナンスを追加できる | 既存のAddMcpServer()設定にどこで組み込むか確認する |
| 起動時ツールスキャン | 危険なツール定義を公開前に検出する | 本番起動時に意図せず停止しないよう、検査結果を事前に確認する |
| ポリシーによる実行制御 | ツールごとに許可、拒否、レート制限を設定できる | まずdefault_action: denyで必要なツールだけ許可する設計にする |
| 認証済みIDの利用 | エージェントIDに基づいてツール実行を評価できる | ID解決ロジックと認証基盤の連携を確認する |
| レスポンスサニタイズ | ツールの戻り値から危険な指示文や資格情報らしき文字列を除去できる | 業務上必要な文字列まで過剰に削られないかテストする |
| 監査・メトリクス | ブロックや評価結果を追跡しやすくする | 運用監視、インシデント調査、変更管理に使える形で保存する |
なぜMCPサーバーにガバナンスが必要なのか
MCPサーバーは、AIエージェントに「使える道具」を渡す仕組みです。たとえば、社内ドキュメント検索、顧客データベース参照、チケット作成、ファイル読み取り、API呼び出しなどをツールとして公開できます。
便利な一方で、次のようなリスクがあります。
| リスク | 具体例 | 放置した場合の影響 |
|---|---|---|
| ツール定義の汚染 | ツール説明文に「以前の指示を無視せよ」のような文言が混入する | モデルが悪意ある指示を通常のコンテキストとして扱う可能性がある |
| 権限の広がりすぎ | 誰でも高権限ツールを呼び出せる | データ漏えいや誤操作につながる |
| 類似名ツールの混入 | read_fileに似たread_flieのような名前が登録される | 意図しないツール選択や偽装に気づきにくい |
| 出力経由の攻撃 | ツール結果にプロンプトインジェクションや外部送信URLが含まれる | ツール結果を再びモデルに渡すと攻撃が連鎖する |
| 監査不足 | どのエージェントが何を呼び出したか分からない | 障害時やインシデント時の調査が難しくなる |
公式記事でも、MCPによりツール統合は容易になる一方で、どのツールを登録し、何を実行し、ツール呼び出しの結果をどう扱うかを管理する必要があると説明されています。今回の拡張パッケージは、こうした制御を個別実装ではなく共通のbuilder拡張として扱えるようにするものです。(Microsoft for Developers)
追加される主な機能
WithGovernance(...)でガバナンスをまとめて組み込める
導入の基本形は、NuGetパッケージを追加し、MCPサーバー設定時にWithGovernance(...)を呼び出す流れです。
dotnet add package Microsoft.AgentGovernance.Extensions.ModelContextProtocolusing AgentGovernance.Extensions.ModelContextProtocol;
builder.Services
.AddMcpServer()
.WithGovernance(options =>
{
options.PolicyPaths.Add("policies/mcp.yaml");
options.DefaultAgentId = "did:mcp:server";
options.ServerName = "contoso-support";
});公式記事では、この1回の呼び出しで、ツール定義の事前スキャン、実行時のポリシー評価、レスポンスサニタイズ、監査とメトリクスの計装が登録されると説明されています。(Microsoft for Developers)
ただし、NuGet上の移行メモでは、RequireAuthenticatedAgentIdが既定でtrueになり、DefaultAgentIdはRequireAuthenticatedAgentId = falseを明示した場合にのみ使われるとされています。さらに、context.Items["agent_id"]はガバナンスID解決には使われません。既存実装で匿名IDやコンテキスト項目に依存している場合は、移行時に必ず見直してください。([NuGet][3])
起動時に危険なツール定義を検査する
この拡張では、MCPサーバーのツールがクライアントに公開される前にスキャンされます。公式情報では、既定で危険なツールが検出されると起動に失敗する、つまり「fail closed」の挙動になると説明されています。(Microsoft for Developers)
検出対象として示されている脅威カテゴリには、tool poisoning、typosquatting、hidden instructions、rug pulls、schema abuse、cross-server attacks、description injectionなどがあります。たとえば、ツール説明文にプロンプトインジェクション風の文言が入っている、名前が既存ツールに紛らわしい、入力スキーマでtokenやpasswordのような機密値を要求している、といったケースが確認対象になります。(Microsoft for Developers)
運用上は、ここが最も「良い意味で壊れる」ポイントです。これまで暗黙的に登録されていたツールが、スキャンにより危険と判断されて起動できなくなる可能性があります。本番に入れる前に、全ツールの名称、説明文、入力スキーマを棚卸ししておきましょう。
YAMLポリシーでツール実行を制御する
ツール実行時には、Agent Governance Toolkitのポリシーモデルに基づいて許可や拒否を判断できます。公式記事では、YAMLベースのポリシーにより、どのツールを許可、拒否、レート制限するかをアプリケーションコードの外で管理できると説明されています。(Microsoft for Developers)
たとえば、最小構成の考え方は次のようになります。
apiVersion: governance.toolkit/v1
version: "1.0"
name: mcp-governance-policy
default_action: deny
rules:
- name: allow-echo
condition: "tool_name == 'echo'"
action: allow
priority: 10実務では、まずdefault_action: denyを基本にし、必要なツールだけを許可する設計が安全です。最初から広く許可して後で絞る方法は、AIエージェントのツール利用では事故につながりやすくなります。特に、ファイル読み取り、HTTPリクエスト、データベース問い合わせ、メール送信、チケット更新など「外部へ影響を与えるツール」は、読み取り専用ツールとは別のルールで管理するべきです。
認証済みエージェントIDを使って判断できる
ガバナンス評価では、認証済みIDが存在する場合、そのエージェントIDを利用できます。公式記事では、認証済みIDがない場合に構成可能な既定DIDへフォールバックできる設計が説明されていますが、NuGetの移行メモでは認証済みエージェントID要求が既定で有効になっている点に注意が必要です。(Microsoft for Developers)
本番運用では、匿名のDefaultAgentIdに安易に頼らない方が安全です。たとえば、社内Copilot、管理者用エージェント、顧客対応エージェント、検証用エージェントで同じツール権限を共有すると、権限管理が曖昧になります。AgentIdResolverなどを使い、認証基盤から一意のエージェントIDを取り出せるようにしておきましょう。
ツール出力をモデルに返す前にサニタイズする
MCPでは、ツールの戻り値がそのままモデルのコンテキストに戻されることがあります。ここに「以前の指示を無視して」などの文言、資格情報らしき文字列、外部送信を促すURLが含まれていると、次の推論やツール呼び出しに影響する可能性があります。
今回の拡張では、既定でテキストレスポンスをサニタイズし、プロンプトインジェクションタグ、命令上書きの表現、資格情報漏えいパターン、外部送信を狙うURLなどを検査して危険な断片を編集する設計になっています。(Microsoft for Developers)
ただし、サニタイズは万能ではありません。業務データに含まれる文字列が誤検知されることもあります。たとえば、セキュリティ研修用の教材、ログ分析ツール、メール本文解析ツールでは、攻撃文言そのものを正当なデータとして扱うことがあります。こうした用途では、サニタイズ結果の差分を確認し、必要に応じて閾値や例外設計を調整してください。
影響を受ける管理者・開発者・運用担当者
今回の更新は、単なるライブラリ追加ではなく、MCPサーバーの安全設計に関わる変更です。影響範囲は開発者だけにとどまりません。
| 対象者 | 確認すべきこと | 具体的な行動 |
|---|---|---|
| .NET開発者 | WithGovernance(...)の組み込み位置、認証IDの解決方法、ポリシー読み込み | ローカルとステージングでツール呼び出しテストを行う |
| システム管理者 | 本番起動時にツールスキャンで停止しないか | 起動ログ、監査ログ、メトリクスの収集先を決める |
| セキュリティ担当者 | 許可すべきツール、拒否すべきツール、レート制限対象 | YAMLポリシーをレビューし、変更承認フローに乗せる |
| SRE・運用担当者 | ブロック増加、レイテンシ、サニタイズによる結果変化 | メトリクスとアラート条件を設計する |
| プロダクト責任者 | Public Preview採用のリスク | 重要業務への適用範囲とロールバック手順を決める |
特に注意したいのは、既定設定が安全側に寄っている点です。公式記事では、ScanToolsOnStartup = true、FailOnUnsafeTools = true、SanitizeResponses = true、GovernFallbackHandlers = true、EnableAudit = true、EnableMetrics = trueなどが有効になる構成が示されています。(Microsoft for Developers)
管理者が確認すべき設定
ポリシーファイルの配置と変更管理
options.PolicyPaths.Add("policies/mcp.yaml");のように、ポリシーファイルのパスを指定します。ここで重要なのは、ポリシーをアプリケーションコードから切り離すことです。ツール権限は頻繁に見直されるため、コード内のif文に分散させると、レビュー漏れや環境差分が発生しやすくなります。
おすすめは、ポリシーファイルをGitで管理し、変更時に次の項目を必ずレビューすることです。
- 新しく許可したツールが、外部API、ファイル、データベース、メール送信などにアクセスしないか
default_actionが不用意にallowになっていないか- 本番用、検証用、開発用のポリシーが混在していないか
- ルールの優先度により、拒否ルールが意図せず上書きされないか
- レート制限が必要なツールに制限が設定されているか
エージェントIDの解決方法
NuGetのサンプルでは、AgentIdResolverでagent_idクレームやClaimTypes.NameIdentifierからIDを取り出す例が示されています。([NuGet][3])
using System.Security.Claims;
builder.Services
.AddMcpServer()
.WithGovernance(options =>
{
options.PolicyPaths.Add("policies/mcp.yaml");
options.AgentIdResolver = static principal =>
principal.FindFirst("agent_id")?.Value
?? principal.FindFirst(ClaimTypes.NameIdentifier)?.Value;
});本番環境では、エージェントIDを「ログに出せる識別子」と「権限判断に使う識別子」の両方として扱います。後から調査できるよう、エージェントID、ユーザーID、テナントID、呼び出し元アプリケーション名をひも付けられる設計にしておくと、インシデント対応が楽になります。
起動時スキャンの扱い
FailOnUnsafeToolsが有効な場合、危険と判断されたツールがあると起動に失敗する可能性があります。これはセキュリティ上は望ましい挙動ですが、運用面では「デプロイしたら本番が起動しない」というリスクにもなります。
展開前に、少なくとも次の確認を行ってください。
| 確認項目 | 確認内容 |
|---|---|
| ツール名 | 既存ツールと紛らわしい名前、タイプミス風の名前がないか |
| 説明文 | モデルへの命令に見える文言が入っていないか |
| 入力スキーマ | password、token、system_promptなどの機密値を要求していないか |
| 外部通信 | 任意URLへのアクセスや外部送信を許す設計になっていないか |
| 失敗時の通知 | 起動失敗を監視で検知できるか |
監査ログとメトリクス
Agent Governance Toolkitは、監査やメトリクスの仕組みと組み合わせて、ポリシー判断やブロックを追跡しやすくする設計です。関連する公式記事では、ポリシー判断、ブロックされたツール呼び出し、レート制限、評価レイテンシなどのメトリクスを扱えることが説明されています。(Microsoft for Developers)
運用では、単にログを出すだけでなく、次のような観点でダッシュボード化すると実用的です。
- ブロックされたツール呼び出し件数
- エージェントID別の拒否回数
- レート制限に達したツール
- サニタイズが発生したレスポンス数
- ガバナンス評価にかかった時間
- ポリシー変更後の拒否率変化
「ブロックされたから安全」と考えるだけでは不十分です。拒否が急増している場合、攻撃の兆候だけでなく、ポリシー変更ミスや正当な業務フローの破損も疑う必要があります。
開発者向けの導入手順
既存のMCPサーバー構成を確認する
まず、現在のMCPサーバーが公式MCP C# SDKのbuilderモデルで構成されているかを確認します。今回のパッケージは、公式C# SDKのIMcpServerBuilderに対してガバナンスを追加する設計です。フォークしたSDK、独自プロキシ、独自抽象化を前提にするものではないと説明されています。(Microsoft for Developers)
NuGet情報では、Microsoft.AgentGovernance.Extensions.ModelContextProtocolはPublic Preview companion packageであり、net8.0が含まれるターゲットフレームワークとして示されています。また、依存関係としてMicrosoft.AgentGovernanceとModelContextProtocolが掲載されています。([NuGet][3])
最小ポリシーから始める
最初から全ツールに複雑な条件を入れると、動作確認が難しくなります。まずは、影響の少ないツールだけを許可する最小ポリシーを作ります。
apiVersion: governance.toolkit/v1
version: "1.0"
name: mcp-governance-policy
default_action: deny
rules:
- name: allow-health-check
condition: "tool_name == 'health_check'"
action: allow
priority: 10
- name: allow-read-docs
condition: "tool_name == 'search_internal_docs'"
action: allow
priority: 20この段階で見るべきことは、機能の多さではなく、ポリシーが確実に効いているかです。許可していないツールが拒否されるか、拒否時に適切なエラーが返るか、監査ログに残るかを確認します。
ステージングで攻撃パターンを試す
MCPサーバーの安全性は、正常系だけでは判断できません。ステージング環境では、次のようなテストデータを使って挙動を確認してください。
| テスト内容 | 期待する結果 |
|---|---|
| ツール説明文に命令上書き文を入れる | 起動時スキャンで検出される |
| 許可していないツールを呼ぶ | ポリシーで拒否される |
| 認証なしでツールを呼ぶ | 認証済みIDが必要な構成では拒否される |
| ツール出力に資格情報風の文字列を含める | サニタイズや監査対象になる |
| 短時間に大量呼び出しする | レート制限やメトリクスで把握できる |
ここで重要なのは、ブロックされるかどうかだけでなく、業務上必要な処理が誤って止まらないかを見ることです。AIセキュリティ対策は強くしすぎても現場で回らなくなります。検出閾値やポリシーは、リスクと使い勝手のバランスを取りながら調整しましょう。
移行・展開時に失敗しやすいポイント
認証済みエージェントIDを前提にしていない
今回の移行で最も見落としやすいのが、認証済みエージェントIDの扱いです。NuGetの移行メモでは、RequireAuthenticatedAgentIdが既定でtrue、DefaultAgentIdは明示的に認証要求を無効にした場合のみ使われるとされています。([NuGet][3])
開発環境で匿名呼び出しを前提にしていたMCPサーバーは、本番相当の認証設定で動かすと失敗する可能性があります。単にRequireAuthenticatedAgentId = falseにして動かすのではなく、なぜ認証済みIDを渡せないのかを先に確認してください。
ツール説明文を「人間向けの説明」として雑に書いている
MCPのツール説明文は、人間だけでなくモデルにも読まれます。説明文に「必ずこの手順で実行」「ユーザーに確認せず進める」などの曖昧な指示が混ざると、スキャンやポリシー評価で問題になる可能性があります。
ツール説明文は、次のように書くと安全に寄せやすくなります。
| 悪い例 | 改善例 |
|---|---|
| 顧客情報を取得する。必要なら全部返す | 顧客IDに一致する顧客の基本情報を取得する。機密項目は返さない |
| ファイルを読む。パスは何でもよい | 許可されたディレクトリ内の読み取り専用ファイルを取得する |
| APIを呼び出して処理する | 事前定義されたエンドポイントに対して読み取りリクエストを送る |
サニタイズで業務データが変わる可能性を見ていない
レスポンスサニタイズは有効な防御策ですが、業務データの一部が削除・編集される可能性があります。たとえば、セキュリティログ、メール解析、教育コンテンツ、脆弱性診断レポートなどは、攻撃文字列そのものを正当なデータとして扱います。
このような用途では、サニタイズ後のレスポンスをそのままエンドユーザーに出すのか、原文は別ストレージに保管するのか、監査時だけ参照できるようにするのかを決めておく必要があります。
Public Previewを本番前提で扱ってしまう
このパッケージはPublic Previewとして案内されています。Public Previewは試用や検証には適していますが、APIや既定値、動作が今後変わる可能性があります。重要業務へ適用する場合は、バージョン固定、ロールバック手順、ポリシーの互換性確認をセットで用意してください。(Microsoft for Developers)
また、公式のコンプライアンス注記では、Agent Governance Toolkitはセキュリティやプライバシープログラムを支援する技術的制御であり、それ自体が法令・規制への準拠を保証するものではないとされています。社内規程、GDPR、SOC 2などの要件に合わせた全体設計は別途必要です。(Microsoft for Developers)
導入前チェックリスト
本番展開前には、次の項目を確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| 対象MCPサーバーの棚卸し | どのサーバーがどのツールを公開しているか一覧化できている |
| パッケージ導入範囲 | 検証環境、ステージング、本番の適用順が決まっている |
| ポリシー設計 | default_action: denyを基本に、必要な許可ルールを定義している |
| 認証ID | エージェントIDをクレームなどから安定して解決できる |
| 起動時スキャン | 既存ツールがスキャンで止まらないか確認済み |
| サニタイズ影響 | 業務データの欠落や誤編集がないか確認済み |
| 監査ログ | 誰が、いつ、どのツールを呼び、どう判断されたか追跡できる |
| メトリクス | ブロック率、レート制限、評価遅延を監視できる |
| ロールバック | パッケージやポリシー変更を戻す手順がある |
| 運用ルール | ツール追加時にセキュリティレビューを必須にしている |
まず何から始めるべきか
今回のAgent Governance Toolkit MCP Extensions for .NETは、MCPサーバーを安全に運用するための「後付けの便利機能」というより、AIエージェント時代の.NETサーバーに必要な制御ポイントを標準化する動きと見るべきです。
最初にやるべきことは、いきなり本番へ入れることではありません。まず既存のMCPサーバーで公開しているツールを一覧化し、危険度の高いツールを分類します。そのうえで、検証環境にMicrosoft.AgentGovernance.Extensions.ModelContextProtocolを追加し、最小ポリシーで「許可されるツール」と「拒否されるツール」が意図どおり分かれるか確認しましょう。
特に、社内データ、顧客情報、ファイル操作、外部HTTP通信、メールやチケット更新を扱うMCPサーバーでは、早めに検証する価値があります。安全なMCP運用の基本は、AIエージェントを信用しすぎることではなく、ツール登録、実行、出力の各段階で明示的に判断できる状態を作ることです。
[3]: https://www.nuget.org/packages/Microsoft.AgentGovernance.Extensions.ModelContextProtocol “
NuGet Gallery
| Microsoft.AgentGovernance.Extensions.ModelContextProtocol 4.0.0
“
コメント