Introduction

AI agents built on Amazon Bedrock AgentCore need credentials to call external APIs — Google OAuth, Salesforce, GitHub, internal services. AgentCore Identity manages these credentials through Credential Providers, storing secrets in AWS Secrets Manager and retrieving them at runtime so agent code never handles raw secrets.

AgentCore Identity supports Bring Your Own Secret (BYOS) — you create and manage secrets in Secrets Manager with your own governance policies (CMK encryption, tags, rotation, resource policies), then reference the secret ARN when configuring a Credential Provider. AgentCore Identity reads the secret value at runtime without managing its lifecycle.

This gives teams full ownership of how credentials are created, classified, rotated, and governed — while AgentCore Identity handles the runtime consumption seamlessly.

How It Works

The model is straightforward:

1. You create the secret in Secrets Manager with your governance requirements
2. You provide the secret ARN + JSON key when configuring the Credential Provider
3. AgentCore Identity calls secretsmanager:GetSecretValue at runtime to retrieve the credential

Your Governance Process (IaC / Console / CLI)
    │
    │  CreateSecret
    │  • CMK encryption (your KMS key)
    │  • Tags: CostCenter=AI, Team=Platform, Env=Prod
    │  • Rotation: 30-day Lambda rotator
    │  • Resource policy: scoped access
    ▼
AWS Secrets Manager (your secret, your rules)
    │
    │  You provide: secretId (ARN) + jsonKey
    ▼
AgentCore Identity Credential Provider
    │
    │  At runtime: GetSecretValue → extracts value from jsonKey
    ▼
External API (Google, Salesforce, GitHub, etc.)

Key Capabilities

• CMK encryption — Encrypt secrets with your customer-managed KMS key, satisfying SCPs that enforce CMK on all resources
• Resource tagging — Apply mandatory tags at creation time (cost allocation, compliance, team ownership)
• Automatic rotation — Attach your own rotation Lambda; AgentCore Identity picks up new values on next read without credential provider updates
• Resource policies — Scope access to specific IAM principals using Secrets Manager resource policies
• Cross-account references — Reference secrets from another AWS account in the same Region
• External connector support — Use secrets imported via Secrets Manager external connectors (HashiCorp Vault, etc.)
• Full CloudTrail audit — Every GetSecretValue call is logged under your account's trail

Implementation Guide

Step 1: Create Your Secret in Secrets Manager

aws secretsmanager create-secret \
    --name "agentcore/google-oauth-client" \
    --description "Google OAuth client secret for AgentCore agent" \
    --kms-key-id "arn:aws:kms:us-east-1:123456789012:key/your-cmk-key-id" \
    --secret-string '{"client_secret": "your-oauth-client-secret-value"}' \
    --tags '[
        {"Key": "CostCenter", "Value": "AI-Platform"},
        {"Key": "Team", "Value": "AgentCore"},
        {"Key": "Environment", "Value": "Production"},
        {"Key": "RotationSchedule", "Value": "30-days"}
    ]'

Step 2: Add Resource Policy

Grant AgentCore Identity permission to read the secret:

aws secretsmanager put-resource-policy \
    --secret-id "agentcore/google-oauth-client" \
    --resource-policy '{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "AllowAgentCoreIdentityRead",
                "Effect": "Allow",
                "Principal": {
                    "Service": "identity.bedrock-agentcore.amazonaws.com"
                },
                "Action": "secretsmanager:GetSecretValue",
                "Resource": "*",
                "Condition": {
                    "StringEquals": {
                        "aws:SourceAccount": "123456789012"
                    }
                }
            }
        ]
    }'

Step 3: Grant KMS Decrypt Permission (if using CMK)

Add to your KMS key policy:

{
    "Sid": "AllowAgentCoreDecrypt",
    "Effect": "Allow",
    "Principal": {
        "Service": "identity.bedrock-agentcore.amazonaws.com"
    },
    "Action": "kms:Decrypt",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com",
            "aws:SourceAccount": "123456789012"
        }
    }
}

Step 4: Create Credential Provider Referencing Your Secret

