AIエージェントから社内ツールを呼び出したくても、接続先がBasic認証しか受け付けない。そんなレガシー境界では、ツール連携を先に進めるために、認証方式をどこかで変換する必要があります。

2026年8月18日に公開されたAWS Security Blogの記事は、Amazon Bedrock AgentCore GatewayのRequest Lambda interceptorをその変換点にする実装を示しました。ポイントは、ユーザー名とパスワードをエージェントへ渡さず、決定的に動くLambdaだけに扱わせることです。

ただし、Basic認証の弱点まで消えるわけではありません。どこが安全側に変わり、どこに運用負債が残るのかを、リクエストの流れから整理します。

BearerからBasicへの変換で、資格情報をモデルの外に置ける理由

AgentCore GatewayのREQUEST interceptorは、ターゲットを呼び出す前にLambdaを実行し、検証や認可、リクエスト変換を差し込める仕組みです。公式ドキュメントでは、Gatewayの各呼び出しでカスタムコードを実行できると説明されています。

今回の構成では、認証の流れを次のように分けます。

Agent -- Bearer JWT --> AgentCore Gateway
                         |
                         +--> REQUEST interceptor
                              1. JWTを再検証
                              2. Secrets Managerからサービスアカウントを取得
                              3. AuthorizationをBasicへ置換
                         |
                         +-- Basic credential --> Legacy tool

Gatewayが受信時のJWTを検証した後、interceptorも署名、有効期限、発行者を再検証します。続いてSecrets Managerからシステム用サービスアカウントを取得し、username:passwordをBase64エンコードしてAuthorization: Basic ...を組み立てます。AWSが公開したサンプルリポジトリでは、Amazon Cognito、PyJWT、Secrets Manager、KMSを組み合わせた一連の構成を確認できます。

interceptorが返したAuthorizationヘッダーはターゲットへ自動転送され、クライアントやcredential providerが用意した同名ヘッダーより優先されます。この動作はAgentCore Gatewayのヘッダー伝播仕様に明記されています。つまり、ツールのスキーマやエージェント側の実装をBasic認証向けに変えず、Gateway境界でだけ認証方式を置き換えられるわけです。

大きな意味を持つのは、エージェントの実行ロールにSecrets Managerへの権限を与えない点です。資格情報を取得できるのはinterceptor Lambdaだけなので、モデルがプロンプトから直接シークレットを読み出す経路を設計上分離できます。ただし、これはプロンプトインジェクション全体を防ぐ保証ではなく、認証情報への直接アクセスを隔離する対策です。

passRequestHeadersを有効にすると、Lambdaが新しい認証境界になる

このパターンでは、interceptorが受信JWTを読むためにpassRequestHeaders: trueが必要です。既定値はfalseであり、有効にすると認証トークンを含むリクエストヘッダーがLambdaへ渡ります。interceptorのセキュリティ指針も、機密ヘッダーをログへ出さないよう求めています。

したがって、Lambdaを単なる文字列変換処理として扱うのは危険です。実装と運用では、少なくとも次の境界を揃える必要があります。

• Gatewayの実行ロールは、使用するinterceptor Lambdaだけを呼び出せるようにする
• interceptorの実行ロールは、対象のsecret ARNに対するsecretsmanager:GetSecretValueと、使用するKMSキーに対するkms:Decryptへ絞る
• Authorizationを含むイベント、例外、デバッグ出力をログへ残さない
• JWT検証に失敗した場合は、資格情報を取得せず401相当で終了する
• 同じ入力で結果が変わらない処理にする

最後の項目は見落としやすいところです。Gatewayは失敗やタイムアウト時にinterceptor Lambdaを再試行する可能性があるため、公式ドキュメントは冪等な実装を推奨しています。今回のように検証、secret取得、ヘッダー生成だけを行うステートレスな処理は、この条件と相性が良いですね。

Base64のBasic認証には、TLSと資格情報ローテーションが残る

