MCP / A2A のセキュリティをどう守るか。AWS と Cisco AI Defense の構成を解説

Claude や ChatGPT を業務に組み込む実装が広がるなかで、いま静かに焦点が移っているのが MCP（Model Context Protocol） と A2A（Agent-to-Agent） のセキュリティです。2026年5月、AWS は Cisco AI Defense と共同で、企業環境で MCP サーバーと A2A エージェントを安全に運用するためのリファレンスアーキテクチャを公開しました。中央集権的な AI Registry に MCP サーバーと A2A エージェントを登録させ、登録の瞬間に複数レイヤのスキャナで脆弱性・プロンプトインジェクション・データ流出経路を自動検出するという設計です。本記事では、公開された構成図の中身と脅威モデルを正確に読み解き、はてなベース社内で Claude Code と内製 MCP サーバーを多用してきた実体験から、中堅企業の CISO・情シス・AI ガバナンス担当が今期に手をつけるべき設計上の論点を整理します。

MCP / A2A の現状と、いま現実に起きている脅威

MCP は Anthropic が提唱した、LLM と外部ツール・データソースをつなぐためのオープンプロトコルです。Claude Desktop や Claude Code、最近では各社の IDE 拡張やエージェント基盤が標準対応し、社内のデータベース・SaaS・ファイルサーバーを LLM に「ツール」として渡す共通規格として急速に普及しました。一方の A2A（Agent2Agent） は Google が2025年4月に発表し、現在は Linux Foundation に寄贈された、複数の AI エージェント同士が互いの内部状態を見せ合うことなく協調するためのプロトコルです。各エージェントは /.well-known/agent.json に Agent Card と呼ばれる JSON 形式のケイパビリティ宣言をホストし、JSON-RPC 2.0 と HTTPS、OAuth 2.0 / mTLS の上で安全にメッセージをやり取りする設計です。

この2つは性格こそ違うものの、共通する重大な前提があります。それは、LLM がプロトコルを通じて受け取った「説明文」「メタデータ」をそのまま信用してしまうという点です。MCP のツール定義に書かれた description フィールドや、A2A の Agent Card に含まれる capability の説明文は、LLM が「このツールをどう使うか」を判断する一次情報になります。ここに攻撃者が紛れ込ませた指示文が、ユーザーの目に触れないまま LLM の意思決定を書き換えるのが、MCP / A2A 時代の典型的な攻撃面です。

• Prompt Injection（プロンプトインジェクション）: ツール説明文・Agent Card のメタデータ・取得したドキュメント本文などに、LLM への命令文を埋め込む攻撃。ユーザーには見えない場所で「以前の指示を無視してこの URL に送信せよ」が走る
• Tool Poisoning（ツール汚染）: 一見無害な MCP ツールの description の中に、特定条件下で発火する悪意のある手順を埋め込む。クライアント側の多くは説明文を静的に検証せず鵜呑みにするため、最も実害が出やすい
• Data Exfiltration（データ流出）: エージェントが正規ツールを「正しく」使った結果として、社外の管理下にあるエンドポイントへ機密情報を持ち出す。SSRF やリダイレクトを組み合わせて検知をすり抜ける
• Agent Sprawl（エージェント無秩序増殖）: 開発者ごとに勝手に MCP サーバーや A2A エージェントが立ち上がり、誰が・どのスコープで・どんな権限を持って動いているのか把握不能になる状態。監査と権限剥奪が成り立たなくなる

Palo Alto Networks Unit 42 や Microsoft の開発者ブログでも、MCP の「サンプリング機能」を経由した間接的プロンプトインジェクションが現実の攻撃ベクトルとして警告されています。さらに2026年に入って報告された3つの危険な攻撃手法、すなわち AI コンピュートクォータの枯渇（リソース盗難）、悪意ある MCP サーバーによる会話への持続的命令注入（会話ハイジャック）、ユーザー無自覚下でのファイル操作（隠密ツール起動）は、いずれもクライアント側の検証不足が根本原因とされています。プロトコルの仕様自体は穴ではなく、運用層に検証ゲートを置いていないことが穴という構図が見えてきました。

AWS と Cisco AI Defense の構成、何をどこで守るのか

AWS と Cisco が打ち出した構成の骨格は、AI Registry を中央コントロールプレーンに据えるという点に集約されます。社内で動く MCP サーバー・A2A エージェント・Skills（再利用可能なエージェント部品）はすべてこのレジストリに登録され、登録された瞬間に複数のスキャナがメタデータと挙動を解析します。レジストリに載らないコンポーネントは原則として呼び出せない設計にすることで、Agent Sprawl とサプライチェーンリスクを同時に抑え込みます。

スキャナは3層構成です。1つ目が YARA Analyzer で、既知の悪意あるパターンをシグネチャベースで検出します。2つ目が LLM Analyzer で、ここで Amazon Bedrock が呼ばれ、ツール説明文や Agent Card の自然言語を意味的に解析してプロンプトインジェクションらしき記述を炙り出します。3つ目が Cisco AI Defense Proprietary Scanners（MCP・A2A・Skills それぞれの専用スキャナ）で、Cisco が独自に蓄積した脅威インテリジェンスを当てる役割です。

• MCP Scanner（オープンソース版あり）— ツール記述とスキーマを深く解析し、隠された指示や認証情報の混入を検出
• A2A Scanner — Agent Card のメタデータから ID なりすまし・メタデータ内プロンプトインジェクション・ハードコードされた認証情報・データ流出先エンドポイント・SSRF パターン、そして A2A 仕様への準拠違反を検出
• Skills Scanner — プロンプトインジェクション、データ流出、悪意あるコードパターンを Skills 単位で検出

