モデル承認を迂回してツールが走る——AWS/Google/Vercelのエージェント基盤で設計欠陥、各社が即応パッチ済みです

今日の深掘りポイント

• エージェント実行系の“安全前提”——「必ずモデルの承認を経てツールを叩く」が土台から崩れた事案です。会話→モデル→ツールという経路のどこに堅牢な信頼境界を置くかの再設計が要ります。
• 問題の本質はプロンプトやフィルターの回避ではなく、オーケストレーターの状態管理と権限移譲の欠陥です。会話履歴や最終メッセージを「信頼できる事実源」にしてしまうアンチパターンが露呈しました。
• 対応の軸は、署名付きツール呼び出し（不可偽造なケイパビリティ・トークン）、ゼロトラストな実行ガード（会話文脈を不信任にする）、観測可能性（モデル未経由実行の検知）の三点セットです。
• 影響は直近の個別製品に留まりません。エージェント化を進める全社にとって、ツール実行基盤を「セキュアな制御プレーン」として扱うアーキテクチャ原則が求められます。
• メトリクス上も新規性と確度が高く、行動に移しやすい類型の欠陥です。緊急パッチ適用に加え、設計レベルの是正と検知体制の追加を並行で打つのが合理的です。

はじめに

AWS、Google、Vercelが提供するエージェント基盤で、モデルを実行せずにツールを起動できてしまう設計欠陥が報告され、各社が修正を完了しています。影響対象はAmazon Bedrock AgentCore、GoogleのAgent Development Kit（ADK）、Vercel AI SDKで、条件はそれぞれ異なるものの、共通するリスクは「LLMの承認・フィルタリングを経ない直接実行」により、プロンプトガードやコンテンツフィルターが介入できない点にあります。

公表情報によれば、AWSの案件はCVE-2026-18830、Googleの案件はCVE-2026-18236として追跡され、各社はパッチ提供済みです。報道ベースでは、AWSではInvokeHarness APIの最終メッセージに“ツール使用ブロック”を差し込み得たこと、Google ADKではセッション履歴の改ざんで承認偽造が可能だったことが要因として示されています。詳細は下記参考をご覧ください。

• 参考: The Hacker News（各社のパッチとCVE言及を含む報道）https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html

本稿では、個別の不具合説明に留まらず、設計原則のほころび、想定すべき脅威シナリオ、そして現場が今日から仕込める実装・検知・運用の具体策を掘り下げます。

深掘り詳細

事実整理（何が起きたか）

• 脆弱性の性質
  • モデル呼び出しを経ずに、オーケストレーターがツール実行パスに到達できる経路が存在したため、プロンプトベースの許可・NG判定やコンテンツフィルターが無力化される可能性がありました。
  • 具体的には、会話の最終メッセージやセッション履歴に混入した“ツール使用指示ブロック”や“承認済みフラグ”が、オーケストレーターの状態機械を誤誘導し、モデルの意思決定を経ない実行に繋がりました。
• 影響範囲（報道ベース）
  • AWS: Amazon Bedrock AgentCore（CVE-2026-18830）
  • Google: Agent Development Kit（CVE-2026-18236）
  • Vercel: AI SDK
• 各社対応
  • AWS/Google/Vercelともにパッチを提供済みです。ベンダーの最新版に速やかに更新する必要があります。
• 参考
  • The Hacker Newsの報道ではCVE識別子と各社の修正完了が明記されています（上掲リンク）。

インサイト（なぜ問題になるか）

• 信頼境界の誤設定
  • 多くのエージェント実装が「会話履歴＝信頼済み入力」「モデル出力＝承認トークン代替」という発想に寄りがちです。しかし、会話は外部入力の集合であり、状態管理は最も攻撃面が広い箇所です。ここを“事実源（source of truth）”にする設計は脆弱です。
• ガードレールの限界
  • プロンプト・ポリシー・コンテンツフィルターは“モデルが意思決定に関与する”前提で機能します。実行系がモデルをバイパスできるなら、どれほど精巧なプロンプトでもガード出来ません。安全性は“モデル外の制御プレーン”で担保すべきです。
