AgentCore Gatewayで検証済みトークンから利用者情報を注入します。Managed Knowledge BaseのACLとCedarの方針を重ねて照合します。 共有Agentの検索で、別部署や別顧客の資料が混ざるリスクを扱います。ACLへ渡す利用者情報の信頼性と、Gatewayを迂回する経路が焦点です。 検索の本人情報をモデルの引数から切り離す AWSは11月12日、Amazon Bedrock Managed Knowledge Baseの検索権限を細かく制御する構成を紹介しました。複数部署が同じAgentを使う例です。通常のアプリでは認証済み利用者に合わせて検索しますが、Agentがツール引数を作ると、誰として検索するかまでモデルが選べる場合があります。誤った出力やプロンプト注入で別の利用者が指定される可能性があります。解説は、利用者の身元をLLMに決めさせないことを設計原則としました。MCPツールとして検索を公開する場合も、信頼するコードと認証基盤の結果を使って検索範囲を設定します。 トークンと検索結果を複数の層で結び付ける 利用者はCognitoで認証し、Gatewayがトークンを検証します。要求を処理するLambdaが検証済みのメール情報を読み、ツール引数のuserContextを上書きします。さらにAgentCoreのPolicyがCedarの規則で本人情報との一致を確認し、Knowledge Base側はACLに基づく文書だけを返します。資源に付ける方針では、検索をGatewayの実行ロールへ限定します。この構成は部門間だけでなく、複数顧客で同じ基盤を共有する場合にも関係します。重要なのは、ACLが受け取る本人情報そのものを認証する機能ではない点です。元の引数を信用したままACLを付けても、利用者のなりすましを防げるとは限りません。引数を書き換える層と検索を絞る層を対応させ、別の経路から直接呼べる権限も確認します。 拒否されるべき検索を運用の評価へ入れる 導入時は、許可した資料を取得できるかと同じくらい、取得できない資料を確かめることが論点です。部署や顧客を取り違えた引数、利用者情報がない要求、Gateway以外からの検索を検証する必要があると見られます。トークンの署名が正しくても、必要な属性の意味や更新時期まで自動で保証されるわけではありません。人事異動や退職に伴う権限の反映も確認対象になります。追加のLambdaと方針管理には保守負担が伴う可能性があります。ログに検索語や個人情報を残す範囲も設計します。原文は架空企業の構成例であり、すべての社内文書へ同じ設定を適用できる保証ではありません。実際の認証と文書の権限が一致することを確かめてから、共有範囲を広げる判断になります。利用者属性の更新と文書側の権限更新に時間差がある場合も、期待する拒否が働くかを見ます。認証の成功だけを検索の安全性の指標にしない運用が必要になります。