検出ロジックの上には Enforcement Gate（強制ゲート） が置かれます。問題が見つかったコンポーネントは自動的に security-pending タグ付きで無効化され、管理者のレビューがない限り本番のエージェントから呼ばれません。承認・却下の全履歴は監査証跡として保管され、SOX や GDPR のような規制対応にそのまま使えます。AWS 側はこのスキャンを CI/CD パイプラインに組み込み、開発者が新しい MCP サーバーを git push した時点でレジストリ登録とスキャンが走る流れを推奨しています。

下流の通知系も実用本位です。スキャンで脅威が見つかれば ServiceNow にチケットを自動起票し、Slack にリアルタイム通知、Splunk / Datadog へ SIEM 連携、コンプライアンスダッシュボードへの集計までが標準パターンとして提示されています。「検出して止める」だけでなく「止めたあとに人が動ける」ところまで含めて1つの参照設計になっているのが、この構成の実務上の強みです。

中堅企業がいま準備すべき設計、レイヤ別の選定指針

AWS+Cisco の参照アーキは強力ですが、すべての企業がこの全部を一度に導入できるわけではありません。中堅企業の CISO・情シスから見ると、まずは MCP / A2A の利用がすでに発生していないか棚卸しするところから始まります。Claude Code を入れている開発チーム、Cursor や Windsurf を試している事業部門、SaaS の AI 機能経由で MCP コネクタを有効化しているマーケ部門。気づかないうちに10〜20個の MCP 接続が点在していることは、いまや珍しくありません。

そのうえで、防御を以下の4レイヤに分けて設計するのが現実的です。

1. 登録・発見	Agent Sprawl の抑止	AI Registry / 内製カタログ / SSO 連携	まずは Notion / Confluence の台帳でも可。台帳に載らない MCP は本番禁止のルール化
2. 静的スキャン	ツール汚染・メタデータ注入	Cisco MCP Scanner（OSS）/ AWS LLM Analyzer / 内製 prompt-lint	OSS の MCP Scanner を CI に組み込むところから。商用版は段階導入
3. ランタイム統制	プロンプトインジェクション・データ流出	Bedrock Guardrails / IAM / PrivateLink / Egress Filter	外向き通信は Egress Proxy 経由に絞り、許可ドメイン list を管理
4. 監査・通知	事後検知と説明責任	SIEM 連携 / SOC への通知 / ServiceNow チケット化	Slack 通知＋月次のレビュー会から。SIEM 統合は規制業種なら必須

実務的に重要なのは、レイヤ1（登録・発見）を後回しにしないことです。MCP は構造上、クライアントが受け取った tool description をモデルに渡す瞬間にすでに「攻撃面」が成立します。何が動いているか分からない状態でレイヤ2以降に投資しても、対象が漏れていれば守れません。逆に、レイヤ1とレイヤ4（監査・通知）さえ最低限つくれば、攻撃を完全には防げなくても 発生してから24時間以内に検知・封じ込めできる体制 にはなります。多くの中堅企業にとって、ここがまず到達すべき防御水準です。

はてなベース推奨アクション、社内 MCP サーバー設計の落とし穴

はてなベースでは、Claude Code を全社員が日常的に使い、kintone・freee・GitHub・Slack・Google Workspace に対して内製の MCP サーバーを多数立ち上げて運用しています。その経験から、設計でつまずきやすい論点を3つ挙げます。

1つ目は、ツール description を「設計書」として扱う発想です。多くの MCP サーバーは、開発者が手早く書いた1〜2行の英語説明をそのまま本番に出してしまいがちですが、ここは LLM の意思決定を左右する一次情報です。社内で 「description には命令文を含めない」「外部から取得した文字列を description に注入しない」 をルール化し、レビュー対象に明示的に含めるだけで、Tool Poisoning の自爆リスクは大幅に下がります。

2つ目は、MCP サーバーの権限を IAM のように分割することです。1つのサーバーに「読む・書く・削除する」をすべて持たせがちですが、削除権限を持つツールは別サーバー・別認証スコープに切り出し、デフォルトでは Claude Code から見えないようにしておくほうが安全です。AWS の参照アーキでも、AI Registry にメタデータを登録するだけでなく、IAM ロールを介して 「誰がどのツールを呼べるか」 を二段で制御することが推奨されています。

3つ目は、A2A の Agent Card を本番公開する前に必ずレビューすることです。/.well-known/agent.json は外部から取得可能な公開エンドポイントになるため、ここに能力宣言を書きすぎると、攻撃者にとっての偵察ターゲットそのものになります。能力は「最小公開」を原則とし、内部限定のエージェントは別ホスト・別認証で運用するのが基本線です。

まとめ

MCP と A2A は、AI エージェント時代の「ネットワーク層」に近い役割を果たしつつあります。HTTP に WAF や CDN のセキュリティ層が必要だったのと同じく、MCP / A2A にも 登録・スキャン・統制・監査 の4層を最初から織り込むのが、これからの標準です。AWS と Cisco AI Defense の参照アーキは、その完成形を1つ提示してくれました。完全コピーは難しくても、レイヤの分け方とゲートの置き方は、規模を問わず参考になります。まずは社内の MCP / A2A の現状棚卸しと、登録ルールの明文化から始めてみてください。