AgentCore Memoryのセキュリティ：FGACによるマルチテナント制御の深層

開発現場において、AIエージェントに「ユーザーごとの記憶」を持たせるという要件は、一見すると魅力的でシンプルな機能に見えます。しかし、マルチテナント環境でこれを実装しようとした瞬間に、我々エンジニアは「データ分離」という名の巨大な壁に突き当たります。Amazon Bedrock AgentCore Memoryのデータプレーンは、SigV4による認証を前提としており、バックエンドがエンドユーザーを代行してリクエストを投げる構成では、Memory側からは「バックエンドのIAMロール」しか見えません。つまり、アプリケーションコードが正しいactorIdを渡し忘れたり、あるいは悪意あるプロンプトインジェクションによってactorIdが改ざんされたりすれば、容易に他人の記憶へアクセスできてしまうという、極めて脆弱な構造を抱えています。

公式ドキュメントが「Memory層にはユーザー間のデータ分離を強制する仕組みがない」と明記している事実は、我々エンジニアにとって無視できない警告です。これまで、このリスクを回避するためにIAMセッションタグを用いたABAC（属性ベースのアクセス制御）を駆使してきましたが、これはユーザーごとに一時クレデンシャルを管理し、STSを呼び出し、キャッシュを制御するという、極めて煩雑な実装を強いるものでした。並行処理が走るマルチテナント環境において、このクレデンシャル管理のミスは致命的なセキュリティインシデントに直結します。我々が求めていたのは、アプリケーションコードの善意に依存しない、より堅牢で透過的なアクセス制御の仕組みでした。

そこで登場したのが「AgentCore Memory connector」と「FGAC（Fine-Grained Access Control）」の組み合わせです。これは単なる機能追加ではなく、エージェントのアーキテクチャを根本から変える可能性を秘めています。Gatewayを介することで、ランタイムは不透明なBearerトークンを転送するだけで済み、IAM識別子をGateway実行ロールに収束させることが可能になります。この構成により、アプリケーション層での複雑な資格情報管理から解放され、より本質的なビジネスロジックの開発に集中できる環境が整いつつあるのです。

FGACの真価は、Gatewayに紐づけられたCedarポリシーエンジンによる「リクエスト単位の認可」にあります。Cedarはオープンソースの認可ポリシー言語であり、デフォルト拒否を原則とする堅牢な設計です。Gatewayに届いたリクエストは、inbound認証、HTTPメソッドとパスの対応付け、ポリシー評価、そしてoutbound資格情報による転送という4段階のプロセスを経て処理されます。ここで重要なのは、Cedarから見える「context」の存在です。IAMの条件キーでは参照できなかったリクエストボディのフィールドや、JWTのクレームを直接評価できるため、極めて粒度の細かい制御が可能になります。

例えば、一つのMemoryをチャットアプリと分析ツールで共有している場合、JWTのclient_idを判定して書き込み操作をチャットアプリに限定したり、レコードのmetadataに公開範囲を持たせて検索結果をフィルタリングしたりといった、IAM単体では不可能だった高度な制御が実現できます。以下に、従来のIAMセッションタグ方式と、今回導入されたGateway経由のFGAC方式の比較をまとめました。

このアーキテクチャの最大の恩恵は、ランタイムにAWS資格情報を渡す必要がなくなる点です。これにより、マルチテナントエージェントにおける「資格情報の取り違え」という、深夜の障害対応で最も避けたい悪夢のようなバグを、アーキテクチャレベルで排除できるのです。FGACは、もはやオプションではなく、エンタープライズレベルでAIエージェントを運用するための「必須のガードレール」であると私は確信しています。

ここまでAgentCore Memory connectorとFGACの有用性を解説してきましたが、技術的な解決策が提示されたからといって、我々の仕事が終わるわけではありません。むしろ、ここからが本当の戦いの始まりです。FGACによってアクセス制御が「コードの外側」に追い出されたことで、開発者は「ポリシーの管理」という新たな責務を負うことになります。Cedarポリシーの複雑性が増せば増すほど、ポリシー自体のデバッグやテスト、そしてCI/CDパイプラインへの統合が新たなボトルネックとなるでしょう。また、Gatewayを迂回するような直接アクセスをいかにして完全に遮断し、インフラレベルで「Gateway経由以外は拒否する」というゼロトラストな環境を構築できるか。これは、インフラエンジニアとアプリケーションエンジニアの境界線が曖昧になる現代において、避けては通れない課題です。

読者の皆さんに問いたいのは、「あなたのエージェントは、本当にユーザーごとのデータ分離を保証できているか？」という点です。単に「動く」ものを作る段階は終わりました。これからは、LLMが生成する不確実な出力に対して、いかにして堅牢な認可レイヤーを被せ、情報漏洩という致命的なリスクを最小化できるか。そのための実践的な処方箋として、まずは既存のIAMセッションタグ方式の複雑さを棚卸しし、Gateway経由のFGACへの移行計画を立てることを強く推奨します。また、Cedarポリシーのテストを自動化し、ポリシー変更が意図しないアクセス拒否を引き起こさないための検証環境を構築してください。技術の進化を享受するだけでなく、その進化がもたらす新たな複雑性とどう向き合い、制御していくか。そのエンジニアリングの姿勢こそが、これからのAI時代を生き抜く鍵となるのではないでしょうか。