OAuth2 Client:

aws bedrock-agentcore-control create-oauth2-credential-provider \
    --name "google-oauth-client-prod" \
    --credential-provider-vendor "GoogleOauth2" \
    --oauth2-provider-config-input '{
        "googleOauth2ProviderConfig": {
            "clientId": "your-google-client-id.apps.googleusercontent.com",
            "clientSecretSource": "EXTERNAL",
            "clientSecretConfig": {
                "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:agentcore/google-oauth-client-AbCdEf",
                "jsonKey": "client_secret"
            }
        }
    }'

API Key:

aws bedrock-agentcore-control create-api-key-credential-provider \
    --name "github-api-key-prod" \
    --api-key-source "EXTERNAL" \
    --api-key-config '{
        "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:agentcore/github-api-key-XyZ123",
        "jsonKey": "api_key"
    }'

Custom OAuth2 Provider:

aws bedrock-agentcore-control create-oauth2-credential-provider \
    --name "internal-idp-client" \
    --credential-provider-vendor "CustomOauth2" \
    --oauth2-provider-config-input '{
        "customOauth2ProviderConfig": {
            "oauthDiscovery": {
                "discoveryUrl": "https://idp.internal.company.com/.well-known/openid-configuration"
            },
            "clientId": "my-agent-client-id",
            "clientSecretSource": "EXTERNAL",
            "clientSecretConfig": {
                "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:agentcore/internal-idp-AbCdEf",
                "jsonKey": "secret"
            },
            "clientAuthenticationMethod": "CLIENT_SECRET_BASIC"
        }
    }'

Secret Rotation

When you rotate the secret value, AgentCore Identity automatically picks up the new value on its next read — no credential provider update or agent restart needed.

Day 0:  Secret = {"client_secret": "value-abc"}
        AgentCore reads "value-abc" at runtime ✓

Day 30: Rotation Lambda runs
        → Generates new secret with IdP
        → Updates Secrets Manager: {"client_secret": "value-xyz"}

Next call: AgentCore reads "value-xyz" ✓
           Zero downtime, zero config changes

Cross-Account Secret Sharing

You can reference secrets from another AWS account in the same Region — useful for centralized secret management:

┌──────────────────────────────┐      ┌──────────────────────────────┐
│  Security Account            │      │  Workload Account            │
│                              │      │                              │
│  Secrets Manager             │      │  AgentCore Identity          │
│  • All OAuth secrets         │◄─────│  • References secret ARN     │
│  • Centrally managed         │      │    from security account     │
│  • Single rotation pipeline  │      │                              │
└──────────────────────────────┘      └──────────────────────────────┘

The secret's resource policy must allow the workload account's AgentCore Identity service principal.

Use Cases

Scenario	How BYOS Helps
SCP enforces CMK on all secrets	Create secret with your CMK before referencing
Mandatory tagging for cost allocation	Tag at creation time with your taxonomy
30-day rotation policy	Attach rotation Lambda to your secret
Multi-account centralized secrets	Reference cross-account secret ARN
Audit who accessed agent credentials	Full CloudTrail on your secret
Importing from HashiCorp Vault	Use Secrets Manager external connectors, then reference
Scoped access (only this agent can read)	Resource policy restricts to specific conditions

Important Notes

• Immutable choice: You cannot switch between service-managed and BYOS after creating a credential provider. To change the method, delete and recreate the credential provider.
• Same Region only: Cross-account references must be in the same AWS Region.
• JSON format required: The secret must be a JSON object. You specify the jsonKey that contains the credential value.
• Permissions are your responsibility: If the resource policy or KMS key policy is misconfigured, AgentCore Identity will fail to read the secret at runtime.

Availability

Available in 14 AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Asia Pacific (Mumbai, Seoul, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Paris, Stockholm).

References

• Reference your own AWS Secrets Manager secrets in Amazon Bedrock AgentCore Identity (AWS Blog)
• Manage credential providers with AgentCore Identity
• Amazon Bedrock AgentCore Identity documentation
• AWS Secrets Manager User Guide