AWS は、Amazon Bedrock AgentCore Memory にきめ細かいアクセス制御を追加し、開発者が AgentCore Gateway を通じてユーザーまたはテナントごとにエージェントのメモリを分離する管理された方法を提供します。 8 月 28 日のリリースでは、エージェント設計の機密部分がインフラストラクチャ ポリシーに移行されます。つまり、AI エージェントがセッション間で使用するメモリを誰が読み取り、書き込み、取得、または変更できるかということです。
AWS によると、この機能では OAuth JWT 認証と Cedar ポリシーが使用されます。マネージド メモリ コネクタは 12 個のメモリ操作を Cedar アクションとして公開するため、チームはアプリケーション コードだけに依存して各呼び出しの前後にレコードをフィルタリングするのではなく、メモリ操作に関するアクセス ルールを表現できます。
これは小さな承認の更新のように聞こえるかもしれません。そうではない。永続メモリは、単純なチャット インターフェイスと長期間実行されるエージェント製品の主な違いの 1 つです。エージェントがユーザー設定、アカウントのコンテキスト、プロジェクト履歴、以前の決定、サポートケース、またはビジネスプロセスの状態を記憶すると、記憶がセキュリティ境界となります。 AWS は現在、そのように扱っています。
変更点
Amazon Bedrock AgentCore Memory は、AWS のエージェント インフラストラクチャ スタックの一部です。これは、すべてのアプリケーション チームが独自のメモリ層を最初から構築することを強制するのではなく、エージェントがインタラクション全体でコンテキストを保存および取得できるように設計されています。
新しいアクセス制御機能により、ビルダーは AgentCore Gateway を通じてユーザーごとおよびテナントごとの分離を強制できます。 AWS によると、この機能は OAuth JWT 認証と、他の AWS 認証システムでも使用されているポリシー言語である Cedar で動作します。 AgentCore のドキュメントでは、AgentCore のポリシーがゲートウェイ ツールへのアクセスを制御するための Cedar ベースのメカニズムとして説明されています。
実際の変化は、メモリ認証がゲートウェイおよびツール層の近くに配置できるようになるということです。チームは、アプリケーション内のすべてのメモリ呼び出しに関するカスタム チェックを記述する代わりに、どの呼び出し元がどの名前空間またはテナント コンテキストでどのメモリ アクションを実行できるかを管理するポリシーを定義できます。
マルチテナント ソフトウェアの場合、これは意味のあるアーキテクチャ変更です。法律事務所、代理店、サポート チーム、または企業部門の AI アシスタントは、同じエージェント コードを通じて多くのユーザーにサービスを提供する場合があります。危険な故障モードは、モデルが間違った答えを与えることだけではありません。それは、あるテナントのメモリが別のテナントのセッションに取得されるか、エージェントが機密状態を間違ったスコープに書き込むことです。きめ細かいポリシーの適用は、この種のエラーを減らすことを目的としています。
メモリ分離が今重要な理由
エージェント メモリは、AI プラットフォームに新たな永続性の問題を引き起こします。プロンプト ログ、取得したドキュメント、ツールの出力、ユーザー設定、ワークフローの状態はすべて、将来の推論の一部となる可能性があります。これによりメモリは便利になりますが、データ境界について推論することが難しくなります。
従来の API 承認は通常、リクエストに焦点を当てます。つまり、この呼び出し元は今このリソースにアクセスできますか?エージェントの記憶は、質問を時間を超えて拡張します。 1 つのセッション中に保存されたレコードは、数週間後に別のツールの呼び出し、別のモデル、または別のバージョンのエージェントによって取得される場合があります。プラットフォームがこれらのメモリ操作に ID および認証コンテキストを伝達しない場合、メモリ層がユーザー間漏洩の静かなソースになる可能性があります。
AWS による Cedar の使用も、エージェント システムのインフラストラクチャとしてのポリシーを指しているため、重要です。エージェント ビルダーは、ツール、メモリ、実行環境、API キー、監査ログをカバーする制御をますます必要としています。これらのコントロールをゲートウェイ層に配置すると、アプリケーション チームがさまざまなモデルやエージェント フレームワークを試しているときでも、プラットフォーム チームに一貫してポリシーを適用する場所が与えられます。
これは AI API ゲートウェイの設計に直接関係します。プロンプトをモデルにルーティングするだけのゲートウェイは、本格的なエージェントの展開にはもはや十分ではありません。コントロール プレーンは、ID、テナント、ツール、メモリ スコープ、レート制限、監査証跡を理解する必要があります。 Model Gate と同様のプラットフォームは同じ進行方向を向いています。ユニファイド アクセスは、強制可能な境界がある場合にのみ役立ちます。
誰が影響を受けるか
当面の対象者は、Bedrock AgentCore でエージェントを構築している AWS の顧客、特に SaaS 製品、社内のエンタープライズ アシスタント、カスタマー サポートの自動化、リサーチ エージェント、パートナー向けワークフローに取り組んでいるチームです。共有インフラストラクチャから複数の組織またはチームにサービスを提供する製品はすべて、同じ質問に答える必要があります。「エージェントはどのメモリの使用が許可されているかをどのようにして知るのでしょうか?」
開発者は、アプリケーション コードを通じて認可ロジックを分散させるのではなく、管理されたポリシー チェックに依存できるため、メリットが得られる可能性があります。慎重な設計の必要性がなくなるわけではありませんが、間違いによって間違ったデータが公開される可能性のある場所の数を減らすことができます。
セキュリティ チームとプラットフォーム チームも影響を受けます。エージェントのメモリは、データベース、ドキュメント インデックス、またはシークレット ストアと同様に検討する必要があります。アクセス モデルは明示的である必要があります。監査証跡には、どの ID がどのメモリ操作にアクセスしたかが示される必要があります。テナントの分離は、アプリケーション ルーティングから推測するのではなく、直接テストする必要があります。
エージェント システムを購入または構築する企業にとって、このリリースはベンダーに関する質問の基準を引き上げます。もはや、アシスタントに記憶があるかどうかを尋ねるだけでは十分ではありません。購入者は、メモリがどのように分割されるか、認可がモデルの外部で強制されるかどうか、ポリシーがどのように更新されるか、メモリ アクセスがログにどのように表示されるかを尋ねる必要があります。
ビルダーにとっての実際的な影響
最も明らかな影響は、アーキテクチャです。有効期間の長いエージェントを構築するチームは、モデル機能のルーティングを実行およびメモリのアクセス許可から分離する必要があります。強力なモデルではタスクを推論することができますが、すべてのツール呼び出しやメモリ ルックアップが広範なアクセスを継承する必要があるという意味ではありません。
第 2 に、ゲートウェイとエージェント プラットフォームはメモリ操作をファーストクラスのイベントとして扱う必要があります。読み取り、書き込み、検索、削除、更新にはすべて異なるリスク プロファイルがあります。使用状況分析はトークン数で停止すべきではありません。エージェントのワークロードの場合、分析ではツールの使用状況、メモリ アクセス、テナントの範囲、ユーザー ID、ポリシーの結果を表示する必要がますます高まっています。
第 3 に、マルチテナント製品では、データ分離を強制するためのプロンプト指示に依存することを避ける必要があります。モデルには、別の顧客のコンテキストを取得しないように指示できますが、永続的な分離をモデルの下で強制する必要があります。これは、範囲指定された資格情報、ゲートウェイ ポリシー、名前空間の設計、およびテナント間アクセスが失敗することを証明するテストを意味します。
最後に、パートナーとリセラーのプラットフォームは注意を払う必要があります。代理店向けの AI API またはパートナー API 自動化レイヤーにより、下流の顧客がエージェントを構築できる場合、メモリ ガバナンスは製品契約の一部になります。プラットフォームは、クライアント間に目に見えないデータ共有パスを作成させずに、有用な自動化を作成できる十分な柔軟性をパートナーに提供する必要があります。
まだ不確実なこと
AWS は、制御モデルと、OAuth JWT、Cedar ポリシー、AgentCore Gateway、およびマネージド メモリ操作の使用について説明しました。公開発表ではまだ明らかになっていないのは、複雑な運用環境でチームがこれらのポリシーをどのように設計するか、ポリシーのデバッグがどれほど簡単になるか、デフォルトで顧客がどの程度の運用詳細をログに取得できるかという点です。
しかし、より広い方向性は明らかです。エージェントのメモリはインフラストラクチャになりつつあります。そうなると、認可、可観測性、課金がゲートウェイ層に続く必要があります。信頼できるエージェント プラットフォームを構築する企業は、モデルへのアクセス、ツールの権限、メモリの状態を 1 か所で可視化して管理できる企業になります。