MCPサーバーは安全だ。その背後にある帳簿はそうではない。

先日、Unite.AIに掲載された記事で、Gil Feigは安全なMCPサーバーを構築するための6つのベストプラクティスを紹介しました。どれも妥当な内容であり、MCPサーバーを提供する人は誰でも従うべきものです。「各連携に、それぞれの細かな役割を割り当て、必要な権限だけに厳密に限定する」という彼の助言は、まさにそのとおりです。ただし、これは接続先のシステムにも細かな役割設定があることを前提としています。ここから、あまり語られることのない、より広い前提が浮かび上がります。つまり、サーバーの背後にあるシステムも、同じ水準でセキュリティを確保できるという前提です。

業務用ソフトウェアでは、それができないことも少なくありません。私は、会計・ERPシステム32種類に接続する連携レイヤーのエンジニアリングチームを率いており、その上にオプションとしてMCPサーバーを提供しています。こちら側では適切に認証され、権限が適切に限定され、ログも十分に記録されているエージェントが、エージェントの関与をまったく把握できないシステムに書き込みを行うケースを、私たちは日常的に目にしています。

この記事では、問題の後半部分を取り上げます。上流システムが実際に提供している機能、連携レイヤーから制御できること、そしてその制御が及ばなくなる境界についてです。

MCP仕様が引き継ぐところ

このMCPの認可仕様は、その境界を明確に定めている。MCPサーバーは、クライアントに対するOAuthリソースサーバーである。上流APIを呼び出す際には、別個のOAuthクライアントとして動作し、上流システムが発行する別個のトークンを使用する。クライアントのトークンをそのまま受け渡すことは、明示的に禁止されている。

それは正しい設計です。一方で、誰が何を実行できるか、またその操作がどのように記録されるかを含め、上流への呼び出しに関するすべてが、全面的に上流システムに依存することも意味します。上流システムが提供していない機能を、仕様で補うことはできません。

同じことは過剰なエージェンシーに関するOWASPのガイダンスにも当てはまる。エージェントの拡張機能が他のシステムで持つ権限を必要最小限に抑え、エージェントが代理するユーザーのコンテキストで操作を実行するよう推奨している。どちらも妥当な助言だ。どちらも、相手側のシステムが最小限の権限とユーザーコンテキストを表現する方法を備えていることを前提としている。

上流システムが実際に提供しているもの

私たちが接続している会計・ERPシステム32種類を、連携を担う側から見ると、次のような状況です。

3分の1にはOAuthがまったくない

32システムのうち21はOAuthを使用しています。残りの11は、APIキー、ユーザー名とパスワード、または2つ一組のトークンといった固定認証情報に依存しています。そうしたキーの中には、有効期限がないものもあります。広く使われているあるシステムでは、ユーザーが存在する限り、APIトークンの有効期間に上限はないと説明されています。

有効期間は長く、失効手段は乏しい

OAuthが役立つ度合いは、期待するほどではありません。あるプロバイダーは、リフレッシュトークンの有効期間を約20年に設定しています。つまり、その認証情報は、それを使うエージェントや、エージェントの構築に使われたフレームワークより長く存続し、場合によっては「許可」をクリックした本人より長く有効であり続けることを想定しているのです。別のシステムでは、アクセストークンにさえ有効期限がありません。

そして、認証情報が発行された後、それを無効にできるのは誰なのかという問題があります。そのための標準であるOAuthトークン失効（RFC 7009）は、2013年から存在しています。それにもかかわらず、約10システム中4システムでは、連携事業者が認証情報を失効させる技術的な手段を提供していません。APIキーを使うシステムはすべて、このグループに該当します。残された手段は、顧客に手作業でアクセス権を削除してもらうことだけです。

大まかな権限範囲、エージェントの識別情報なし

固定キーの大半は、作成したユーザーの権限をそのまま引き継ぎます。キーの権限を個々のエンドポイントに限定できるシステムは、ほんの一部です。多くのOAuthシステムには権限範囲の設定がありますが、「会計データの読み書き」といった大まかなものになりがちです。また、32システムのいずれにも、APIを通じて、同じ取引についてエージェントと代理対象の人物の両方を記録する方法は見つかりませんでした。外部エージェントは、接続を設定したユーザーとして表示されるか、汎用のシステムユーザーとして表示されます。示唆的なのは、ベンダーが自社製品にエージェントを組み込んでいる場合、MicrosoftがBusiness Centralで行っているように、エージェント専用のユーザーアカウントを用意していることです。これは、私が以下で推奨するのと同じ方法ですが、ベンダー独自のエージェントに限って適用されています。

連携レイヤーで強制できること

だからといって、何も対策できないわけではありません。エージェントと会計システムの間では、ほとんどすべてを制御できます。

• 自社のレイヤーへの接続に、エージェントごとの認証情報を使用する
• 独自の権限範囲を設定する。たとえば、請求書への読み取り専用アクセス
• エージェントによるすべての呼び出しと、代理対象の人物を記録する監査ログ
• 再試行するエージェントが同じ請求書を二重に計上しないようにする冪等性キー
• エージェントごとのレート制限
• 書き込みを行う前に承認を求める手順

これらはどれも、接続先システムが何をサポートしているかには左右されません。連携レイヤーに高機能なアクセス制御レイヤーを設けることは、今すぐ可能です。金融データにエージェントを少しでも関与させるなら、これを構築すべきです。

その先にある限界

できないのは、そのレイヤーをシステムの境界の先まで広げることだ。そこで、3つの問題が生じる。

操作主体の特定

