StrandsのA2Aサーバーで会話履歴が混在｜SDK更新と利用者分離を確認

複数の利用者へAIエージェントを提供している場合、ログインを要求するだけでは会話履歴の混在を防げないことがあります。AWSはStrands Agents SDKのA2Aサーバーについて、認証済み利用者が別の利用者の履歴を参照したり、モデルの応答へ影響したりできる脆弱性CVE-2026-115419を公表しました。

優先するのは、共有しているA2Aサーバーの有無を調べ、対象SDKを更新することです。さらに、修正後も会話を識別するcontext_idだけに認可を任せない確認が必要です。会話状態を分ける処理と、その会話へ誰が接続できるかを決める処理は、それぞれ点検します。

本稿は2026年10月25日にAWS：Strands A2Aサーバーの脆弱性告知 2026-146-AWSと開発元の資料を確認した記事です。AWSの公表時刻は10月22日13時PDT、日本時間では10月23日5時です。25日に新たな悪用が判明したという意味ではありません。以下の確認手順と業務例は本サイトの提案であり、実環境で攻撃や動作検証を実施した結果ではありません。

対象はA2Aサーバーを複数の利用者へ提供する構成

Strands AgentsはPythonとTypeScriptで利用できるAIエージェント開発用SDKです。A2Aのサーバー機能は、エージェントをHTTP経由で別のエージェントやクライアントから呼び出せるようにします。Webアプリの問い合わせ窓口、社内支援、業務自動化などからこのサーバーへ接続する構成では、Webのログイン情報と会話状態の両方が関係します。

今回の問題は、異なるcontext_idの呼び出し元の間でも、条件によって会話履歴が共有されることです。単にモデルが似た回答を返すという品質の問題ではありません。他の会話から情報を読む機密性の問題と、他の呼び出し元のモデル動作へ影響する完全性の問題として扱います。

Strands開発元：GHSA-4v6f-7vjh-6x4mではCVSS v3.1が8.1、Highです。説明されている攻撃者は認証済みの遠隔利用者であり、認証不要のRCEという話ではありません。公表資料は複数の利用者またはテナントが到達できるA2Aサーバーを対象にしています。SDKを依存関係へ入れているだけで、すべてのアプリに同じ攻撃経路があると決め付けないでください。

PythonとTypeScriptの修正境界を別々に確認する

Pythonではmultiagent.a2aモジュールを含むstrands-agentsの1.43.0未満、TypeScriptでは@strands-agents/sdkの1.5.0未満が告知の対象です。修正境界はそれぞれ1.43.0と1.5.0です。AWSと開発元は最新版への更新に加え、フォークや派生コードへも修正を取り込むよう案内しています。

本サイトでは、最初にHTTPの公開経路からサーバーの実体までを対応付けることを勧めます。ロードバランサーの配下にあるサービス、コンテナ、起動コマンド、読み込まれるパッケージ、独自のA2Aアダプターを調べます。Python側だけを直して、同じ業務で使うTypeScript側を見落とさないよう、言語別に担当を決めます。

確認するのは開発端末の最新版表示だけではありません。固定された依存関係、ビルド成果物、実行中の全レプリカを照合します。古いイメージから増設する設定や、停止中の予備系が残る場合も対象です。これは今回のSDK修正を本番へ届けるための確認で、AWSのマネージドサービスが自動で利用者のアプリを更新するという告知ではありません。

更新前はユーザーまたはテナントごとにサーバーを分ける

提供元は、影響版の問題を完全に解決する回避策はないと説明しています。更新までの間は、一つのA2Aサーバーを複数のユーザーやテナントへ公開せず、複数の呼び出し元に対応する必要があるなら、ユーザーまたはテナントごとに別のサーバーインスタンスを実行するよう案内しています。

ここで「社内限定だから一つでよい」と置き換えないことが大切です。同じ会社の中でも、顧客対応、人事、経理では閲覧してよい会話が異なります。一つのテナント内に異なる権限の利用者がいる場合は、誰を同じ信頼境界として扱えるかを確認し、必要ならユーザー単位まで分ける判断をします。

また、入口だけを別URLにしても、背後で同じA2Aサーバーへ流していれば、提供元が示す別インスタンスの対策と同じとは言えません。本サイトの提案として、ルーティング先と起動されたプロセスを確認し、独自に追加した履歴保存先も境界を共有していないか点検します。分離の確認が難しい場合は、共有提供の一時停止を含めて判断してください。

修正された会話分離と認可を混同しない

修正では、A2Aのcontext_idごとに会話状態が分離されます。Strands公式：A2Aの会話分離と認証の境界は、会話ごとに専用のエージェントを返すagent_factory方式を推奨しています。一方、同じ資料は、このIDがクライアントから渡される値であり、認証の境界ではないと明記しています。

