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 サーバーは、設計上「クライアントから送られたリクエストに応じて OS コマンドを実行できる」性質を持つ。この実行能力こそが、サプライチェーン攻撃の入口となる。

AI エージェントのサプライチェーンに関する事案が、複数の公開ソースから報告されている。代表例を 3 件挙げる。

• Anthropic MCP の "by design" RCE 脆弱性: OX Security が 2026 年 4 月 15 日に公開したアドバイザリで、Model Context Protocol のリファレンス実装が任意コマンド実行を許す設計になっていることが指摘された。Anthropic は STDIO 実行モデルを「設計通りの安全なデフォルト」として大幅変更を行わず、サニタイズは利用者側の責任とする方針を示した（出典: OX Security / SecurityWeek）。影響範囲は累計 1.5 億ダウンロード超とされる。
• 公開 MCP サーバーの大量露出: BlueRock Security が 7,000 件超の MCP サーバーを分析し、約 36.7% に SSRF（Server-Side Request Forgery）の脆弱性候補を確認したと公表している。認証なしで公開ネットワークに露出している MCP サーバーも多数報告されている。
• マーケットプレイス経由の悪意あるスキル配信: AI エージェントの「スキルマーケット」を経由した悪意あるスキル配布の観測が、複数のセキュリティリサーチャから公表されている。

防御側の準備状況についても、Cisco「State of AI Security 2026」では、エージェント型 AI を本番展開できる準備が整っている組織は 約 29% にとどまるという結果が報告された。攻撃面は広がりつつ、防御側の整備は追いついていない。

最初の防御線は「どの MCP サーバー・Skill を実行できるか」を許可リスト（allowlist）で明示することだ。デフォルト全許可は実質ノーガードであり、設計上の脆弱性が表面化している以上、企業側で経路の信頼を限定する以外に出発点はない。

検証すべき配信経路は (1) 公開ネットワーク上の MCP サーバー、(2) マーケットプレイスで配布される Skill、(3) 社内開発の MCP / Skill の 3 種に分けられる。それぞれリスクの性質が異なる。

公開 MCP サーバーを利用する際、最低限以下を確認する。

• 認証方式（OAuth・API キー・mTLS）が文書化されており、無認証エンドポイントが存在しないこと
• 提供者の組織情報・連絡先・脆弱性報告窓口が明記されていること
• 通信が TLS で暗号化され、証明書ピンニングなど追加保護があること
• 提供者の SBOM・変更履歴が公開され、依存ライブラリの脆弱性追跡が可能なこと

無認証で誰でも叩ける公開 MCP は、業務利用には適さない。最初は「社内ネットワーク内に閉じた MCP サーバー」または「認証付きの提供者直結 MCP」のみに絞り、外部公開 MCP は段階的に評価して取り込むのが現実的だ。

Skill や MCP パッケージは「コンテナイメージや npm パッケージと同じく改ざんされうる」前提で扱う。

• 署名検証: 配布物に提供者の署名（Sigstore / cosign 等）が付いていることを確認し、検証通過したもののみ取り込む
• SBOM: Skill 内で利用する依存ライブラリ一覧を取得し、既知の CVE と照合する
• ハッシュ固定: 取り込み時のハッシュを保存し、定期的に再計算して改ざんがないか比較する

理想は「マーケットプレイスからの自動更新を許可せず、社内のレビューを通過したバージョンのみを配布する内部ミラー」を持つことだ。社内ミラーは過剰投資に見えるが、悪意あるスキルが実際に流通している観測値を踏まえれば、サプライチェーンの境界を企業側に引き戻すコストとして妥当な選択になる。

MCP / Skill が呼び出すコマンドや API の権限を最小化し、エージェント実行を OS / ネットワーク両面でサンドボックス化することで、悪意あるツールが混入しても被害を局所化できる。「by design」の脆弱性が許す挙動を前提に、被害範囲を物理的に絞るのが Step 2 の役割だ。

