NSA はなぜ動いたのか:MCP の普及速度がセキュリティを追い越した
MCP(Model Context Protocol)はこの一年で、AI Agent を企業システムに接続するための事実上の標準となり、Agent がデータベースの照会、メールの送信、コードの修正まで直接行えるようになりました。しかし 2026 年 5 月、米国国家安全保障局(NSA)はこの単一プロトコルを対象とした異例のセキュリティガイダンス「Model Context Protocol: Security Design Considerations for AI-Driven Automation」を公表しました。その冒頭のメッセージは明確です。MCP の普及速度はセキュリティ対策の整備を追い越しており、多くの組織がプロトコル設計者の想定を超えたリスクにさらされている、というものです。ガイダンスはアクセス制御、プロンプトの取り扱い、ツール実行権限、監査可能性、サードパーティ統合のガバナンスを網羅し、「制御されない自動アクション」と「入力チェックの欠如」という二大リスクを特に指摘しています。国家レベルの安全保障機関が、登場から二年に満たないプロトコルのために専用ガイダンスを出したこと自体が、これが理論上のリスクではなく、すでに起きている現実であることを物語っています。
実証済みの二つの攻撃パターン:騙される代理人と毒入りツール
一つ目は「confused deputy(騙される代理人)」です。2026 年 7 月、セキュリティ企業 Manifold Security は、Microsoft 公式の Azure DevOps MCP Server の脆弱性を公表しました。攻撃者が Pull Request の説明文に、画面上では見えない HTML コメントとして指示を隠しておくと、被害者が AI Agent にその PR のレビューを依頼した際、隠された指示が Agent のコンテキストに入り込み、その目的を乗っ取ります。Agent は被害者の資格情報を保持しているため、攻撃者自身では到達できないプロジェクトにアクセスし、データを持ち出せてしまうのです。
二つ目は「tool poisoning(ツールポイズニング)」です。MCP ツールの説明欄に悪意ある指示を埋め込む手法で、ユーザーの画面には表示されませんが、モデルはそれに従ってしまいます。2025 年 8 月に発表された MCPTox の研究では、実在する 45 の MCP Server と 20 の主要モデルを対象に検証した結果、攻撃成功率は最高 72.8% に達し、モデルが拒否することはほとんどありませんでした。Microsoft も 2026 年 6 月、この種の攻撃がデータ漏えいにつながり得ると正式に警告しています。両者に共通するのは、問題はモデルの賢さではなく、デプロイ構成に適切な信頼境界が設けられていない点にあるということです。
デプロイ前セキュリティチェックリスト:五つの観点を一つずつ確認する
攻撃パターンを理解した上で、AI Agent を社内システムに接続する前に企業が確認すべき五つの観点を挙げます。
- アイデンティティと権限:各 MCP ツールに独立した最小権限のトークンを発行します。Agent に個人アカウントや管理者の資格情報を直接持たせません。データ削除、外部送信、金銭操作などの高リスク操作には必ず人間の確認を義務付けます。
- 信頼境界:Agent が読み込む外部コンテンツ(PR コメント、メール、Web ページ、顧客のアップロードファイル)はすべて信頼できない入力として扱います。外部コンテンツを読むツールと、機密性の高い操作を実行するツールは別々の Agent に分け、一つに集約しません。
- ツール供給元のガバナンス:出所が確認でき、審査を経た MCP Server とスキルモジュールのみをインストールします。バージョンを固定し、ツールの説明欄を必ず確認します。全社的なホワイトリストを整備し、各チームによる自由なインストールを認めません。
- ネットワーク露出面:MCP Server をパブリックインターネットに直接公開しません。認証と通信の暗号化を必ず有効にします。NSA の推奨に従い、社内ネットワークを定期的にスキャンし、未承認または設定不備の MCP デプロイを洗い出します。
- 監査とモニタリング:すべてのツール呼び出しについて、トリガー元・パラメータ・結果を漏れなく記録します。異常な呼び出し頻度やアクセス範囲に対してアラートを設定します。インシデント発生時に「Agent は何を、なぜ行ったのか」に答えられる状態を確保します。
このチェックリストの使い方は明快です。五つの観点すべてにチェックが付いて初めて、デプロイ前の受け入れ審査に合格したことになります。一つでも答えられない項目があれば、接続を一旦保留し、対応を完了させてから進めてください。特に注意していただきたいのは、最も飛ばされやすい二番目の項目です。多くの企業は権限管理には取り組む一方で、Agent が読み込むコンテンツを習慣的に信頼してしまいがちですが、最近の実際の攻撃のほとんどは、まさにこの隙間から侵入しています。
サプライチェーンからの警鐘:私たち自身のエコシステムも標的に
恩梯科技(Nerdtechnic)が長年運営に取り組んできたオープンソース AI Agent プロジェクト OpenClaw も、そのスキルマーケットプレイス ClawHub が 2026 年初頭、大規模な悪意あるスキルの登録事案に見舞われました。セキュリティ研究者の調査により、暗号資産ツールを装って利用者の資格情報を窃取しようとする数百件の悪質なスキルが発見されたのです。私たちはこの事実から目を逸らさず、正面から向き合うことを選びます。これはオープンなエコシステムにおけるサプライチェーンガバナンスが、あらゆる Agent フレームワークに共通する課題であることを示しており、OpenClaw が企業導入において権限のレッドライン、スキル供給元の管理、完全な監査証跡を特に重視している理由でもあります。フレームワークがオープンである以上、ガバナンスの層は導入側が厳格に担わなければなりません。オープンソースの Agent フレームワークを評価中の企業にとっての正しい教訓は、機能一覧だけを見るのではなく、「ガバナンス機能がどれだけ充実しているか」を選定基準に加えることです。
セキュリティチェックを導入プロセスに組み込む:事後対応にしない
MCP がもたらす統合の効率は本物ですが、リスクもまた本物です。正しい結論は「まだ接続しない」ことではなく、上記のチェックリストを導入プロセスの受け入れゲートに組み込むことです。PoC の段階から最小権限で運用し、本番稼働前に露出面のスキャンとレッドラインの設定を完了し、稼働後も監査を継続します。多くの企業に足りないのはツールではなく、セキュリティを AI プロジェクトのスケジュールに組み込む決断です。統合計画にセキュリティ受け入れの時間をあらかじめ確保しておくことは、インシデント後に信頼を立て直すよりも、はるかに安上がりです。恩梯科技の AI 導入コンサルティングは、OpenClaw と MCP 統合のセキュアなアーキテクチャ設計を含め、まさにこのプロセスで企業の評価と導入をご支援しています。AI Agent を社内システムに接続しようとお考えでしたら、着手の前に、ぜひこのチェックリストで安全をお確かめください。