
AIエージェントのサプライチェーン攻撃とは、エージェントが実行時に取り込む MCP サーバー・Skill・プラグインなどの外部コンポーネント配信経路を侵害し、業務 AI 実行環境に任意コードや悪意ある指示を注入する攻撃である。
従来のサプライチェーン攻撃が「ライブラリ」「コンテナイメージ」を狙ったのに対し、AIエージェント時代の攻撃面は「実行時に動的にロードする MCP / Skill」へと広がった。Anthropic 自身が認める設計意図と、公開 MCP サーバーの大量露出という現実が、この問題を加速させている。
本ガイドは情シス・SRE・セキュリティ担当者を対象に、(1) 信頼ソースの allowlist 化、(2) 最小権限とサンドボックス、(3) 入出力ガードと監査ログの 3 層防御 を 3 ステップで設計する手順を解説する。読み終えたとき、自社のエージェント運用環境で「最初に何を絞り、何を監視するか」を即決できる状態を目指す。
従来のサプライチェーン攻撃が「ライブラリ・コンテナ」を狙ったのに対し、AI エージェント時代の攻撃面は実行時に動的にロードされる MCP サーバー・Skill・プラグインへと拡大した。これらは外部の指示を受け取って業務 PC 上でコマンド実行・ファイル操作・API 呼び出しを行うため、被害が即座に企業の業務システムへ波及する。
このセクションでは、攻撃面が拡大した構造的な理由と、表面化した実例を整理する。
MCP(Model Context Protocol) は、エージェントが外部のツール・データソース・コードを呼び出すための共通プロトコルだ。基礎は AIエージェントプロトコル(MCP・A2A)入門 で扱った。Skill はこれを拡張し、再利用可能なワークフローを「スキル」として配布する仕組みとして登場している。
実行モデルは 3 つのレイヤで成り立つ。
| レイヤ | 役割 | リスクの所在 |
|---|---|---|
| エージェント本体 | 推論と意思決定 | プロンプトインジェクション |
| MCP クライアント | プロトコル通信を担う | 通信改ざん・認証バイパス |
| MCP サーバー / Skill | 実コマンドを実行 | 任意コード実行・データ流出 |
特に下層の MCP サーバーは、設計上「クライアントから送られたリクエストに応じて OS コマンドを実行できる」性質を持つ。この実行能力こそが、サプライチェーン攻撃の入口となる。
AI エージェントのサプライチェーンに関する事案が、複数の公開ソースから報告されている。代表例を 3 件挙げる。
防御側の準備状況についても、Cisco「State of AI Security 2026」では、エージェント型 AI を本番展開できる準備が整っている組織は 約 29% にとどまるという結果が報告された。攻撃面は広がりつつ、防御側の整備は追いついていない。

最初の防御線は「どの MCP サーバー・Skill を実行できるか」を許可リスト(allowlist)で明示することだ。デフォルト全許可は実質ノーガードであり、設計上の脆弱性が表面化している以上、企業側で経路の信頼を限定する以外に出発点はない。
検証すべき配信経路は (1) 公開ネットワーク上の MCP サーバー、(2) マーケットプレイスで配布される Skill、(3) 社内開発の MCP / Skill の 3 種に分けられる。それぞれリスクの性質が異なる。
公開 MCP サーバーを利用する際、最低限以下を確認する。
無認証で誰でも叩ける公開 MCP は、業務利用には適さない。最初は「社内ネットワーク内に閉じた MCP サーバー」または「認証付きの提供者直結 MCP」のみに絞り、外部公開 MCP は段階的に評価して取り込むのが現実的だ。
Skill や MCP パッケージは「コンテナイメージや npm パッケージと同じく改ざんされうる」前提で扱う。
理想は「マーケットプレイスからの自動更新を許可せず、社内のレビューを通過したバージョンのみを配布する内部ミラー」を持つことだ。社内ミラーは過剰投資に見えるが、悪意あるスキルが実際に流通している観測値を踏まえれば、サプライチェーンの境界を企業側に引き戻すコストとして妥当な選択になる。

