Agent Governance Toolkit MCP Extensions Make the Secure Path Much Easier in .NET

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

エージェントツールにおける最大の問題のひとつは、ハッピーパスが通常、安全でないパスであることだ。

MCP サーバーを立ち上げることはできる。ツールを素早く公開できる。デモを動かすこともできる。

そして、その直後に厄介な質問がやってくる:

誰が何を呼び出せるのか？
ツールのメタデータが悪意のあるものや誤解を招くものだったらどうなるのか？
安全でない出力がそのままモデルに流れ込んだらどうなるのか？
このうちどこまでがポリシーで、どこまでが単なる慣習なのか？

だからこそ、新しい Agent Governance Toolkit MCP Extensions for .NET が重要なのである。

エージェントエコシステムのすべてのセキュリティ問題を解決するわけではないが、非常に重要なことを果たしている。デフォルトの .NET ビルダーフローをはるかに堅牢にしやすくしているのだ。

アナウンスメントで最も重要な一文

元記事によれば、このパッケージは IMcpServerBuilder に「ワンコールガバナンス」を追加する。

それが私が注目すべき正確なフレーズである。

なぜなら、ほとんどのチームがエージェントガバナンスの構築に失敗するのは、認識不足のせいではないからだ。安全なパスがより多くの作業、より多くの配線、より多くのカスタムコードを必要とし、クリーンアップを後回しにする機会が増えるから失敗するのである。

そして「後回し」こそがリスクの温床である。

なぜこれが良い .NET ストーリーなのか

私が気に入っているのは、このパッケージが既存のビルダーモデルにどれほど自然に適合するかという点だ。

チームに以下を強制する代わりに:

サイドカー
別のプロキシ
カスタムラッパーアーキテクチャ
奇妙な代替 SDK

このパッケージは公式の C# MCP ビルダーフローを直接拡張する。

これは非常に重要である。

セキュリティにアーキテクチャ上のアクロバットが必要なら、採用は即座に低下する。セキュリティがサーバー設定の通常の一部に見えれば、採用ははるかに現実的になる。

脅威モデルはもはや理論上のものではない

チームが過小評価すべきでないのは、MCP 関連のリスクが本番システムでいかに急速に現実のものになるかという点だ。

元記事は次のような問いを提起している:

「登録されたすべてのツールが、すべてのエージェントから呼び出し可能であるべきか？」
「ツールの説明にプロンプトインジェクション形式の指示が含まれていたらどうなるか？」

これらはまさに正しい問いである。

なぜなら、ツールがエージェントの実行面となった時点で、システムは単にテキストを生成しているのではない。セキュリティ、信頼性、ガバナンスに影響を及ぼす意思決定を行っているのである。

それはハードルを変える。

このパッケージが正しくやっていること

この拡張の最も優れた設計判断は、複数のセキュリティレイヤーをひとつの一貫したフローにバンドルしている点である:

安全でないツール定義の起動時スキャン
実行時ポリシー適用
アイデンティティ認識型ガバナンス
クライアントやモデルにコンテンツが戻る前のレスポンスサニタイゼーション
監査およびメトリクスフック

これこそ正しい形である。

ひとつの巨大な「セキュリティモード」ではなく、ライフサイクルのさまざまな障害点をカバーする一連の具体的な制御である。

起動時スキャンは多くのチームが思う以上に重要

特に気に入っているのは、安全でないツールメタデータがデフォルトで起動を失敗させられる点だ。

これは強い意見であり、正しい判断だと思う。

毒された、または疑わしいツール定義をブロックできるのは早ければ早いほど良い。実行時まで待っていては、あるクラスの問題にはすでに手遅れである。

レスポンスサニタイゼーションも非常に実用的なレイヤー

この発表でもうひとつ過小評価されているのが、出力サニタイゼーションへの焦点である。

多くのチームは危険な入力を考える。

しかし、ツールから戻ってきた危険な出力がそのままエージェントループに渡されることについて、十分に注意を払うチームは少ない。

それは簡単に痛い目にあうポイントである。

それでも注意すべき点

私はこのパッケージを高く評価しているが、ひとつ注意すべき点がある。ガバナンスツールは、チームが実際に意味のあるポリシーを定義し維持する場合にのみ機能する。

この拡張はメカニズムの配線を容易にする。それは素晴らしい。

しかし、チームは依然としてより困難な組織的作業を行う必要がある:

どのツールを許可するか
どのエージェントまたは ID がそれらを呼び出せるか
自分たちの環境で「デフォルトで拒否」が実際に何を意味するか
偽陽性と例外をどのように処理するか

したがって、このパッケージを強力な適用レイヤーとして扱うべきであり、アーキテクチャ上の判断の代替として扱うべきではない。

私の見解

これは、ここしばらくで見た中で最も明確な セキュアバイデフォルト の .NET エージェントアナウンスメントのひとつである。

魔法を約束するからではなく、チームが一貫性なく実装しがちだったセキュリティ作業のカテゴリーに対して、ビルダーパイプライン内によりクリーンで自然な居場所を与えるからだ。

それが私がこのエコシステムに求める種類のパッケージである。

これは広範なガバナンスの議論を終わらせるものではない。より実用的なことを行う: ガバナンスが誰か他の人の後回しのクリーンアップタスクであるふりをすることを、はるかに難しくする。

そしてそれが真の進歩である。

元記事: Announcing Agent Governance Toolkit MCP Extensions for .NET

Agent Governance Toolkit | The .NET Blog