MCP はコネクタではありません — エージェント時代のガバナンス サーフェイスです

枠組みの問題: 「コネクタ」は実際に行っている決定を過小評価している

Anthropic が 2024 年 11 月に、AI システムをデータ ソースやビジネス ツールに接続するためのオープン スタンダードとして Model Context Protocol (MCP) を導入したとき、業界は新しい統合仕様で通常行うことを実行しました。つまり、MCP を配管の下にファイルしました。アダプター、トランスポート、すべてのモデルとすべてのツールに一度限りの接着剤を作成するのをやめるきちんとした方法。すべて真実ですが、CIO、CTO、または CISO の椅子に座っている場合は、すべてが的外れです。

企業にとって重要な再フレームは次のとおりです。エージェントが顧客データを読み取ったり、記録システムに書き込んだりするツールを呼び出すことができるようになった瞬間、名前を付けたかどうかに関係なく、新しいコントロール ポイントが作成されたことになります。 MCP は、その制御点を明示できる場所です。単にエージェントがツールに到達する方法だけではありません。ここで、誰が電話をかけているか、誰の ID に基づいて、どのツールが表示されるか、各通話がどのように記録されるか、各通話に許可される料金はいくらになるかを決定します。これらはガバナンスの問題であり、接続性の問題ではありません。

MCP を接続機能として扱うと、カバレッジ、統合数、最初の通話までの時間など、間違ったものを最適化することになります。これをガバナンス サーフェスとして扱うと、エージェントを大規模に展開しても安全かどうかを実際に決定するもの、つまりポリシーが一度適用され、どこでも監視される単一の標準化された監査可能なインターフェイスを最適化できます。

「多数のカスタム統合」がガバナンスを N 回静かに再構築する理由

ほとんどの企業は、白紙の状態でエージェント時代を迎えるわけではありません。彼らは、ポイント統合のポートフォリオとともに到着します。オーダーメイドのコネクタがここにあり、サービス アカウントがそこにあり、チームが 2 四半期前に構築した、誰も完全には覚えていない API ラッパーです。これらはいずれも地元の合理的な決定でした。それぞれが独自のイディオムで ID、認可、ロギング、レート/コスト制御を再実装するか、それらの一部を完全にスキップするため、これらは集合的にガバナンスの問題となります。

予想通り、3 つの故障モードが発生します。まず、ID のドリフトです。1 つの統合は共有サービス アカウントとして実行され、別の統合はエンド ユーザーになりすまし、3 つ目の統合では、その後チームを変更した人によって作成された長期有効なキーが使用されます。つまり、「誰がこれを行ったのか?」 N 個の異なる答えがありますが、完全なものはありません。 2 つ目は、承認フラグメントです。ツールが実行できるルールは、N 個のレビュー リズムを持つ N 個のコードベースに存在するためです。ある場所で締めたコントロールが、別の場所では静かに緩んだままになります。 3 つ目は、財務と監査が最初に感じていることですが、2 つの統合パスを通じて同じ質問に答えると 2 つの答えが返されるため、数値が変動します。利害関係者が数字を信頼しなくなると、エージェント プログラムは重要でなくなります。

標準化された代替案は魔法でも無料でもありませんが、作品の形を変えます。 N 個の統合を N 回管理する代わりに、1 つのインターフェイスを 1 回管理し、それを介してツールを意図的に公開します。アイデンティティは 1 か所で確立されます。承認はインターフェイスのプロパティであり、各コネクタの習慣ではありません。ログは均一であるため、監査証跡は実際には証跡です。また、数値を計算するためのパスが 1 つあるため、数値の変動が止まります。

ID とテナントのコンテキスト: ツールではなく、玄関で決定します

ガバナンス サーフェスが答えなければならない最初の質問は、呼び出しが誰の権限を持っているかということです。マルチテナント SaaS コンテキストでは、これは微妙です。これは、呼び出し元の ID (どのエージェントがどのユーザーまたはサービスを担当しているか) と、呼び出しが行われるテナント コンテキスト (どの顧客のデータと資格が適用されるか) という 2 つの異なる事実が関係しているためです。これらを混同すると、古典的な混乱した代理のバグが発生します。つまり、ある目的のために正当に認証されたエージェントが、決して継承すべきではない権限で動作するように誘導されるということです。

採用すべき規律は、呼び出し元のセッションが提示する情報ではなく、サーバー側のテナントバインディングからテナントコンテキストを導出することです。当社の実装では、機能アクセスを制御する顧客層はテナントコンテキストから解決され、呼び出し元のセッションから読み戻されることはありません。これは、呼び出し元がよりリッチなセッションを提示することで、自身の影響範囲を拡大することを防ぐためです。IDは誰が要求しているかを示し、テナントコンテキストは、回答を計算する際に考慮しなければならないデータと権限の範囲を示します。どちらも、ツールが実行される前に、呼び出し元で決定されます。