MCP / Skill が呼び出すコマンドや API の権限を最小化し、エージェント実行を OS / ネットワーク両面でサンドボックス化することで、悪意あるツールが混入しても被害を局所化できる。「by design」の脆弱性が許す挙動を前提に、被害範囲を物理的に絞るのが Step 2 の役割だ。
権限分離は OS レイヤと通信レイヤの両方で設計する。
エージェント本体・MCP クライアント・MCP サーバーは、それぞれ別の実行コンテキストに分離するのが基本だ。
| 分離レイヤ | 推奨実装 | 防げるシナリオ |
|---|---|---|
| ユーザー | 専用 OS アカウントで実行 | 開発者個人ファイルへのアクセス |
| コンテナ | サーバーごとに別コンテナ | コンテナ間の横移動 |
| ネットワーク | 必要なエンドポイントのみ許可 | 任意の外部 API 叩き |
| ファイルシステム | 読み取り専用マウント+作業領域のみ書き込み可 | 業務ファイルの破壊・流出 |
「とりあえず docker で動かしている」という状態は、実は分離が不十分なケースが多い。コンテナ内で root 実行、ホストの Docker socket をマウント、/var/run を共有といった構成は、サンドボックスとは呼べない。Skill が実行できるコマンド集合を allowlist された実行可能ファイルだけに絞り、それ以外のシステムコールはブロックする方針が安全だ。
MCP サーバーのおよそ 4 割近くが SSRF 脆弱性を持つ可能性が指摘されている(BlueRock Security による分析)。これは MCP / Skill が「内部ネットワーク・クラウドメタデータエンドポイントへ任意の HTTP リクエストを発行できてしまう」現象だ。
防御は egress(外向き通信)の allowlist 化が中心となる。
169.254.169.254 への通信を全面ブロック(IMDSv2 強制でも追加防御として)10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 等)への通信を、業務上必要な接続先以外ブロックegress 制御を入れていない MCP / Skill 実行環境は、AWS の IAM ロールから一時クレデンシャルを盗まれるリスクと隣接している。クラウド上で運用するなら、egress フィルタは「あれば良い」ではなく「ない時点でリスクが顕在化している」と扱うべきだ。

MCP / Skill の入力プロンプトと出力アクションを記録し、異常パターンを検出することで、攻撃の早期発見と PDPA 等のコンプライアンス要件を同時に満たせる。Step 1・2 が「侵入を絞る」防御だとすれば、Step 3 は「侵入された後で検知し、説明責任を果たす」ためのレイヤだ。
入出力ガードは プロンプトインジェクション対策 と AI ガードレール実装 で議論したパターンの拡張として捉えると整理しやすい。
MCP / Skill の入力経路は 3 つある。(1) ユーザーからの直接プロンプト、(2) RAG・データベース・ファイルから取り込まれた文字列、(3) 別の MCP サーバーや別エージェントからの応答。
特に注意すべきは (2) と (3) で、ユーザーが意図せずデータ経由で攻撃指示を注入される「間接プロンプトインジェクション」だ。
| 検査項目 | 実装パターン |
|---|---|
| 制御文字・ゼロ幅文字の除去 | 取り込み時に正規化 |
| 既知の脱獄パターン検出 | プロンプトベースのフィルタ+LLM-as-a-Judge |
| ツール呼び出しの確認 | 高リスク操作(削除・送金・外部送信)は HITL で人間承認を挟む |
| メタデータ汚染 | 出典・タイムスタンプを別フィールドに分離 |
「全部のリクエストを LLM で精査する」のは現実的でないことが多いため、書き込み・削除・外部通信を伴うツール呼び出しのみ重い検査を入れる方針が、コストとリスクのバランスとして取りやすい。
MCP / Skill の呼び出しは「いつ・誰が・どのエージェントが・どのツールを・どの引数で・何を返したか」を構造化ログとして残すのが基本だ。最小限ログに含めたい項目を整理する。
異常検知のシグナルとしては、(a) 短時間での大量ツール呼び出し、(b) 普段使わないドメインへの egress、(c) 大量のファイル読み出し、(d) 個人データを含む応答の外部送信、が定番だ。これらは既存の SIEM / SOC ツールに組み込めるシンプルなルールから始めると、初期投資を抑えながら可視化できる。
監査ログは攻撃検知だけでなく、PDPA や監査対応で「個人データへのアクセス履歴を提示できるか」を担保する 役割も担う。AES-256 等の 暗号化実装 と組み合わせて、保存時の機密性とトレーサビリティを両立させたい。

