MCPの信頼モデルが、汚染された1つのエージェントを別のエージェントへ到達させた

AIエージェント同士を接続する既定の手段となったこのプロトコルには信頼の問題があり、次のインシデントが起きる前にその輪郭を理解しておく価値がある。

Ars Technicaは10月5日、独立系研究者のSyed Anas Mohiuddin氏が「プロトコル・ピボッティング」と呼ぶ攻撃クラスを実証したと報じた。考え方は単純だ。ネットワーク内でエージェントはModel Context Protocol（MCP）を介して互いに通信する。ガードレールが最も弱くなるのは、あるエージェントが別のエージェントにタスクを引き渡す時点だ。2番目のエージェントは既定で1番目を信頼するからである。厳格な入力検証を欠く翻訳エージェントやデータ分析エージェントに悪意ある命令を仕込めば、そのエージェントは命令を下流に渡してしまう。受け取った側は従う。信頼できる同僚がなぜ嘘をつくのか。

Mohiuddin氏の概念実証は、Google、JPMorgan Chase、Weviate、Rapid7、フランスの省庁間デジタル総局、米国連邦機関という、互いに無関係な5つの組織にまたがった。これらの組織に共通するものは、エージェントを大量に使っていること以外にほとんどない。そこが要点だ。弱点は配管にあり、特定の製品にあるのではない。

2つのCVEとスコアの乖離

具体的なバグはありふれたものだ。それこそがこの話を居心地の悪いものにしている一因である。Rapid7のMCPサーバーにはCVE-2026-97228があり、同社は2026年9月に修正した。ただしこの脆弱性のスコアは10点満点中2.7だった。Googleの問題はより高く8で、googleapis/mcp-toolboxに関係していた。そのHTTPクライアントにはCheckRedirectポリシーと宛先IP検証が欠けており、細工されたパスパラメータによってリクエストを内部エンドポイントへリダイレクトできた。GoogleはIP許可リストとブロックリストを追加し、起動時に安全でないベースURLをツールボックスが拒否するようにした。

深刻度スコアの不一致自体が教訓である。2つの組織が同じプロトコルで同等の弱点を見つけながら、大きく異なる評価を下した。これは、エージェント間の信頼ギャップにどれほどのコストを課すべきかについて、業界の合意がまだ形成されていないことを示唆している。

誰もが「プロトコル・ピボッティング」を新しいカテゴリとして受け入れているわけではない。X41 D-Secの研究者Markus Vervier氏はArs Technicaに対し、これを間接プロンプトインジェクション、すなわちセキュリティチームが2年間追跡してきたのと同じ手法として読んでいると語った。その見方は妥当であり、実務上の問題をより鮮明にする。プロンプトインジェクションに対する防御の手引きは、入力が外部から来ることを前提としている。ここではそれは内部から、内部資格情報を身にまとってやって来る。

ギャップはアーキテクチャ上のものであり、パッチで埋まるものではない

セキュリティベンダーClawSecureによる別のレポートは、分析をさらに一層深く押し進めている。同社の研究者はLinear、Notion、Dropbox Dashをテストし、欠陥はどのベンダーの実装にあるのではなくMCP仕様にあると主張する。NotionとLinearでは、コンテンツが作成された瞬間に攻撃者制御のリンクを自動的に取得するMCPサーバーが見つかり、モデルは一切介在していなかった。ワークスペースへの書き込みアクセスを持つ者なら誰でも、巧みに言い回しを凝らしたプロンプトを必要とせず、それをリーク経路に変えられる。

彼らの数字は容赦ない。ゼロ幅Unicodeや同形異義文字を含む20種類の難読化手法のうち、17種類が往復を生き残った。5つのラボの14モデルにわたり、脅威を一貫してブロックしたモデルはなかった。最も優れた性能のClaude Opus 4.7でさえ、依然として約26.7%の確率で悪意ある指示に従った。

ClawSecureはセキュリティ製品を販売しており、このレポートは独立に再現されていない。そのためプラットフォーム層に関する主張は相応に慎重に扱うべきだ。とはいえ、根底にある状況は容易に確認できる。MCPは月間5億回を超えるSDKダウンロードと、1万6000近い公開サーバーを記録しており、ある集計ではこれらのサーバーのうちOAuthを使っているのはわずか8.5%にすぎない。導入が堅牢化を先走ったのである。

