What's New

Amazon Bedrock AgentCore Identity now supports a "bring your own secret" (BYOS) model, allowing customers to reference existing AWS Secrets Manager secret ARNs directly when configuring Credential Providers. Previously, the service created and managed secrets on the customer's behalf, limiting governance controls such as customer-managed key (CMK) encryption, resource tagging, and custom rotation policies. Customers can now fully own the lifecycle of their secrets while AgentCore Identity continues to consume them transparently at runtime.

How It Works

• Customers create and manage secrets independently in AWS Secrets Manager, applying their own CMK encryption, tagging strategies, resource policies, and rotation schedules before any AgentCore configuration takes place.
• When configuring a Credential Provider in AgentCore Identity, customers supply the existing secret's ARN rather than providing raw credential values for the service to store.
• The clientSecretSource field is set to "EXTERNAL" in the credential provider configuration, and a clientSecretConfig block specifies both the secretId (ARN) and the jsonKey that maps to the relevant field within the secret.
• At runtime, AgentCore Identity reads the referenced secret from Secrets Manager to perform authentication flows (e.g., OAuth 2.0 token exchange), without requiring any changes to how agents request or receive access tokens.
• The feature is accessible via the AWS CLI (aws bedrock-agentcore-control create-oauth2-credential-provider), the AgentCore SDK, and the AgentCore CLI, giving teams flexibility in how they integrate it into existing workflows.

Why It's Important

• Organizations with strict compliance requirements (e.g., PCI-DSS, HIPAA, FedRAMP) can now enforce CMK encryption on all secrets used by AI agents, closing a gap that previously blocked adoption in regulated industries.
• Security and platform teams can apply consistent tagging taxonomies to AgentCore secrets, enabling cost allocation, automated policy enforcement, and audit trail continuity across the entire secrets estate.
• Automatic rotation policies configured in Secrets Manager are now fully honored, reducing the risk of long-lived, stale credentials being used by agents without manual intervention.
• Resource-based policies on secrets allow fine-grained access control, ensuring only authorized AgentCore workloads or accounts can retrieve a given credential, supporting least-privilege architectures.
• Decoupling secret lifecycle management from the AgentCore service reduces operational friction for teams that already have established secrets governance pipelines, avoiding duplicate management overhead.

How It's Different

• Previous service-managed model: Secrets were created by AgentCore Identity on the customer's behalf, meaning customers had no control over encryption keys, tags, or resource policies at creation time; the new BYOS model transfers full ownership to the customer.
• CMK encryption: The old approach did not support customer-managed KMS keys for secret encryption; BYOS explicitly supports CMK-encrypted secrets created outside the service.
• Tagging and classification: Service-managed secrets could not be tagged at creation time with customer-defined metadata; BYOS secrets carry whatever tags the customer applies before referencing them in AgentCore.
• Rotation and resource policies: Automatic rotation and Secrets Manager resource policies were unavailable under the service-managed approach; BYOS secrets fully support these native Secrets Manager capabilities.
• Runtime behavior unchanged: Despite the governance changes, AgentCore Identity's runtime credential retrieval and token vault behavior remain identical, meaning no agent code changes are required.

When to Prefer It

• Use BYOS when your organization mandates CMK encryption for all secrets and you need to specify a particular KMS key managed by your security team.
• Use BYOS when your cloud governance policy requires all AWS resources, including secrets, to carry specific cost-allocation or environment tags at the time of creation.
• Use BYOS when you need automatic secret rotation (e.g., rotating OAuth client secrets on a schedule) and want Secrets Manager's native rotation framework to handle it without manual AgentCore reconfiguration.
• Use BYOS when operating in a multi-account or AWS Organizations environment where resource-based policies on secrets are used to enforce cross-account access boundaries.
• Use BYOS when your security team already manages a centralized secrets vault in Secrets Manager and you want AgentCore Identity to consume from that vault rather than creating a parallel, service-managed secrets store.
• Use BYOS when audit and compliance workflows require secrets to be discoverable and attributable through your existing Secrets Manager inventory and tagging reports.

Availability

• Status: Generally Available (GA) as of June 1, 2026.
• Supported Regions (14 total): US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), and Europe (Stockholm).
• Pricing: No additional charge from AgentCore Identity for using BYOS; standard AWS Secrets Manager pricing applies for secret storage and API calls.
• Credential Provider Types: Supported for OAuth 2.0, API key, and payment credential providers within AgentCore Identity.
• Limitation: Customers are responsible for ensuring the AgentCore Identity service role has secretsmanager:GetSecretValue permission on the referenced secret ARN; misconfigured IAM or resource policies will cause runtime authentication failures.

Related Resources

• https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/resource-providers.html