MCP / Skill の防御は「デフォルトの設定で十分」「社内ネットワークなら安全」という前提が崩れているのが現実だ。最も多い失敗は構造的な過信から来る。
ここでは観測される 2 つの典型例を取り上げる。
最も頻発する誤解は「ローカルマシンで動かしているから外部に出ない」という発想だ。Anthropic の MCP リファレンス実装の脆弱性は、ローカル実行であってもユーザーマシン上で任意コマンドを実行できる点が核心だった。具体的に何が起きるかを整理する。
「ローカル」は「企業の境界の外側」ではなく、業務システムへ接続できる別の高権限ホストとして扱うのが正しい。社内ガイドラインでは、MCP / Skill を動かす PC が本番 DB への直接アクセスを持たない構成にし、必要なら踏み台 + 短命クレデンシャル経由に切り替えると、被害範囲が大きく縮む。
もう 1 つよくあるのが、開発時の便利設定が本番に流れ込むパターンだ。
MCP_ALLOW_ALL=true が本番にも設定されるこれらは古典的な構成ミスだが、AI エージェント時代は影響範囲が大きい。開発・ステージング・本番で MCP / Skill 構成を別ファイルに分離し、CI/CD パイプラインで「本番に許可されない MCP 一覧」をビルド時に拒否する仕組みが効く。Infrastructure as Code で構成を管理し、レビュー対象に含めると検出しやすくなる。

MCP / Skill 防御の優先順位は「現状の利用棚卸し → allowlist 化 → 最小権限化 → 監査」の順で進める。すべてを一度に実装しようとすると失敗しやすい。本セクションでは現場で最も聞かれる 2 つの問いに答える。
Q. タイ PDPA に対応している企業は、AI エージェント運用で追加的に何をすべきですか?
PDPA の文脈では、AI エージェントが個人データに触れる場合 (1) 処理目的の明示、(2) アクセス記録、(3) 越境移転の制限、(4) データ主体からの要求対応の 4 点が追加で必要になる。
実装上は次の整備が現実的だ。
タイ PDPA 対応の AES-256 暗号化実装 で扱った鍵管理パターンと組み合わせると、保存と通信の両方で監査要件を満たしやすい。
Q. 既存の SOC / SIEM がすでにある場合、AI エージェントの監視はどう統合すべきですか?
新たな監視基盤を立てるより、既存 SIEM に「MCP / Skill 呼び出し」を新しいデータソースとして取り込むのが現実的だ。最初の一歩として推奨するのは次の 4 点。
tool_call イベントにも適用するexec ・ http_post ・ファイル削除など)を別アラートクラスとして優先度を上げる「AI 専用の監視チーム」を新設せず、既存の SOC が AI エージェントを 1 つの新しいワークロードとして扱える状態を目指すと、人材的にも運用的にも持続可能になる。攻撃側目線の演習は AI レッドチーミング実践ガイド で扱っているので、防御演習に並行して取り入れたい。

AI エージェントのサプライチェーン攻撃は、MCP・Skill という新しい配信経路の出現と、Anthropic 自身が「by design」と認める設計選択によって、従来のセキュリティ対策が想定していなかった攻撃面を企業に持ち込んだ。
防御は単一のツールではなく、3 層で設計する。
すべてを一度に整備するのは現実的でない。現状の MCP / Skill 利用棚卸しから始め、まずは公開 MCP の利用を絞ることが、コスト対効果の高い最初の一手になる。
関連ガイドとして AIエージェントプロトコル(MCP・A2A)入門 ・ AI ガードレール実装 ・ AI レッドチーミング ・ Claude Mythos と Project Glasswing を併せて読むと、検出側と攻撃側の両面から AI エージェント運用の防御線を立体化できる。

Yusuke Ishihara
13歳でMSXに触れプログラミングを開始。武蔵大学卒業後、航空会社の基幹システム開発や日本初のWindowsサーバホスティング・VPS基盤構築など、大規模システム開発に従事。 2008年にサイトエンジン株式会社を共同創業。2010年にユニモン株式会社、2025年にエニソン株式会社を設立し、業務システム・自然言語処理・プラットフォーム開発をリード。 現在は生成AI・大規模言語モデル(LLM)を活用したプロダクト開発およびAI・DX推進を手がける。