OWASP MCP Top 10 — 手足の付け根が、一番狙われる

エージェントが外の世界に触れるとき、実際に手足になっているのはツールを呼ぶ層だ。MCP(Model Context Protocol)は、その層をつなぐ共通の取り決めとして広まった。つなぎ方が共通になれば、攻撃面も共通になる。OWASPがMCPに特化した一覧を作ったのは、そのためだ。ただし現時点ではbeta版で、番号も名前も動く可能性がある。

どこが攻撃面なのか#

MCPが受け持つのは三つの動きになる。

• ツールの発見 — どんな道具が使えるかを、モデルに知らせる
• 文脈の受け渡し — 何をしようとしているかを、道具側へ渡す
• 呼び出し — 実際に道具を動かし、結果を返す

この三つは、どれもモデルの入力と出力に直結している。ツールの説明文をモデルが読み、渡した文脈が外部のサーバーへ届き、返ってきた結果がモデルの次の判断材料になる。全部が境界をまたぐ。

つまりMCPの層は、信用の境界そのものだ。 ここを越えるものが全部、モデルの振る舞いに影響する。

十項目#

ツールの説明文が、命令になる#

Tool Poisoningが、この一覧で最も特徴的な項目だ。

MCPでは、ツールの名前と説明をサーバーが宣言し、モデルはその説明を読んでどれを使うか決める。つまり説明文はモデルへの入力だ。 ここに指示を仕込める。

利用者の画面には「請求書を検索します」としか出ないのに、説明文の中には別の指示が書いてある。人が見ている表示とモデルが読んでいる内容が食い違ったまま動くことになる。

厄介なのは、後から差し替えられる点だ。導入したときは無害でも、サーバー側で定義を書き換えれば振る舞いは変わる。一度確認したから安全、とはならない。

権限がじわじわ広がる#

Privilege Escalation via Scope Creepは、事故というより運用の帰結として起きる。

最初は読み取りだけで始める。機能を足すたびに必要な権限を一つずつ追加していくと、半年後には当初想定していなかった範囲まで届くようになる。どの追加も、その時点では妥当な判断だった。

Token Mismanagementも絡む。MCPサーバーは外部サービスの資格情報を預かることが多く、それがどのエージェントのどの依頼で使われたのかを追えない構成だと、範囲の議論そのものが成立しない。

把握していないサーバー#

Shadow MCP Serversは、技術的には単純な問題だ。誰かが試しに立てたサーバーが、そのまま残る。

MCPサーバーは立てるのが簡単で、そこが利点でもある。手元で動かして繋げば、その日から使える。だからこそ、組織として何が繋がっているかを把握する仕組みは後回しになりやすい。

一覧がなければ、点検もできない。 どのサーバーが、どの資格情報を持ち、どのデータに届くのか。この表が作れない状態は、それ自体がリスクとして数えられている。

記録が残らないという項目#

Lack of Audit and Telemetryが単独で一項目になっているのは、注目に値する。

普通、監査ログは攻撃の手口ではない。それでもここに入っているのは、記録がないと他の九項目を検出できないからだ。ツールが細工されても、権限が広がっても、気づく手段がない。

何を記録するかは決めておく必要がある。どのエージェントが、どのツールを、どの引数で呼び、何が返ったか。拒否された呼び出しも残す。拒否の記録こそ、範囲の設計が効いている証拠だ。

意図の流れを曲げる#

Intent Flow Subversionは名前が抽象的だが、指しているものは具体的だ。

利用者が頼んだことと、実際に実行されることのあいだにずれを作る。ツール呼び出しの引数を少し変える、呼ぶ順序を変える、返ってきた結果を書き換えて次の判断を誘導する。どれも小さい。

これが効くのは、人が最終結果しか見ていないからだ。途中でどのツールをどう呼んだかまで確かめる人は少ない。結果がもっともらしければ、そのまま通る。

対策は検知よりも可視化に寄る。呼び出しの列を人が追える形で残しておけば、あとから食い違いに気づける。気づけない設計では、曲げられたこと自体が分からない。

実際に事故は起きている#

抽象的な懸念ではなく、報告は積み上がっている。

2026年の初めの二か月だけで、MCPのサーバーやクライアント、周辺のツールを対象としたCVEが三十件以上登録され、そのうち四割強はシェルのコマンド実行に関わるものだったという集計がある。

Command Injection & Executionが一覧に入っているのは、この実態を反映している。MCPサーバーは外部のコマンドやAPIを叩く役目を負うので、引数の組み立てを誤れば、そのまま実行の穴になる。

新しい層ができると、その層の実装が一巡するまでは似た欠陥が出続ける。いまはその段階だ。

Agentic Top 10との関係#

内容は重なる。ただし粒度が違う。

OWASP Top 10 for Agentic Applicationsは、エージェントという系全体を見る。目標の乗っ取り、記憶の汚染、エージェント間の連鎖。設計の話が中心になる。

MCP Top 10は、そのうちツールをつなぐ一層だけを、実装の粒度で扱う。Tool MisuseやAgentic Supply Chainが、MCPという具体的な仕組みの上ではどう現れるかを書いている。

だから両方を見ることになる。構成はAgentic側で、接続はMCP側で確かめる。

使うときの注意#

beta版であることを前提にする。 現時点の版はv0.1で、番号や名前は今後変わりうる。社内基準に取り込むなら、追随の担当を決めておいたほうがいい。

サーバーを信用するかどうかを、明示的に決める。 公開されているMCPサーバーを繋ぐのは簡単だが、繋いだ時点でツール定義の書き換えを許すことになる。誰が運営していて、定義が変わったら気づけるのかまで見て決める。

渡す文脈を絞る。 Context Injection & Over-Sharingは、必要以上の情報を外部サーバーへ送る問題も含む。会話全体を渡す実装は、その分だけ漏れる面積が広い。

まとめ#

MCPが解いたのは接続の標準化で、それ自体は前進だ。同じ取り決めで繋がるほど、道具は増やしやすくなる。

ただし繋ぎ方が共通になれば、壊し方も使い回せる。この一覧が並べているのは、その裏側だ。

エージェントに手足を付けるとき、狙われるのは付け根だ。何を繋いだかを把握し、繋いだ先に何を渡すかを絞り、呼び出しの記録を残す。求められている条件は、結局そこに集まっている。