権限分離は OS レイヤと通信レイヤの両方で設計する。

エージェント本体・MCP クライアント・MCP サーバーは、それぞれ別の実行コンテキストに分離するのが基本だ。

「とりあえず docker で動かしている」という状態は、実は分離が不十分なケースが多い。コンテナ内で root 実行、ホストの Docker socket をマウント、/var/run を共有といった構成は、サンドボックスとは呼べない。Skill が実行できるコマンド集合を allowlist された実行可能ファイルだけに絞り、それ以外のシステムコールはブロックする方針が安全だ。

MCP サーバーのおよそ 4 割近くが SSRF 脆弱性を持つ可能性が指摘されている（BlueRock Security による分析）。これは MCP / Skill が「内部ネットワーク・クラウドメタデータエンドポイントへ任意の HTTP リクエストを発行できてしまう」現象だ。

防御は egress（外向き通信）の allowlist 化が中心となる。

• メタデータエンドポイント 169.254.169.254 への通信を全面ブロック（IMDSv2 強制でも追加防御として）
• プライベート IP 帯（10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 等）への通信を、業務上必要な接続先以外ブロック
• 外部通信は HTTPS かつドメインの allowlist で限定
• DNS リバインディング攻撃を考慮し、IP 解決後の再検証を入れる

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 で精査する」のは現実的でないことが多いため、書き込み・削除・外部通信を伴うツール呼び出しのみ重い検査を入れる方針が、コストとリスクのバランスとして取りやすい。

MCP / Skill の呼び出しは「いつ・誰が・どのエージェントが・どのツールを・どの引数で・何を返したか」を構造化ログとして残すのが基本だ。最小限ログに含めたい項目を整理する。

• リクエスト ID（エージェントセッションと紐づけ可能）
• 呼び出し元のエージェント ID・ユーザー ID（HITL の場合は承認者も）
• ツール名・パラメータ（PII はマスク）
• 戻り値のサイズと外部通信先
• 例外・タイムアウトの発生有無

異常検知のシグナルとしては、(a) 短時間での大量ツール呼び出し、(b) 普段使わないドメインへの egress、(c) 大量のファイル読み出し、(d) 個人データを含む応答の外部送信、が定番だ。これらは既存の SIEM / SOC ツールに組み込めるシンプルなルールから始めると、初期投資を抑えながら可視化できる。

監査ログは攻撃検知だけでなく、PDPA や監査対応で「個人データへのアクセス履歴を提示できるか」を担保する 役割も担う。AES-256 等の 暗号化実装 と組み合わせて、保存時の機密性とトレーサビリティを両立させたい。

MCP / Skill の防御は「デフォルトの設定で十分」「社内ネットワークなら安全」という前提が崩れているのが現実だ。最も多い失敗は構造的な過信から来る。

ここでは観測される 2 つの典型例を取り上げる。

最も頻発する誤解は「ローカルマシンで動かしているから外部に出ない」という発想だ。Anthropic の MCP リファレンス実装の脆弱性は、ローカル実行であってもユーザーマシン上で任意コマンドを実行できる点が核心だった。具体的に何が起きるかを整理する。

• ブラウザに保存された Cookie・パスワード・SSH 鍵の窃取
• 開発者 PC から到達できるクラウド管理コンソール（AWS / GCP）への横移動
• IDE 内に置いてある別案件のソースコード・顧客データの吸い出し

「ローカル」は「企業の境界の外側」ではなく、業務システムへ接続できる別の高権限ホストとして扱うのが正しい。社内ガイドラインでは、MCP / Skill を動かす PC が本番 DB への直接アクセスを持たない構成にし、必要なら踏み台 + 短命クレデンシャル経由に切り替えると、被害範囲が大きく縮む。

もう 1 つよくあるのが、開発時の便利設定が本番に流れ込むパターンだ。

