AWS Security Hub の知見をAIエージェントに渡す — MCP App で考える権限境界と監査ログ設計

2026年7月27日、AWSは AWS Security Hub MCP App をプレビューで公開しました。Security Hub が検出した exposure findings（露出に関する検出結果）を Model Context Protocol（MCP）経由で Claude Desktop などのAIエージェントに渡し、自然言語でセキュリティ態勢を調査できるようにするものです。公式ページには「すべてのツールは読み取り専用で、環境への変更は一切行わない」と明記されています。

ただし「読み取り専用である」ことと「設計判断が要らない」ことは同じではありません。攻撃経路やリソース構成は、攻撃者にとってこそ価値が高い情報だからです。本記事では、まずこの機能の公式仕様を整理し、そのうえで機微なセキュリティ知見をAIエージェントに渡すときに検討すべき権限スコープ・配置境界・監査ログの論点を扱います。

背景：Security Hub の exposure findings とは

すでに Security Hub を運用している方は次のセクションまで読み飛ばしてください。

AWS Security Hub は、AWSアカウント内のセキュリティに関する検出結果を集約・正規化して一覧できるサービスです。

そのなかで exposure findings は、個々の設定不備を単体で並べるのではなく、複数のシグナルを突き合わせて「実際にどう露出しているか」を示す種類の検出結果です。今回の MCP App の公式説明では、上位の exposure findings を見ることに加えて、ある findings の攻撃パスと拡張ネットワークパスを掘り下げる、相関する findings と影響を受けるリソースの構成を調べる、修復推奨（remediation recommendations）を得ることができるとされています。つまり扱う情報は「このリソースの設定が緩い」という単発の指摘ではなく、「どのリソースがどの経路でつながっており、どこから侵害が連鎖しうるか」という構造的な知見です。この性質が、後述する設計判断のすべての出発点になります。

背景：MCP とローカルMCPサーバー

Model Context Protocol（MCP） は、AIエージェントと外部のツール・データソースを接続するためのオープンなプロトコルです。エージェント側（MCPクライアント）とツール側（MCPサーバー）を分離し、サーバーが公開する「ツール」をエージェントが必要に応じて呼び出す、という構造をとります。

重要なのは、ローカルMCPサーバーは利用者の端末上のプロセスとして動作し、そのプロセスが持つ権限で外部APIを呼ぶという点です。サーバー自体はクラウド上のマネージドサービスではありません。したがって「どの端末で動くか」「どの認証情報を持つか」は、利用者側の設定に委ねられます。

発表内容の整理：Security Hub MCP App の仕様

公式ページに記載されている事実を整理します。

項目	公式の記載
形態	ローカルマシン上で動作する MCP サーバー
接続先	Claude Desktop など MCP に対応したAIエージェント
できること	上位の exposure findings の閲覧、攻撃パスと拡張ネットワークパスの掘り下げ、相関する findings と影響を受けるリソース構成の確認、修復推奨（remediation recommendations）の取得
ツールの性質	すべて読み取り専用。環境への変更は一切行わない
認証	既存のAWS認証情報を利用
応答形式	各ツール呼び出しは、AIエージェントが推論するためのテキストサマリーと、同じ会話のなかで利用者が確認できるインタラクティブな可視化の両方を返す
提供範囲	Security Hub が利用可能な全AWS商用リージョンでプレビュー提供
費用	追加費用なし

この応答形式は実務上の意味を2つ持ちます。1つは、要約された構成情報や攻撃経路がテキストとしてエージェント側に渡ること。もう1つは、同じ会話のなかに可視化が並ぶことで、エージェントの要約を鵜呑みにせず利用者が裏取りできることです。前者は後述する持ち出し経路の話に、後者は調査結果の信頼性の話につながります。

また、修復推奨が得られるといっても、あくまで提案が返るだけです。公式には全ツールが読み取り専用で環境への変更は行わないと明記されているため、提案された修復を実際に適用する工程は、これまでどおり別の手段で行うことになります。

位置づけとしては、これまでコンソールで findings を絞り込みながら追っていた調査を、自然言語のやり取りに置き換えるものになります。

なぜ「読み取り専用」でも設計判断が要るのか

「読み取り専用」という記載が保証しているのは、この機能を通じてAWS環境が変更されたり壊れたりしないことです。保証していないのは、読み出した内容がその後どこへ行くかです。統制すべき対象は、書き込み権限ではなく情報の持ち出し経路になります。

検討対象は次の3つです。

1. モデル提供者側へ渡るテキスト。 各ツール呼び出しは、AIエージェントが推論するためのテキストサマリーを返します。MCPサーバーがローカルで動いていても、エージェント本体が外部の推論基盤を使う構成であれば、要約された構成情報・攻撃経路はプロンプトの一部としてその経路を通ります。利用するAIエージェントとモデル提供者のデータ取り扱い条件が論点に含まれます。
2. 端末に残る会話ログ。 エージェントの会話履歴は、多くの場合ローカルまたは提供者側に保存されます。findings の内容が写しとして残り、Security Hub 側のアクセス制御が及ばない場所に置かれる前提で考える必要があります。
3. 参照範囲そのもの。 読み取り専用であっても、参照できる範囲が組織全体なのか担当アカウントだけなのかで、1回の会話に載る情報量は大きく変わります。

