2026-08-01

MCPを本番で守るには、ゲートウェイだけでは足りない

InfoQの記事「Securing MCP in Production: Defense-in-Depth Beyond the Gateway」は、MCP（Model Context Protocol）を本番環境で使うときのセキュリティを、かなり現実的な目線で整理した記事です。読んでいて印象的なのは、「ゲートウェイを置けば安心」という甘い考えを、かなりはっきり否定しているところです。ここ、すごく大事だと思います。便利な入り口を作っただけでは、裏口や中身の暴れ方までは止められないからです。

この記事のキーポイント

MCPの防御は1か所ではなく、4つの層で考えるべきだと主張している
その4層は、safe execution、management infrastructure、outbound trust、semantic integrity
gatewayは認証・認可・監査には有効だが、すべてを守れるわけではない
ツールの定義が後から変わる「schema drift」や「rug-pull」も問題になる
外向き通信の制御と、トークンの権限を絞ることが重要
仕様の成熟を待つより、CIゲートや隔離された実行環境などで先に運用を固めるべきだとしている

MCPは「入口」だけの問題じゃない

この記事の出発点は、著者のチームがMCPをマルチエージェント基盤の統合レイヤーとして採用するにあたり、「自動化されたツール実行を、どうやって信頼できる形で本番運用するか」を考えたことでした。

その結果たどり着いた答えが、単純な1枚の防御壁ではなく、4つのコントロール層です。

safe execution
ツールを安全に実行する層。たとえばコマンド注入のような、入力を悪用して危ない処理を走らせる攻撃を防ぐ考え方です。
management infrastructure
MCPサーバーを監視する人間向けの管理基盤や、検査ツール、運用コンソールを守る層です。
outbound trust
MCPサーバーが外部へ出ていく通信を制御する層です。外向き通信は見落とされがちですが、ここがかなり危ない。
semantic integrity
これは少し分かりにくいですが、「承認した意味や中身が、あとから勝手に変わらないこと」です。ツール定義のズレや、承認後の仕様変更を防ぎます。

この4つを見て、なるほどなと思いました。セキュリティって、つい「ログインできるか」「権限があるか」だけで語られがちです。でも実際には、入ったあとに何をするか、運用中に何が変わるか、外に何を漏らすか、そこまで見ないと足りない。MCPは特に、ツール実行そのものが価値なので、入口の強化だけでは穴が残ります。

gatewayは大事。でも万能ではない

記事でも、gatewayの価値自体はしっかり認めています。gatewayは、認証・認可・監査・ポリシー評価をまとめる場所です。MCPトラフィックの前に置くのは、当然まず考えるべき構成です。

ただし、gatewayができるのはあくまで「入口の統制」です。次のような問題は、gateway単体では止めきれません。

ツールハンドラが、受け取った引数を安全でない形で扱うこと。
管理画面や検査用の仕組みがむき出しになっていること。
MCPサーバーが、広すぎる権限で外部APIにアクセスしてしまうこと。
承認済みのツール定義が、あとからこっそり変わること。

このあたり、現場の感覚ではかなり刺さる話だと思います。セキュリティ対策を1枚の壁として設計すると、壁の内側で起きることが雑になりやすいんですよね。著者はそこを、かなりはっきり「gatewayは一部でしかない」と言っているわけです。

何が起きているのか、最近のMCP周辺はけっこう荒い

記事は、2026年初頭にMCP関連のCVEが30件以上報告されたことを挙げています。さらに、Adversa AIの調査では500以上のMCPサーバーのうち、重要エンドポイントに認証がないものが38%、コマンド実行の脆弱性があるものが43%あったとしています。

かなり荒い数字です。正直、これは「まだ新しい技術だから仕方ない」で済ませるには、少し多い。しかも Microsoft が Azure MCP Server の SSRF 脆弱性、CVE-2026-26118 を修正した件も触れられています。SSRFは、サーバーに「外部への取り次ぎ」を悪用させて、意図しない内部情報に触れさせる攻撃です。この件では managed identity token が漏れたとされており、外向き通信の危険性がいかに厄介かを示しています。

ここで面白いのは、著者がこれらを「個別のバグの寄せ集め」ではなく、「境界ごとに似た失敗が起きている」と見ている点です。つまり、穴を1個ずつパッチで塞ぐ話ではなく、境界の設計そのものを見直すべきだという主張です。私はこの見方のほうがずっと本質的だと思います。攻撃はだいたい、決まりきった境界を狙ってきますから。

「最初に信頼できる地点はどこか」で考える

この記事で何度も出てくるのが、「earliest trustworthy enforcement point」、つまり「いちばん早く、信頼して制御できる場所はどこか」という考え方です。これ、実はかなり使える問いです。

コマンド注入なら、ツールハンドラとCIパイプライン。
管理系の露出なら、management plane と network boundary。
認証情報の漏えいなら、egress policy と token scope。
ツール定義の変化なら、登録時点の manifest の固定・差分確認・レビュー。

要するに、「あとで検知する」のでは遅い場面が多い、ということです。できるだけ手前で止める。しかも、その制御は役割ごとに場所が違う。ここを分けて考えるのが、この文章の肝です。

ツール定義は“承認した後”が危ない

個人的にいちばん興味深かったのは、tool manifest を registration の時点で pin する、という話です。manifest はツールの定義書みたいなものですが、これを承認後に勝手に変えられると、レビューした内容と実際の挙動がズレます。著者はこれを schema drift や rug-pull behavior と表現しています。

rug pull は本来、足元の絨毯を引き抜くように、後から前提をひっくり返す動きのことです。つまり「承認したときと中身が違うじゃないか」という話ですね。

ここでのポイントは、単純な allow / deny の二択ではなく、差分ベースのレビューを運用モデルにすることです。全部OKか全部NGか、ではなく、何が変わったのかを見て判断する。これは地味ですが、実運用ではかなり効く発想だと思います。AIやエージェント系の仕組みは、静的なルールよりも、じわじわ変わる差分のほうが怖いですから。

本番では、仕様の完成を待っていられない

記事のトーンはかなり現実的です。MCPの仕様やセキュリティモデルが成熟する前に、企業はもう本番運用を始めている。だから「仕様が追いつくのを待つ」のではなく、今ある仕様のままで守る方法を先に作れ、という考えです。

そのために挙げられているのが、CI gate、隔離された tooling、差分ベースの manifest review、behavioral baselines などです。behavioral baselines は、ざっくり言うと「普段の挙動の基準値」を持っておいて、そこから外れたら気づけるようにすることです。

この割り切りは、かなり好感が持てます。理想的な標準が整うまで待つと、現場は先に走り始めてしまう。AIやMCPの世界は特にその傾向が強いです。だからこそ、「今すぐ使う前提で、どう縛るか」を考える必要があるわけです。