AWS MCP ServerのPythonサンドボックス修正｜顧客対応不要でも確認するIAM境界

AWSは2026年10月23日、マネージドサービス「AWS MCP Server」のrun_scriptに関するCVE-2026-115845を公表しました。Pythonコード検証の禁止入力が不完全で、認証済みの利用者が細工したスクリプトを送ると、その利用者自身の分離セッション内で任意コードを実行できる可能性がありました。AWSはサービス側で修正済みとし、顧客側の更新作業は不要と説明しています。

対象組織が今行うべきことは、存在しないクライアント更新を探すことではありません。AWS MCP Serverを利用している担当者とIAMロールを把握し、run_scriptが必要か、MCP経由で許すAWS APIが過大でないか、CloudWatchとCloudTrailで想定外の利用を追えるかを確認します。本稿は公表内容を伝えるニュースと、マネージドAIツールを安全に運用するための恒久対策を分けて整理します。

確認されたのは利用者自身の分離セッション内の任意コード実行

AWSのセキュリティ告知によると、問題はrun_scriptのPythonコードバリデーターにありました。禁止すべき入力の一覧が不完全だったため、認証済みのリモート利用者が細工したスクリプトを渡すことで、任意コードを実行できる可能性がありました。影響版は「N/A」で、顧客が導入するライブラリーではなくAWSだけがホストするサービスです。

影響の表現には境界があります。公式告知が述べるのは「利用者自身の分離セッション環境内」です。他の利用者のセッション、AWSの管理基盤、利用者のPCへサンドボックスを越えて到達できたとは記載されていません。公開資料から、そのようなサンドボックス脱出や実環境での悪用を推定しないでください。一方、認証が必要だから安全と片付けることもできません。MCPクライアントを操作できる人や自動エージェントが、どの認証情報で何を実行できるかが影響条件になります。

AWSは10月23日12時（米国太平洋夏時間）に告知し、問題はサービス側で対処済み、顧客作業は不要としています。run_scriptを設計どおりAWS APIを呼ぶPythonスクリプトの実行だけに使う場合、回避策も不要です。したがって本件だけを理由に、非公開の修正版番号を推測したり、MCPクライアントを再導入したりする必要はありません。

修正されたコード検証とIAMの権限は別の境界

AWS MCP Serverの公式資料は、AWS APIの呼び出し、サンドボックス内のPython実行、スキルの利用に既存のIAM認証情報を使うと説明しています。run_scriptのコード検証が直っても、その認証情報に付与したAWS API権限は自動的に縮小されません。サービス側修正と権限設計を同じ完了項目にしないことが重要です。

AWSの一般提供時の説明では、run_scriptはネットワークやローカルのファイルシステム、シェルをエージェントへ直接渡さず、複数のAWS API呼び出し、結果の絞り込み、計算を一つの往復で行うための機能です。しかしサンドボックスはIAM権限を引き継ぎます。OS上の任意コードを制限する境界と、AWS APIでリソースを読み書きする認可は役割が異なります。前者の修正を、後者の最小権限の代わりにはできません。

最初に利用者、接続方式、ロール、用途を一行で結ぶ

棚卸しでは、MCPの設定ファイルだけを探して終えず、AWS MCP Serverへ接続するクライアント、利用者または自動処理、認証方式、引き受けるIAMロール、対象アカウント、利用するツールを一行で対応付けます。個人の開発端末、CI、運用ボット、共有のエージェント基盤では責任者と必要権限が異なります。run_scriptを一度試しただけの環境も、現在の設定と認証情報が残っているかを確認します。

• 主体：人、サービスアカウント、CIジョブのどれが接続するか
• 認証：SigV4経由かOAuth 2.1か、どのロールやセッションへ結び付くか
• 用途：ドキュメント検索、単発API呼び出し、run_scriptのどこまで必要か
• 範囲：読み取り、変更、削除の各操作をどのリソースに許すか
• 記録：担当者がCloudWatchとCloudTrailをどの期間・手順で確認するか

この表で、ドキュメントを調べるだけの利用者へ本番変更権限を渡している、検証用ロールを共有端末で使っている、run_scriptの利用目的を説明できない、といった差を見つけます。機能を使わない環境では、クライアント側の表示を隠すだけでなく、不要な認証情報と権限を取り除くことが本質です。

MCP経由の要求をIAM条件キーで区別する

AWSのIAM連携資料では、AWS MCP Serverが要求をSigV4で認証し、aws:ViaAWSMCPServiceとaws:CalledViaAWSMCPを加えて対象サービスへ転送すると説明しています。対象サービスは既存のIAMポリシー、セッションポリシー、アクセス許可の境界を使って認可します。直接のCLI操作とMCP経由の操作に同じ上限を与える必要はありません。