Basic認証は暗号化方式ではありません。RFC 7617は、ユーザーIDとパスワードの組をBase64で符号化する方式として定義し、TLSなどの外部保護なしでは安全な認証方法とみなせないとしています。interceptorでヘッダーを生成しても、Gatewayから下流ツールまでTLSで保護する必要があります。

もう一つ残るのが、長期資格情報のライフサイクルです。一次ソースのActive Directory例では、管理者がサービスアカウントを作り、初期パスワードをSecrets Managerへ一度登録します。その直後にローテーションして人が知る初期値を退役させ、以後はSecrets Manager側とAD側を同期して更新する構成です。

Secrets Managerのローテーション仕様でも、ローテーションはsecretだけでなく、その資格情報を使うデータベースやサービス側も更新する処理だと分かります。どちらか片方だけが更新されると認証に失敗するため、ローテーション成否、同期ずれ、401応答を同じ運用単位で監視したいところです。interceptor内でsecretをキャッシュする場合は、ローテーション後の値をいつ再取得するかも決めておく必要があります。

この構成で下流へ送るのは、個々の利用者の資格情報ではなくシステム用サービスアカウントです。そのため、レガシーツール側が見る主体は基本的にそのアカウントになります。ユーザー単位の認可や監査が必要なら、受信JWTのclaimでinterceptor側の許可を判断し、誰のどのツール呼び出しだったかを秘密情報なしで追跡できる設計を別途用意する必要があります。

OAuthやIAMを使えるターゲットでは、組み込み認証を先に選ぶ

AgentCore Gatewayの現在のアウトバウンド認証ドキュメントには、IAM、caller IAM credentials、OAuth、token passthrough、API keyなどが掲載されています。使える方式はMCP server、OpenAPI schema、Lambda functionなど、ターゲットの種類によって異なります。

接続先がこれらの方式へ対応できるなら、まず組み込み認証を選ぶ方が自然です。特にOAuthやIAMへ移行できれば、Basic認証用パスワードを生成し、保管し、下流のIDストアと同期する仕事そのものを減らせます。Request Lambda interceptorが必要になるのは、下流ツールをすぐ変更できず、AgentCore導入と認証基盤の刷新を別のタイムラインで進めたい場合です。

判断は次の順序にするとぶれにくくなります。

1. ターゲット種別で利用できる組み込み認証を確認する
2. 下流ツールがOAuth、IAM、API keyなどへ移行できる時期を確認する
3. それまでBasic認証が必要なら、interceptorを期限付きの橋として設計する
4. TLS、最小権限、ログ抑制、ローテーション、認可、監査を受け入れ条件にする
5. 下流の認証刷新が完了したら、Basic変換とサービスアカウントを撤去する

AWS Secrets Managerのベストプラクティスが示す最小権限も、3番と4番を分けないための基準になります。secretを安全な保管場所へ移しただけで終わらせず、「誰が読めるか」まで狭めて初めて隔離が成立します。

Request Lambda interceptorは、認証刷新までの橋として使う

冒頭の問いへの答えは明確です。レガシーツールがBasic認証しか受け付けなくても、Request Lambda interceptorを境界に置けば、資格情報をエージェントへ渡さずにツール呼び出しをつなげます。

一方で、Basic認証はBasic認証のままです。TLS、ヘッダーログの抑制、Lambdaとsecretの最小権限、資格情報の同期ローテーション、サービスアカウント粒度の監査という負担は残ります。

だからこそ、この構成は完成形ではなく移行用の橋として扱うのが実務的です。導入時に撤去条件まで決めておけば、AgentCore活用を先に進めながら、下流ツールのOAuthやIAM対応も止めずに進められます。

出典

• Title: Implement custom authentication for tools integration using request Lambda interceptor in AgentCore Gateway
• URL: https://aws.amazon.com/blogs/security/implement-custom-authentication-for-tools-integration-using-request-lambda-interceptor-in-agentcore-gateway/