ここは、エージェントがユーザーではないことを伝える場所でもあります。コンソールの中の人間には目があって、迷いがあり、マネージャーがいる。エージェントにはループがあります。付与する ID とコンテキストは、プロビジョニングしたどの人物よりも迅速かつ文字通りに動作できることを反映する必要があります。

ツールごとの承認: 公開はデフォルトではなく決定です

初期のエージェント展開における最も一般的かつ最も危険なデフォルトは、全か無かの暴露です。つまり、エージェントをプラットフォームに接続し、基礎となる資格情報が到達できるすべてのものにエージェントが到達できるようにします。デモでは便利ですが、運用環境では防御できません。ガバナンス サーフェスは、各ツールの可視性と許可を、意図的でレビュー可能な決定として扱います。

具体的には、認可は単一のオン/オフ スイッチではなく多軸である必要があります。スコープと層の 3 軸モデルを使用し、前述のように層はテナント コンテキストから取得されます。これにより、特定のツールは、呼び出し元のスコープで許可され、テナントの層に含まれる場合にのみ公開されます。 2 番目の軸のポイントは、能力は誰が要求しているかだけでなく、どの顧客の資格が有効であるかにも依存するということです。これにより、公開面が正直に保たれます。新しいツールをカタログに追加しても、すべてのテナントのすべてのエージェントがそのツールに黙ってアクセスできるようになるわけではありません。

建築家に与えるメンタルモデルは配電盤ではなくカタログです。カタログ上のすべてのツールは、誰がどのようなテナント条件でそれを呼び出すことができるかを決定することによってその場所を獲得しました。現在エージェントが必要としているツールがカタログに載っていないだけです。 「全か無か」は偽りの経済です。 「ツールごとに意図的に」という姿勢が、実際の監査にさらされても生き残る唯一の姿勢です。

フェールクローズ書き込み: 読み取りと動作の間の非対称性

読み取りと書き込みは道徳的に同等ではないため、ガバナンス面で同等であるかのように見せるべきではありません。読み取りエラーが発生すると、古いデータまたは空のデータが返されます。回復可能ですが、多くの場合は表示されません。エラーのある書き込みは、記録システムを変更したり、実際の顧客にメッセージを送信したり、お金を移動させたりします。間違った場合の代償は非対称であるため、デフォルトの姿勢も非対称でなければなりません。

私たちが守るルールは、書き込みツールはフェイルクローズするということです。承認があいまいな場合、テナント コンテキストを明確に解決できない場合、ガードを評価できない場合、書き込みは行われません。これは、多くの統合が継承する利便性重視のデフォルトとは逆で、未評価のチェックが「許可」に解決されるため、スムーズなパスが維持されます。フェールオープンとは、エージェントが誰も承認したことのない条件で書き込みを行っていたことを数週間後に発見する方法です。状態を変化させたり、顧客に触れたりするものについては、安全なデフォルトは拒否であり、それが許可されていることを証明するのは立証責任です。

ここには文化的な側面があります。エンジニアは物事が機能するように最適化します。セキュリティは、最悪の事態に陥らないように最適化します。ガバナンス サーフェスとは、問題のない書き込みを時折拒否するという犠牲を払ってでも、最悪の方法 (サイレントに実行される不正な書き込み) は受け入れられないことをコード化する場所です。

予算台帳とキルスイッチ: 第一級のコントロールとしてコストを管理する

エージェントは、従来の統合ではほとんど発生しなかった、自律的な支出というカテゴリのリスクを導入します。ツールを呼び出すループは、バグや敵対的なプロンプトを通じて、誰もが意図したよりもはるかに多くのツールを呼び出す可能性があり、API 予算を消費したり、ダウンストリーム料金をトリガーしたり、顧客が殺到したりする可能性があります。したがって、コスト管理はガバナンス面に属しており、損害が発生したときに発生する請求アラートとして後から追加されるものではありません。

私たちが実行しているメカニズムは、実行ごと、1 日ごと、およびローリング 30 日の制限を備えた支出前に評価される予算台帳と、実行前にチェックされるキルスイッチです。順序に注意してください。予算とキルスイッチは支出前に評価され、支出後に調整されません。浪費したことを知らせるアラートは事後分析です。予算超過の要求を拒否する台帳はコントロールです。故障モードにはさまざまな形があるため、3 つの時間軸が重要になります。暴走ループは実行あたりの上限を超え、スケジュールの設定ミスは 1 日あたりの上限を超え、スロークリープは 30 日のウィンドウに対してのみ現れます。