例えば、担当者は直接操作では削除できても、AWS MCP Server経由では削除を拒否する設計が可能です。公式のポリシー例は、aws:CalledViaAWSMCPがaws-mcp.amazonaws.comのときに削除操作を明示的に拒否する構成を示しています。コピーする前に対象サービス、必要な変更操作、障害対応の経路を洗い出し、検証アカウントで通常作業と拒否動作を確認してください。

プレビュー時代のaws-mcp:InvokeMcp、aws-mcp:CallReadOnlyTool、aws-mcp:CallReadWriteToolは現在効果がないと公式資料に明記されています。以前これらをDenyに使った組織は、現在も遮断できていると思い込まず、上記の条件キーへ移行したかを確認する必要があります。これは今回のCVE修正とは別に、既存設定を点検する具体的な理由です。

CloudWatchはツールの変化、CloudTrailはAPI行動を追う

CloudWatchメトリクスの資料によると、AWS MCP ServerはAWS-MCP名前空間へツール別のInvocation、Success、UserError、SystemError、Throttleを1分粒度で出します。aws___run_scriptだけを絞り、通常の件数と成功率を基準化すれば、使っていない時間帯の呼び出しや急増を検知する材料になります。

ただし、成功件数は安全な内容だったことを証明しません。エラーの急増がなかったことも、問題が悪用されなかった証拠にはなりません。CloudWatchは利用傾向の入口と位置付け、具体的なAPI操作はAWS MCP ServerのCloudTrail資料と、呼び出された各AWSサービスのイベントで確認します。要求時刻、送信元IP、主体、MCPセッション、対象サービスの変更を可能な範囲で結び付けます。

最近のイベントだけでなく継続的な記録が必要なら、組織のログ設計に沿ってtrailと保管先を確認します。OAuthを使う場合は、aws:SignInSessionArnでAPI行動とサインインセッションを関連付けられるかも検証項目です。利用者の入力文や秘密情報を無差別に別ログへ複製するのではなく、調査に必要な識別子と保持期間を決めてください。

修正後の受け入れ試験は権限の上限を見る

サービス側修正後の確認で、公開された問題を再現する攻撃スクリプトを本番へ送る必要はありません。隔離した検証アカウントと専用ロールで、意図した読み取りや複数APIの集約が成功し、許可していない変更・削除がIAMで拒否されることを確認します。検証用リソースに限定し、試験の主体、時刻、期待結果を残してCloudWatchとCloudTrailの記録まで追います。

クライアントの確認画面も防御の一部ですが、利用者が承認すれば広い権限が使える構成は残ります。プロンプトや取得文書がエージェントのツール選択へ影響しても、IAMの上限で重大操作を止められる状態を完了条件にします。既存のMCPのトークン宛先と権限境界の解説は認証一般を扱っています。本稿ではAWS MCP Server固有の条件キー、run_script、監査経路を追加の判断材料にしています。

不審な利用が見つかった場合の切り分け

想定外のrun_script呼び出しやAWS API操作が見つかった場合は、CVEの悪用と即断せず、利用者、セッション、クライアント、自動ジョブ、対象リソースを時系列で確認します。証跡を保全し、不要な接続を止め、影響するロールのセッションやOAuthトークンを組織の手順に沿って失効します。変更されたリソースと参照されたデータを調べ、必要に応じて認証情報を再発行します。

AWSの告知は顧客に一律の侵害調査を求めておらず、本稿の確認項目も侵害が発生したという意味ではありません。マネージドサービスの修正は迅速ですが、顧客が渡した権限、接続主体、ログの保管は顧客側の設計として残ります。今回の完了条件は、修正済みサービスを利用していること、必要最小限のIAM上限があること、run_scriptと下流APIの利用を追跡できることを別々に確認することです。

運用変更後は、棚卸し表と実環境がずれない仕組みも必要です。新しいMCPクライアントやロールを追加するときは、用途、所有者、許可するAWS API、MCP経由のDeny、監視担当をレビュー項目にします。退職・異動、プロジェクト終了、CIの廃止では接続設定だけでなく、ロールの信頼ポリシー、長く残った認証情報、OAuthクライアントとトークンも片付けます。

四半期など組織に合う間隔で、実際のCloudTrailイベントから未使用権限を探し、通常のrun_script件数と作業時間帯を見直します。権限を絞った結果として自動処理が失敗した場合は、すぐ全面的な許可へ戻さず、必要だったAPIと対象リソースを特定して最小の例外を追加します。これにより、次のサービス側不具合や誤操作が起きても、エージェントが到達できる範囲を事前に抑えられます。