権限スコープ設計の論点

ここから先は公式に具体的な設定手順が示されている範囲を超えるため、一般的な設計論として整理します。実際の設定値は、導入時に公式ドキュメントで最新の仕様を確認してください。

「ツールが読み取り専用」と「認証情報が読み取り専用」は別

最も混同しやすいのがこの点です。本機能は既存のAWS認証情報を利用します。開発者端末に設定済みのプロファイルは、日常の運用作業のために書き込み権限まで含む広い権限を持っていることが少なくありません。ツール側が読み取りしか行わなくても、その認証情報自体は端末上の他のプロセスからも同じように使えます。

したがって、MCPサーバーに渡すプロファイルを分け、Security Hub の読み取り系アクションに限定した専用ロールを用意する、という分離が設計の第一歩になります。IAMポリシー側で範囲を絞っておけば、ツールの仕様変更やクライアント側の不具合に依存せず、権限の上限を自分で決められます。

参照範囲をどこまで広げるか

Security Hub を委任管理者アカウントに集約している場合、1つの認証情報で組織全体の findings が見える構成になり得ます。調査の効率としては望ましい一方で、1つの端末・1つの会話に組織全体の攻撃経路が集まることを意味します。担当範囲ごとにロールを分けるか、集約ビューへのアクセスを限られたメンバーに絞るかは、運用の初期に決めておく論点です。

ローカルMCPサーバーをどこに置くか

「ローカルマシン上で動作する」という仕様は、配置境界の選択が利用者側に委ねられていることを意味します。選択肢としては、開発者の業務端末で動かす構成と、管理された作業環境（踏み台や仮想デスクトップなど、統制の効くホスト）で動かす構成が考えられます。

判断材料になるのは、その端末にディスク暗号化・持ち出し制御・資産管理が適用されているか、個人所有の端末が含まれ得るか、といった端末側の統制状況です。findings が落ちる先の統制水準が、そのまま情報の管理水準になります。

監査ログ・利用ルールの運用設計

「誰が・いつ・何を参照したか」を後から追えるかどうかは、セキュリティ情報を扱う機能では特に重要です。ここには構造的な非対称性があります。

AWS側に残るのは、AWS APIの呼び出し記録です。 AWS APIの呼び出しは CloudTrail に記録される仕組みになっているため、どのプリンシパル（IAMロールやユーザー）が、いつ、どの操作を呼んだかは追跡できます。記録対象の詳細はサービスごとに異なるため、導入時に公式ドキュメントで対象範囲を確認してください。

一方で残らないのは、エージェント側のやり取りです。 どのような質問をしたか、どんな回答が返ったか、会話に並んだ可視化で何を見たか、その内容をどこに転記したかは、AWSの監査ログの外側で起きます。「AWS APIの呼び出し履歴は追えるが、調査の中身は追えない」という前提で、運用ルール側で補う設計になります。

補い方の方向性としては、次のような組み立てが考えられます。

• プリンシパルを個人に紐づける。 共有の長期アクセスキーではなく、IAM Identity Center 等を経由した一時的な認証情報を使うことで、CloudTrail 上のプリンシパルが個人と対応します。「誰が」を成立させるための前提条件です。
• 使ってよい対象を明文化する。 どのアカウント・どの環境に対して使ってよいか、本番アカウントを含めるか、インシデント対応中の利用を認めるかを事前に決めます。
• アウトプットの扱いを決める。 会話の内容や findings の抜粋を、チケット・チャット・ドキュメントへ転記してよい範囲を定めます。監査ログでは追えない部分なので、ルールと教育で担保する領域になります。
• プレビュー提供であることを前提にする。 本機能は現時点でプレビューです。仕様・提供条件が変わる可能性があるため、恒久的な統制手順に組み込む前に、公式ページで提供状況を確認しておく必要があります。

まとめ

本記事のポイントを3つに整理します。

1. AWS Security Hub MCP App は、exposure findings をAIエージェントに渡すローカルMCPサーバーです。findings の閲覧、攻撃パスの掘り下げ、修復推奨の取得を扱い、各ツール呼び出しはテキストサマリーとインタラクティブな可視化の両方を返します。すべてのツールが読み取り専用で、既存のAWS認証情報を利用し、Security Hub が利用可能な全AWS商用リージョンで追加費用なしのプレビュー提供です。
2. 読み取り専用が保証するのは「環境が変わらないこと」だけです。修復推奨も提案が返るだけで適用はされません。攻撃経路やリソース構成はテキストサマリーとしてエージェント側へ渡るため、統制の焦点は情報の持ち出し経路になります。
3. 設計の要点は、認証情報の権限範囲・参照スコープ・サーバーの配置境界の3点です。監査ログはAWS API呼び出しまでしか追えないため、プリンシパルの個人紐づけと利用ルールの明文化で補います。

セキュリティ情報をAIエージェントに接続する設計は、同種の機能が増えるたびに繰り返し問われます。「何ができるか」だけでなく「何が外に出るか」を並べて考える枠組みを、早い段階で持っておくと応用が利きます。

出典

• AWS Security Hub launches MCP App（AWS What’s New・2026-07-27）
• AWS Security Hub（公式サービスページ）