• TOCTOU問題の典型
  • 「（会話に基づく）承認チェック」→「ツール実行」という2段構えで、チェック対象と実行対象を分離している限り、両者の結合を攻撃者が差し替える余地が生まれます。チェック結果を不可偽造なトークンで束ねる、ないしは実行器側が都度ポリシーに問い合わせる構造に変える必要があります。
• メトリクスの読み解き
  • 本件は新規性と現実適用性が高く、重大度評価も高水準です。一方で、各社のパッチが迅速に出ており運用上の手当は取りやすい部類です。ゆえに「パッチ適用で終了」にせず、設計と検知に投資するほどリスク低減の費用対効果が高くなります。

設計原則の再定義（防御の“ど真ん中”）

• ツール実行は“能力の貸与”であり、モデル承認ではなく“権限証明”でガードする
  • 署名付きツール呼び出し: モデル（または承認サービス）が発行するJWS/JWTに、ツールID・パラメータ・スコープ・有効期限・ノンスを含め、実行器はこのトークンがなければ実行しないようにします。
  • ケイパビリティ・トークン: 会話状態ではなく、明示的な権限トークンを最小権限・短寿命で付与します。ツール側はトークン検証に合格しない限り拒否します。
• 会話は“参考情報”、決定は“独立プレーン”
  • 会話履歴は不信任データとして扱い、承認・実行の意思決定は独立した制御プレーン（ポリシーエンジン、OPAや独自のABAC/RBAC）で行います。
• 観測可能性の設計
  • モデル呼び出しIDとツール実行IDの“不可分連結（チェーン・オブ・カストディ）”をログで保証します。連結欠落は検知で即座に隔離・遮断します。
  • 実行経路の不変条件（invariant）を定義し、違反をSLOとして監視します（例: 「ツール実行の100%が承認トークンを伴う」「トークン残存TTLが常に閾値未満」など）。

脅威シナリオと影響

以下は仮説に基づくシナリオ例です。実際の技術的詳細やバリエーションは環境依存のため、貴社のスタックで具体化して検証することを推奨します。

• シナリオ1: 外部からの会話差し替えで社内コネクタが無断実行

  • 進行イメージ（仮説）
    1. 攻撃者が公開エージェントのフロントに細工した最終メッセージ/履歴を投下
    2. オーケストレーターがモデル承認を経ずに“チケット作成”“Slack送信”“データベース読み出し”等のツールを実行
    3. 内部情報の流出や業務ワークフローの撹乱に至る
  • ATT&CK対応（例）
    • Initial Access: Exploit Public-Facing Application（T1190）
    • Execution: Exploitation for Client Execution（T1203）/Command and Scripting Interpreter（T1059, ツールがスクリプト実行型の場合）
    • Credential Access: Unsecured Credentials（T1552, ツールが環境変数等を参照する場合）
    • Exfiltration: Exfiltration to Cloud Storage（T1567）

• シナリオ2: セッション履歴改ざんで承認偽造、権限横断

  • 進行イメージ（仮説）
    1. 攻撃者が会話履歴に“承認済み”フラグやツール応答を偽装
    2. 状態機械が承認済みと誤認し高感度操作（顧客照会、見積承認）を実行
    3. 重要データの取得・操作・送信へ
  • ATT&CK対応（例）
    • Defense Evasion: Modify Authentication Process（T1556, 承認フローへの干渉の概念的対応）
    • Discovery: System/Service Discovery（T1082/T1046, 実行ツールが探索系のAPIを持つ場合）
    • Impact: Data Manipulation（T1565）

• シナリオ3: モデル未経由の“直接実行”を足掛かりに持続化

  • 進行イメージ（仮説）
    1. 不正ツール実行でWebhook/外部SaaSへトークンを送出
    2. 外部SaaS側でオートメーションを悪用し持続化、定期的なデータ引き抜き
  • ATT&CK対応（例）
    • Persistence: External Remote Services（T1133）
    • Command and Control: Web Services（T1102）

影響の質的評価