キルスイッチには、設計の中で独自のラインが必要です。これは、何が起こっているのかまだ理解できず、すぐに活動を停止する必要があるときに到達するコントロールです。実行前に評価されるため、クリーンアップ ツールではなくサーキット ブレーカーです。すべてのエージェント プログラムは、「どうすればそれを止められるか?」という 1 つの質問に即座に答えることができる必要があります。答えが 3 つのチームにページングを行い、手動でキーを無効にすることである場合、キルスイッチはありません。希望はあります。

監査と編集: 範囲が定められ、期限が設定され、観察可能です

遵守できないガバナンスはガバナンスではありません。それは意図です。表面の最後の層は、その上のすべてを事後証明可能にする層です。エージェント キーは、実際に必要なツールに範囲を限定し、資格情報の影響範囲が無期限に残るのではなく、スケジュールに従ってゼロに縮小されるように時間制限を設ける必要があります。永久に何でもできる鍵は、事件調査の残骸から発見された最も一般的なアーティファクトです。

同様に、監査証跡自体も、記録されるデータを尊重する必要があります。呼び出しごとの編集を適用することで、コントロールが保護するために存在する非常に機密性の高いデータの二次コピーになることなく、何が起こったか (どのツール、どの ID およびテナントのコンテキストで、どのような結果が得られたか) がログに記録されます。平文の顧客記録を静かに蓄積する監査ログは制御ではありません。それはフレンドリーな名前の新しい責任です。

これらのプロパティ (スコープ付きキー、時間制限、呼び出しごとの編集、統一監査) を組み合わせることで、CISO はインシデント後に実際に尋ねられる質問に答えることができます。つまり、この資格情報で何ができるのか、どのくらいの期間実行できるのか、実際に何をしたのか、証明で漏れることなく証明できるのかなどです。

継続的なリスクと結びつけ、何が残っているかについて正直である

これらはいずれも 1 回限りのセットアップではありません。 NIST AI リスク管理フレームワーク (AI RMF 1.0) は、AI リスクの管理は継続的なプロセスであり、完成させて棚上げするチェックリストではないことを明示しています。ガバナンス サーフェスは、継続的なプロセスに単一の行動場所を提供するため、まさに価値があります。新しいリスクが発生した場合、N 個の統合にわたる変更を追うのではなく、1 つのインターフェイスで承認、予算、エクスポージャ、または監査を調整できます。標準化によって、継続的なガバナンスは野望的なものではなく、実行可能なものになります。これは、思慮深い露出決定が 2 回効果をもたらす理由でもあります。1 回目はそれを行うとき、もう 1 回目は再検討する必要があるときです。

あなたのボードもそうなるので、残留リスクについては正直に考えてください。ガバナンス サーフェスは攻撃対象領域を狭め、アクティビティを監査可能にします。それはエージェントを無謬にするものではありません。迅速な注入は依然として、合法的に許可されたエージェントを合法的に見える悪用に誘導しようとする可能性があります。意図的に公開されたツールでも、その権限の範囲内で悪用される可能性があります。予算にはコストの制限がありますが、判断の制限はありません。 Deloitte の「企業における AI の現状」調査では、AI の野心とそれを管理する運用の成熟度の間にギャップがあることが繰り返し示されており、そのギャップこそがこれらの残留リスクが存在する場所です。正しい対応は、ギャップが埋まったと主張するのではなく、ギャップを小さくし、観察可能にし、継続的に管理することです。

私たちはこの信念に基づいてプラットフォームを構築しました。 SocialHub.AI は、HTTP ストリーミング可能なトランスポートを使用して MCP 上でセマンティック層ツールを公開し、Claude、GitHub Copilot、Microsoft 365 Copilot などのエージェントからアクセス可能です。ここで説明する制御は、コネクタ間で散在するのではなくインターフェイスで適用されます。テナント コンテキストからの層による 3 軸認証、フェールクローズ書き込み、実行ごと、日ごと、30 日ごとの予算台帳。実行前のキルスイッチ、および通話ごとの編集と監査を備えたスコープ付きの時間制限付きエージェント キー。これは、McDonald's China メンバーの GMV 寄与率を約 5% から 85% に拡大することに私たちが貢献したロイヤルティの取り組みを支えるのと同じガバナンス規律です。その規模の成果は、データへのインターフェースが構築によって信頼できる場合にのみ存続します。

エージェントが記録システムにどのようにアクセスするかを決定している場合、チームに課すべき問題は「どのコネクタか」ではなく、「ID、承認、ロギング、コストがどこで決定されるのか、そしてそれは 1 か所なのか、それとも N か」ということです。ガバナンス優先の MCP サーフェスが実際にどのようなものかを確認したい場合は、デモを予約するか、/platform/ai-frontier でアプローチの詳細をお読みください。