• 開発で使った無認証 MCP サーバーが、本番 Docker イメージに残ったままデプロイされる
• 環境変数 MCP_ALLOW_ALL=true が本番にも設定される
• デバッグ用に CORS を全開放した API が本番でもそのまま稼働

これらは古典的な構成ミスだが、AI エージェント時代は影響範囲が大きい。開発・ステージング・本番で MCP / Skill 構成を別ファイルに分離し、CI/CD パイプラインで「本番に許可されない MCP 一覧」をビルド時に拒否する仕組みが効く。Infrastructure as Code で構成を管理し、レビュー対象に含めると検出しやすくなる。

MCP / Skill 防御の優先順位は「現状の利用棚卸し → allowlist 化 → 最小権限化 → 監査」の順で進める。すべてを一度に実装しようとすると失敗しやすい。本セクションでは現場で最も聞かれる 2 つの問いに答える。

Q. タイ PDPA に対応している企業は、AI エージェント運用で追加的に何をすべきですか？

PDPA の文脈では、AI エージェントが個人データに触れる場合 (1) 処理目的の明示、(2) アクセス記録、(3) 越境移転の制限、(4) データ主体からの要求対応の 4 点が追加で必要になる。

実装上は次の整備が現実的だ。

• MCP / Skill の監査ログに「処理した個人データのカテゴリ」をタグ付けする
• 個人データを扱う Skill は別グループに隔離し、PDPA トレーニングを受けた担当者のみが配布権限を持つ
• 越境送信が発生する MCP（海外 API 呼び出し等）には egress フィルタと事前同意の仕組みを組み合わせる
• データ主体からのアクセス履歴開示要求に応えられるよう、ログの保持期間を業務要件に合わせて十分長く設定する

タイ PDPA 対応の AES-256 暗号化実装 で扱った鍵管理パターンと組み合わせると、保存と通信の両方で監査要件を満たしやすい。

Q. 既存の SOC / SIEM がすでにある場合、AI エージェントの監視はどう統合すべきですか？

新たな監視基盤を立てるより、既存 SIEM に「MCP / Skill 呼び出し」を新しいデータソースとして取り込むのが現実的だ。最初の一歩として推奨するのは次の 4 点。

1. MCP / Skill のログを JSON Lines 形式で標準化し、既存 SIEM の取り込み経路に乗せる
2. 既存の脱獄・データ流出検知ルールを tool_call イベントにも適用する
3. AI エージェントセッションを「ユーザーセッション」相当のエンティティとして登録する
4. 高リスクツール呼び出し（exec ・ http_post ・ファイル削除など）を別アラートクラスとして優先度を上げる

「AI 専用の監視チーム」を新設せず、既存の SOC が AI エージェントを 1 つの新しいワークロードとして扱える状態を目指すと、人材的にも運用的にも持続可能になる。攻撃側目線の演習は AI レッドチーミング実践ガイド で扱っているので、防御演習に並行して取り入れたい。

AI エージェントのサプライチェーン攻撃は、MCP・Skill という新しい配信経路の出現と、Anthropic 自身が「by design」と認める設計選択によって、従来のセキュリティ対策が想定していなかった攻撃面を企業に持ち込んだ。

防御は単一のツールではなく、3 層で設計する。

• Step 1: どの MCP / Skill を取り込むかを allowlist で限定し、署名・SBOM で配信経路を検証する
• Step 2: 実行は最小権限のサンドボックスで行い、SSRF / egress を物理的に遮断する
• Step 3: すべての呼び出しを監査ログ化し、異常検知と PDPA / SOC の要件に接続する

すべてを一度に整備するのは現実的でない。現状の MCP / Skill 利用棚卸しから始め、まずは公開 MCP の利用を絞ることが、コスト対効果の高い最初の一手になる。

関連ガイドとして AIエージェントプロトコル（MCP・A2A）入門 ・ AI ガードレール実装 ・ AI レッドチーミング ・ Claude Mythos と Project Glasswing を併せて読むと、検出側と攻撃側の両面から AI エージェント運用の防御線を立体化できる。