AWSは10月2日に公表したセキュリティ速報で独自の証拠を示した。同社のオープンソースLoomエージェントオーケストレーションプラットフォームの3つの欠陥により、未認証の管理者乗っ取り、OAuth2資格情報の漏えい、内部サービスへのアクセスが可能になる可能性があった。最も深刻なCVE-2026-103956では、IDプロバイダーが構成されていないデプロイにおいて、あらゆるネットワーククライアントがエージェント制御プレーンに到達できた。Loomバージョン1.6.1と1.7.0がこれらのギャップを塞ぐ。

なぜ既定の信頼前提が真の知見なのか

CVEを取り除いても、1つの設計上の選択が際立つ。エージェントは協調するように作られているため、互いを認証し、その後は有効な資格情報が有効なリクエストをも意味するかのように振る舞う。古典的なゼロトラストは逆を言う。境界の内側からであっても、すべてのリクエストをそれ自体の妥当性によって証明せよ、と。

Mohiuddin氏の攻撃は、この反転を悪用することで成立する。悪意ある命令がシステム間の認可境界を通過できるのは、コード上では境界を一度も越えないからにほかならない。それは1つの信頼されたファブリックの内部をエージェントからエージェントへと移動し、そのリクエストが妥当だったかを問う層がどこにも残らない。

チームが今週できること

即効性のある修正は地味だが、今すぐ利用できる。言語モデルから届いた命令は、どのエージェントが生成したものであれ、敵対的入力として扱う。厳格なリダイレクト処理を強制し、宛先IPを検証する。あるエージェントが別のエージェントに委任する前に、エージェント単位の認証を必須とし、委任をログに記録して、後から一連の受け渡しを再構築できるようにする。

より長期的には、標準化団体がプロトコル・ピボッティングを名前付きの脅威クラスとして成文化することが予想される。そうなればベンダーは、MCPの脇ではなくMCPの内部にゼロトラストチェックを実装するよう促されるだろう。監査人もそれに続き、エージェント間ガードレールに関する質問は、一世代前のファイアウォール規則と同じようにコンプライアンスレビューに現れ始めるだろう。

この話の居心地の悪い点は、エージェント同士が信頼し合うほど、この手口がよりうまく機能することだ。MCPを通じてツールを接続しようと急ぐすべての組織が、まさに今その信頼のファブリックを構築している。そしてそのほとんどは、チームの一員が嘘をついていると判明したときにどうするかの計画なしに築かれている。

なぜ今になって浮上したのか

根底にある技術のどれも新しいものではない。サーバーサイドリクエストフォージェリやインジェクションのバグは何年も前からOWASPのリストに載っている。変わったのは、それらが動く場所だ。エージェントはそれらの古いバグに新たな配送経路を与えた。エージェントは文書中の一文、データベース行の1フィールド、あるいは別のエージェントの出力の1行に対して喜んで行動するからだ。命令は攻撃者が入力する必要はない。モデルが読むどこかに最終的に存在すればよいだけである。

だからこそこの開示は、銀行、検索エンジン、セキュリティベンダー、政府の総局にまたがる。彼らはコードもベンダーも共有していなかった。共有していたのはアーキテクチャであり、そのアーキテクチャにはすべての参加者が信頼できるという前提が組み込まれている。MCPは約1年で新奇なアイデアから重要インフラになり、ダウンロード数は月間数億回単位で測られる。そして、通常ならこの成長に伴うはずのセキュリティレビューは、ほとんど行われていない。

この話には、うまく終わるバージョンもある。バグは修正されつつあり、プロトコルの管理者は反応が早く、攻撃には書き込みアクセスかネットワーク内部の足場のいずれかが必要で、それは意味のあるハードルだ。しかし本当に重要な修正は技術的というより文化的である。エージェントを導入するチームは、有効な内部資格情報をリクエストが正当である証拠とみなすのをやめ、まるで見知らぬ相手から来たかのように各リクエストを検証し始める必要がある。それはどんなパッチよりも出荷が難しい変更であり、次の一波のインシデントがそれを試すことになる。