別の利用者のIDを知る呼び出し元が、その会話へ接続できる点に注意が必要です。更新によって異なる会話の状態が混ざる問題を修正しても、他人の会話IDをそのまま受理してよいことにはなりません。IDの形式がランダムで推測しにくいことと、その利用者に会話の利用権限があることは別の条件です。

本サイトの提案は、認証済みの利用者または所属と会話の所有関係を、サーバー側で照合することです。新規会話だけでなく、継続要求でも同じ関係を確認します。クライアントが送った組織名やモデルが生成した会話IDを、本人確認の代わりに使わないでください。検査をゲートウェイへ置く場合も、内部から直接到達する経路が検査を迂回しないか確認します。

Strands公式：A2Aサーバーの構成には認証に関係する構成項目がありますが、項目が存在するだけで自社の認可が完成するわけではありません。誰の身元を確定し、どの会話への接続を許可し、拒否時にどこで処理を止めるかを、実際の配備構成で説明できる状態にします。入口の認証に成功したことだけを更新後の合格条件にしないことが要点です。

履歴保存を共有していないかも点検する

Strands公式：Python A2A Executorの仕様では、会話ごとのagent_factoryで必要なsession_managerを構成する方法が示されています。単一のエージェントを共有する方式は非推奨で、そこでセッションマネージャーを組み合わせると、複数の会話を一つの保存セッションへ混在させるため、受け付けないと説明しています。

自社で保存処理を差し替えている場合、SDKの版だけではその独自処理の安全性を確認できません。本サイトでは、保存キーが会話と利用者の境界に対応しているか、復元時に所有者を検査するか、共通の既定値へ戻る処理がないかを確認することを提案します。画面上の会話一覧が別れていても、モデルへ戻す履歴が共通なら問題は残ります。

更新前の会話を継続利用する場合も、既に保存した履歴まで自動で正しく分割されたと仮定しません。今回の告知は、自社の過去データを修復できた証明にはなりません。履歴の由来を確認できないものは、調査用にアクセスを制限して保全し、新しい会話へ無条件に読み戻さない扱いを検討します。削除や初期化の前に、調査と業務継続の責任者を決めてください。

回答の印象ではなく会話の境界を検証する

次は、許可された検証環境で行う確認例です。利用者AとBを用意し、それぞれの会話へ異なる無害な識別文字列を渡します。別の会話IDを使う通常の往復に加え、交互の要求と並行要求で、相手の履歴がモデル入力や応答へ入らないかを照合します。本稿でこの試験を実施したわけではなく、漏えいを再現する攻撃コードでもありません。

もう一つの確認は、BがAの会話IDを指定した場合に、モデルを呼び出す前に拒否されることです。前者は会話状態の分離、後者は会話の所有者に対する認可を調べます。モデルが「教えられません」と返すだけでは、権限外の履歴を既に受け取った可能性を区別できません。入口の判定とモデルへ渡した履歴の由来を見ます。

ログへは認証主体、所属、会話ID、処理先の実体、拒否または許可の結果など、調査に必要な対応関係を残します。実際の機密会話を丸ごと検証ログへ複製する必要はありません。応答の文面だけで判断すると、たまたま出力されなかった情報や、別セッションへ渡った状態を見逃すため、記録の閲覧権限も含めて点検します。

侵害調査と更新完了を別々に記録する

今回確認した提供元の告知は、特定の利用環境で実際に悪用されたことを報告するものではありません。脆弱性の存在と、自社で漏えいが起きた事実を分けます。一方、対象版で複数利用者へ公開していた場合は、更新だけで過去の影響確認を終了しないことを本サイトでは勧めます。

公開期間、利用者の範囲、会話IDと認証主体の対応、問い合わせや回答への混入の申告を調べます。記録が足りない場合、漏えいなしと断定する材料にはできません。モデルの挙動へ影響できるという告知から、すべての接続ツールが不正実行されたと広げず、実際に起きた操作と権限を記録で確認してください。

完了条件は、全実行系への修正版の反映、共有提供の暫定制限の解消、異なる会話の分離、他人の会話IDの拒否、独自の履歴保存経路の確認がそろうことです。更新の作業記録と、過去の影響調査の記録を分けると、「修正版になった」ことを「漏えいしなかった」証明と取り違えずに管理できます。

関連記事

会話へ取り込む文書の境界は、RAGで利用者の権限を引き継いで情報漏えいを防ぐ設計でも扱っています。同記事は検索対象の認可を説明する恒久対策であり、今回のA2Aサーバー固有の修正は本稿の提供元告知を基準にしてください。文書検索が正しくても、会話履歴の混在は別に確認する必要があります。