AgentCore Identity in Amazon Bedrock can now reference existing AWS Secrets Manager secrets for agent credentials

Amazon Bedrock’s AgentCore Identity now lets credential provider resources reference existing AWS Secrets Manager secrets instead of automatically creating new ones. That change allows teams to supply the ARN of a preconfigured secret for Outbound credential provider resources, preserving their existing encryption, rotation, tagging, replication and resource policies and avoiding forced creation of additional secrets.

Previously, AgentCore Identity provided credential providers and a token vault that automatically created a Secrets Manager secret for each Outbound credential provider resource. That automatic creation prevented customers from setting custom tags, rotation policies, replication options, or specifying a customer‑managed AWS KMS key at creation time. Allowing references to existing secrets removes those limitations and brings Bedrock agent credential management under the same Secrets Manager governance already in use.

The feature supports cross‑account selection within the same AWS Region and accepts Secrets Manager secrets imported via external connectors to enable third‑party secret manager integration. It does not support cross‑Region secret sharing, so any secret you reference must reside in the same Region as the AgentCore resources that consume it. To use an existing secret, the secret must contain the agent’s API key or OAuth client secret. You must also grant the AgentCore Identity service principal permission to call secretsmanager:GetSecretValue on that secret. If the secret is encrypted with a customer‑managed AWS KMS key, the service principal additionally needs kms:Decrypt permission to read the secret value.

Referencing an existing secret maintains operational behaviors: when you rotate the secret value in Secrets Manager, AgentCore Identity will retrieve the updated value on its next read, so credential provider resources do not need to be updated or recreated after rotation. You can also control which agents can access credentials by applying resource policies and IAM conditions directly to the secret.

For builders, this change extends existing secrets governance — customer‑managed CMKs, rotation schedules, cross‑account usage within a Region, and tagging for cost or compliance — into Bedrock agent credential management. The AWS post provides example use cases and a walkthrough for configuring credential provider resources with an existing secret; consult the AWS Secrets Manager User Guide for detailed secret configuration options.