会計システム内では、エージェントによる書き込みは、接続を承認したユーザー、または技術ユーザーによるものとして表示される。そのシステムを監査する人が目にするのは、そのユーザーによる記帳だ。それを人間とエージェントのどちらが行ったのかは判別できない。元帳上では、午前3時に400件の請求書を記帳するエージェントも、非常に勤勉な財務マネージャーも、まったく同じように見える。それを後から明らかにするには、インテグレーターのログが必要になるが、これは記録システムとは別の信頼の連鎖だ。フォレンジック調査や監査において、これは心もとない状態である。

ほとんどの組織も、この点で先行しているわけではない。Cloud Security Allianceの調査では、あらゆる環境においてエージェントの操作を人間またはシステムまで確実に追跡できると回答した回答者はわずか28%で、44%がエージェントに静的APIキーを使用している、または使用する予定だと答えた。

最小権限

エージェントが請求書を読み取るだけに制限することはできる。しかし、接続先のシステムにスコープがなければ、そのレイヤーの背後にある認証情報は依然として完全なアクセス権を持つ。それを入手した者はレイヤーを完全に迂回でき、レイヤーに設定したルールもすべて回避できる。

アクセスの取り消し

自社のエージェントなら、即座にアクセスを遮断できる。しかし、接続先システム自体の認証情報が侵害された場合は、それでは対処にならない。また、10システム中4システムにはアクセス取り消し用のエンドポイントがなく、その場合、キルスイッチの役割を果たすのは顧客へのメールだ。

現実的な答え：エージェント専用ユーザー

今日できる最も有効な対策は、地味なものだ。接続先のシステムにエージェント専用のユーザーを作成し、そのユーザーだけを通じてエージェントを接続する。

ユーザーを作成できるシステムならどれでも機能し、統合レイヤーでは実現できない次の3つの利点が得られる。

• 記録システム上で操作主体を特定できる。記帳内容には、6か月前に「接続」をクリックした財務マネージャーではなく、「買掛金エージェント」と表示される。
• APIがなくても、アクセスを取り消す手段がある。顧客はインターフェース上でそのユーザーを無効にできるため、アクセス取り消し用のエンドポイントがないシステムでも対応できる。
• 部分的に最小権限を実現できる。システムに何らかのロール管理機能があれば、エージェントユーザーのアクセスを、実際に必要なモジュールだけに制限できる場合が多い。

コストは現実に発生する。導入時に誰かが手作業でユーザーを作成しなければならず、ちょうど最も避けたいタイミングで手間が増える。システムの約半数はユーザーを追加するたびに料金がかかり、中小企業向けツールでは月数ユーロから、本格的なERPでは月100ユーロを超える場合もある。また、プランごとにユーザー数に上限を設けているシステムも複数あり、ユーザーを1人追加するために会社全体でより高額なプランへの変更が必要になることもある。そして、誰も管理していないサービスユーザーは、それ自体がリスクとなり、Unite.AIが以前取り上げた非人間IDの乱立の一因となる。他のアカウントと同じく、管理責任者と見直し日を定める必要がある。

また、スコープのないシステムにスコープを設けられるわけではない。それでも、監査担当者が実際に確認するシステム内で、操作主体の特定とアクセスの取り消しができるようになる。

構造的な答え：委任されたID

あるべき解決策は、すでに仕様として存在している。OAuth 2.0 トークン交換（RFC 8693）では、なりすましと委任が区別されている。委任の場合、エージェントは独自のIDを維持し、トークンには「act」クレームを通じて、人に代わって動作していることが記録される。

これを会計に適用すれば、次のようになる。

• 元帳に、このエージェントがこの人に代わって記帳したと記録される
• スコープはユーザーごとではなく、委任ごとに付与される
• 人のアカウントに手を加えずに、個別の委任を取り消せる

調べた限りでは、32システムのうち、これに類する機能をサポートするものは1つもない。したがって、今のところこれは選択肢ではなく、目指すべき方向にとどまる。つまり、これはインテグレーターの仕事ではなく、会計ソフトやERPの提供事業者への要望だ。エージェントはすでに元帳に書き込んでいるのだから、APIでもその事実を示せるようにすべきである。

エージェントが元帳にアクセスする前にすべきこと

エージェントを会計システムやERPに接続する場合は、次の簡単なチェックリストを確認しよう。

1. 接続先システムごとに認証情報の仕組みを確認する。OAuthなのか静的キーなのか、認証情報の有効期間はどのくらいか、スコープが設定されているか、そしてアクセスを取り消せるかを確認する。
2. いずれにせよ、自社のアクセス制御レイヤーを構築する。接続先がどのような機能を提供しているかにかかわらず、エージェントごとのID、スコープ、冪等性、承認の仕組みは自社側に用意する。
3. システムが許す場合は、エージェント専用のユーザーを使う。操作主体を特定できるようにするためのコストとして、導入時の作業とライセンス費用を受け入れる。
4. 自社の監査証跡は改ざんを検知できるように保つ。多くのシステムでは、それがエージェントの関与を示す唯一の記録となる。
5. 残存リスクを書き留める。 システムにスコープ設定も失効機能もない場合は、そのことを顧客にも自社のリスク登録簿にも明記する。

境界こそが要点だ

MCPサーバーを保護することは必要だが、それだけでは十分ではない。台帳に書き込むエージェントのセキュリティは、自社のレイヤーと記録の正本となるシステムとの境界で決まる。そして現状、その境界を定めているのはあなたではなく、システム側だ。

朗報なのは、このギャップが明確に定義されていることだ。標準はすでに存在する。欠けているのは、帳簿を管理するシステムでの標準への対応だ。