AWS Bedrock のロゴ

AWS Bedrock / 公式ブログ / 2026/06/01 / 重要

Amazon Bedrock AgentCore Identity、既存のSecrets Manager シークレット参照に対応

AIセキュリティ

公式ブログ原文

AWS は 2026年6月1日、Amazon Bedrock AgentCore Identityで、利用者が用意したAWS Secrets Managerのシークレットを参照できるようになったと発表しました。エージェントが外部APIへアクセスするための認証情報を、既存のシークレット管理ルールに合わせて扱いやすくする更新です。

要点

  • AgentCore Identityの認証情報 プロバイダー リソースで、既存のAWS Secrets Manager シークレットを参照できるようになりました。
  • API keyとOAuth client シークレットの両方で、Secrets Manager ARNとJSON keyを指定する流れが説明されています。
  • 暗号化、ローテーション、レプリケーション、タグ、リソースポリシーを、利用者側のSecrets Manager運用に合わせて管理できます。
  • 同一リージョン内であれば別AWSアカウントのシークレット参照も可能ですが、クロスリージョンのシークレット共有はサポートされません。
  • AgentCore Identityがシークレットを読むには、secretsmanager:GetSecretValue と、必要に応じてKMSの kms:Decrypt 権限をサービスプリンシパルへ与える必要があります。

今回のブログ記事で語られていること

AIエージェントは、CRM、Slack、GitHub、社内APIなど外部ツールを呼び出すほど価値が出ます。ただし、そのたびにAPI keyやOAuth client シークレットの扱いが問題になります。認証情報をコード、プロンプト、環境変数、手作業の設定に散らすと、漏えい、ローテーション漏れ、監査不備が起きやすくなります。AgentCore Identityは認証情報 プロバイダーとトークン vaultで外部認証を管理しますが、これまではAgentCore IdentityがSecrets Manager上のシークレットを作成・管理する形が中心で、利用者が既存のシークレット管理ルールをそのまま当てはめにくい場面がありました。

今回の更新では、既に作成済みのSecrets Manager シークレットをAgentCore Identityの認証情報 プロバイダー リソースから参照できます。これにより、企業が既に持っている暗号化設定、ローテーションポリシー、タグ付け、リソースポリシー、監査ルールを、エージェントのOutbound Authにも適用しやすくなります。たとえば、顧客管理APIのAPI keyを既存のシークレットとして管理しているチームは、そのARNとJSON keyを指定してAgentCore Identityに渡せます。ローテーション後も、AgentCore Identityは次回読み取り時に更新後の値を取得するため、認証情報 プロバイダーを再作成しなくて済むと説明されています。

この更新は、規制産業や大規模組織では特に意味があります。すべてのシークレットに顧客 マネージド KMS keyを使う、タグでコスト配賦やコンプライアンスを管理する、特定のIAM principalだけにシークレット参照を許可する、といった既存のセキュリティ統制を、エージェント基盤にも広げられるためです。外部APIを使うエージェントでは、モデルの安全性だけでなく、どの資格情報でどの外部サービスを呼ぶのかが重要です。既存のSecrets Manager運用に寄せられることで、AIエージェントだけが例外的な認証情報管理になるリスクを下げられます。

一方で、設定しただけで安全になるわけではありません。AgentCore Identityがシークレットを取得するには、対象シークレットのリソースポリシーでサービスプリンシパルに secretsmanager:GetSecretValue を許可する必要があります。顧客 マネージド KMS keyで暗号化している場合は、kms:Decrypt も必要です。また、別アカウントのシークレットを参照する場合でも同一リージョンに限られます。クロスアカウント、KMS、リソース ポリシー、SCP/RCPが絡む環境では、小さな検証環境で権限経路を確認してから本番に入れるべきです。

今回のブログ記事が関係する人

AgentCore Identity を使って外部サービスの認証情報を扱う開発者、プラットフォーム担当、セキュリティ担当に関係します。エージェントがどのシークレットへアクセスできるかを設計する立場の人ほど、便利さよりも権限境界と監査を重視して読むべき内容です。

実務で確認したいポイント

  • AgentCore Identityに渡すシークレットを、API key用とOAuth client シークレット用で分け、JSON key名を明確にする。
  • シークレットのリソース ポリシーで、AgentCore Identityのサービスプリンシパルに必要最小限の secretsmanager:GetSecretValue を付与する。
  • 顧客 マネージド KMS keyを使う場合、kms:Decrypt の権限経路を確認する。
  • ローテーション後にエージェントが新しい値を取得できるか、認証情報 プロバイダーを再作成せずに検証する。
  • クロスアカウント利用では同一リージョン制約、タグ、監査ログ、SCP/RCPとの整合性を確認する。

結局、今回のブログ記事をどう読むべきか

AgentCore IdentityのSecrets Manager参照対応は、エージェントの外部API接続を企業のシークレット管理に乗せるための重要な更新です。AIエージェントはツールを呼べるほど便利になりますが、同時に資格情報の扱いが本番運用の弱点になりやすい領域です。既存の暗号化、ローテーション、タグ、リソースポリシーを使えるようになったことで、AgentCoreをセキュリティ運用に合わせやすくなります。