• ビジネスロジック直撃型です。実行される“ツール”が支払い、見積、在庫、顧客連絡といった業務APIであれば、被害はデータ漏えいに留まらず、業務や財務の改ざんリスクに波及します。
• マルチテナントのオーケストレーターでは、テナント境界の曖昧さが二次被害の触媒になります。テナントID/プロジェクトIDの強制検証とツール側のスコープ制限が鍵になります。

セキュリティ担当者のアクション

“今すぐ（48時間以内）”

• 在庫確認
  • Amazon Bedrock AgentCore、Google ADK、Vercel AI SDKの利用有無とバージョンを棚卸しし、全ワークスペース/環境（本番・検証）に適用範囲を広げます。
• パッチ適用と強制再デプロイ
  • 各ベンダーの最新パッチを適用し、オーケストレーターと実行ワーカーをローリング再起動します。イメージ固定（pin）環境ではベースイメージの更新漏れに注意します。
• 一時的ブロックルール
  • “モデル未経由のツール実行”を弾く暫定WAF/ゲートルールを導入します（例: ツール実行エンドポイントで承認トークンの必須化、ヘッダー/クレームの存在検査）。

“短期（1–2週間）”

• 署名付き実行の実装
  • 承認サービスが発行する短寿命JWS/JWTに、tool_id, paramsハッシュ, session_id, nonce, exp, audを含め、ツール実行時に必須化します。ツール側はissuer/audience/exp/nonce再利用の検査を実装します。
• ゼロトラスト化
  • 会話履歴は“不信任入力”とし、オーケストレーターは履歴内の“承認済み”表現を一切解釈しない方針へ。承認は常に独立した制御プレーン（OPAや専用ポリシーサービス）で評価します。
• 観測と検知
  • ログの不可分連結を整備します（model_invocation_id ↔ approval_token_id ↔ tool_run_id）。任意のツール実行がこの連結を持たない場合は即時隔離。
  • アラート設計:
    • モデル呼び出しを伴わないツール実行率のしきい値超過
    • 失敗した署名検証のバースト
    • 同一セッションにおけるトークン再利用
• 最小権限化と短寿命化
  • ツール実行に紐づくサービスアカウントの権限を最小化し、スコープと時間制約を強制します。クラウドキー/外部SaaSトークンは7–30日ローテーションを既定化します。

“中期（四半期以内）”

• セキュア・オーケストレーションの基盤整備
  • 制御プレーン/データプレーンの分離、ポリシー・アズ・コード、テナント境界強制（tenant_idのJWS署名検証とツール側検証の二重化）。
• セキュリティ・インバリアントとカナリアテスト
  • “モデル未経由実行がゼロであること”などの安全不変条件をSLO化。継続的な対向テスト（プロパティベース・フェイジング）で回帰検知します。
• レッドチーム演習（エージェント特化）
  • 会話履歴改ざん/最終メッセージ挿入/状態機械の遷移バイパスを焦点にした演習を実施し、検知と封じ込めの実効性を評価します。

運用のヒント（現場の落とし穴と対策）

• “承認済み”を文字列で表現しないこと。承認は常に暗号学的事実（署名付きトークン）として扱います。
• ログは改ざん耐性のあるストレージ（WORMやオブジェクトロック）に二重書き込みします。インシデント時に“連結の証拠”がないと、調査が空転します。
• ツール実行の“危険度”に応じたインタラクティブ承認（高リスク時のみ人間承認）を設け、全自動の誤爆を抑えます。
• 依存SDKの固定（pin）に注意。CI/CDでの“最新パッチ取り込み失敗”が定番の取りこぼしです。

参考情報

• The Hacker News: AWS、Google、Vercelがエージェントの欠陥にパッチ提供（CVEと影響の報道）https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html

本稿は公表情報を基に編集部で再構成し、実務設計の観点から示唆を加えたものです。エージェントの価値は“自律性”にありますが、自律性は“制御できること”が前提です。制御プレーンを鍛える投資は、生成AIの価値を安全に引き出す最短距離です。今、設計を見直す好機です。