エージェントが外の世界に触れるとき、実際に手足になっているのはツールを呼ぶ層です。MCP(Model Context Protocol)は、その層をつなぐ共通の取り決めとして広まりました。つなぎ方が共通になれば、攻撃面も共通になります。OWASPがMCPに特化した一覧を作ったのは、そのためです。ただし現時点ではbeta版で、番号も名前も動く可能性があります。
どこが攻撃面なのか
MCPが受け持つのは三つの動きです。
- ツールの発見：どんな道具が使えるかを、モデルに知らせる
- 文脈の受け渡し：何をしようとしているかを、道具側へ渡す
- 呼び出し：実際に道具を動かし、結果を返す
この三つは、どれもモデルの入力と出力に直結しています。ツールの説明文をモデルが読み、渡した文脈が外部のサーバーへ届き、返ってきた結果がモデルの次の判断材料になります。全部が境界をまたぎます。
MCPの層は、信用の境界そのものです。 ここを越えるものが全部、モデルの振る舞いに影響します。
十項目
| ID | 項目 | 中身 |
|---|---|---|
| MCP01 | Token Mismanagement & Secret Exposure | 資格情報の扱いと漏洩 |
| MCP02 | Privilege Escalation via Scope Creep | 権限が少しずつ広がる |
| MCP03 | Tool Poisoning | ツールの定義そのものに細工する |
| MCP04 | Software Supply Chain Attacks | 依存と配布経路の汚染 |
| MCP05 | Command Injection & Execution | サーバー側でのコマンド実行 |
| MCP06 | Intent Flow Subversion | 意図の流れを曲げる |
| MCP07 | Insufficient Authentication & Authorization | 認証と認可が足りない |
| MCP08 | Lack of Audit and Telemetry | 記録が残らない |
| MCP09 | Shadow MCP Servers | 把握されていないサーバー |
| MCP10 | Context Injection & Over-Sharing | 文脈の注入と、渡しすぎ |
ツールの説明文が、命令になります
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が解いたのは接続の標準化で、それ自体は前進です。同じ取り決めで繋がるほど、道具は増やしやすくなります。
ただし繋ぎ方が共通になれば、壊し方も使い回せます。この一覧が並べているのは、その裏側です。
エージェントに手足を付けるとき、狙われるのは付け根です。何を繋いだかを把握し、繋いだ先に何を渡すかを絞り、呼び出しの記録を残す。求められている条件は、結局そこに集まります。自社で確かめるなら、まず繋がっているMCPサーバーの一覧が出せるかどうかから始めてください。出せない状態では、この十項目のどれについても現状が分かりません。
