JA EN
shiichan

Amazon Bedrock AgentCore Memory、ユーザーごとの壁を自前コードなしで作れるって知ってた？

AWS What's New ★★★★ Markdown で見る
#aws#ai#security

おつかれさま、しぃちゃんだよ！今日は AI エージェントのメモリまわりのセキュリティ機能で、テンション上がる発表を見つけちゃった。マルチテナントのエージェントを作ってる人にはかなり刺さる話だと思うから、一緒に見ていこうね！

AWS What's New aws.amazon.com

なにが発表されたの？

AWS What's New によると、Amazon Bedrock AgentCore Memory が「fine-grained access control(FGAC)」に対応したよ。AgentCore Gateway を経由することで、ユーザーごと・テナントごとのメモリの隔離を、独自の認可ロジックを書かずに実現できるようになったの。

具体的には、Memory リソースの手前に OAuth(JWT) 認証で構成した AgentCore Gateway を置いて、そこに Cedar ポリシーをアタッチする仕組み。認証された呼び出し元のアイデンティティに基づいてアクセスを制限できるようになるよ。

今までどうだったの？

AgentCore Memory には元々、IAM の ID ベースポリシーやリソースベースポリシーを使って、アクション・リソース・actor / session / namespace のスコープで制御する仕組みがあったの。でもこれは「呼び出す IAM プリンシパルが誰か」を見る仕組みだから、OAuth や JWT で認証したエンドユーザーの ID を条件にすることはできなかったんだよね。

つまり、エージェントのバックエンドがエンドユーザーの JWT を受け取って Memory を呼び出すような構成——たとえば OpenID Connect でログインするタイプのエージェントアプリ——では、「このユーザーは自分の actorId のデータしか読めない」といったチェックを、アプリ側のコードで自前で書くしかなかったの。

これで何が変わるの？

FGAC を使うと、この認可ロジックをインフラ層(Gateway)に移せるようになるよ。具体的にはこんなことができるようになるの。

  • 呼び出し元の JWT の sub クレームと、リクエストの actorId が一致する場合だけ許可する(自分のデータしか触れない)
  • ユーザーのトークンクレームから導かれるネームスペースだけにメモリレコードのアクセスを制限する
  • 呼び出し元(OAuth の client_id など)ごとに、許可する Memory 操作を個別に絞る

つまり「暗号学的に証明されたアイデンティティ」を根拠に、アプリのコードを一切信用せずにアクセス制御ができるってこと。マルチテナントの SaaS 型エージェントを作ってる人にとっては、認可漏れのリスクを減らせる大きい話だと思うな。

深く潜ってみよう

FGAC は「AgentCore Memory connector」という仕組みの上に構築されてるよ。これは Gateway のターゲットを Memory のデータプレーンに接続するマネージドコネクタで、12 個の Memory 操作を Cedar のアクションとして公開してるの。対応してる操作はこれだよ。

  • ListEvents
  • CreateEvent
  • GetEvent
  • DeleteEvent
  • ListSessions
  • ListActors
  • RetrieveMemoryRecords
  • ListMemoryRecords
  • GetMemoryRecord
  • DeleteMemoryRecord
  • ListMemoryExtractionJobs
  • StartMemoryExtractionJob

各操作は {ターゲット名}___{HTTPメソッド}:{URIテンプレート} という形式の Cedar アクション ID になっていて、ポリシーはこのアクションと、パスパラメータ(memoryId / actorId / sessionId / eventId / memoryRecordId)やリクエストボディのフィールド(namespace / namespacePath / metadata / filter / payload など)を条件にできるの。評価はデフォルト拒否で、forbid が permit より優先されるよ。

たとえば「自分の actorId のイベントしか見れない」を強制する条件はこんな感じで書けるみたい。

context.input.actorId == principal.getTag("sub")

セットアップは Gateway にポリシーエンジンを作って Cedar ポリシーを追加し、Gateway の policyEngineConfiguration に紐づける流れ(コンソール・SDK・CLI どれでも設定可能)。ポリシーエンジンには ENFORCE(強制)と LOG_ONLY(ログのみ・ブロックしない)の 2 つのモードがあって、まず LOG_ONLY で評価結果を確認してから ENFORCE に切り替えるのが推奨されてるよ。意図しない拒否を防げるからね。

ただし注意点もあるの。BatchCreateMemoryRecords / BatchUpdateMemoryRecords / BatchDeleteMemoryRecords の 3 つのバッチ操作は Cedar アクションとして公開されてないから、FGAC の対象外なの。1 リクエストに複数レコードが乗る形式だから、レコード単位・ネームスペース単位の条件を適用できないんだって。これらは引き続き IAM のポリシーで操作全体を許可/拒否する形になるよ(全部やるか全部やらないか、の粒度)。

もう既存の Memory を使っていて actorId が JWT の sub と一致しない場合のために、移行パターンも用意されてるよ。

  • IdP が発行できるカスタムクレーム(内部ユーザー ID を持つもの)と比較する
  • actorId の代わりにネームスペースで隔離する(ネームスペースのパスをクレームに持たせて比較する)
  • 新規のイベント・レコードから actorId を sub に揃えていく(過去データは移行期間を設ける)

まとめ

  • Amazon Bedrock AgentCore Memory に「fine-grained access control(FGAC)」が追加され、ユーザー / テナントごとのメモリ隔離を自前コードなしで実現できるようになったよ
  • OAuth(JWT) で認証した Gateway に Cedar ポリシーをアタッチして、actorId や namespace を JWT のクレームと比較する形で制御するよ
  • 12 個の Memory 操作が Cedar アクションとして公開されていて、ENFORCE / LOG_ONLY の 2 モードで安全に導入できるよ
  • バッチ操作 3 種は FGAC の対象外で、引き続き IAM ポリシーでの制御になるよ
  • マルチテナントのエージェントアプリを作っていて、認可ロジックをアプリコードから切り離したい人にはうれしいアップデートだね

関連記事