Amazon Bedrock AgentCore Identity References AWS Secrets Manager Secrets for Secure AI Agents

Amazon Bedrock AgentCore Identity: Reference AWS Secrets Manager Secrets for Secure AI Agents

  • What changed: AgentCore Identity can now reference an existing AWS Secrets Manager secret (by ARN + JSON key) for outbound credentials instead of creating its own secret.
  • Why it matters: Security and platform teams keep control of encryption keys (including customer‑managed KMS CMKs), rotation, tags, replication, and resource policies while AI agents get runtime access to APIs.
  • Action: Identify the secrets your agents need, update Secret and KMS policies to allow AgentCore access, and test rotation and logging in a staging environment.

Meta description suggestion: How Amazon Bedrock AgentCore Identity can reference existing AWS Secrets Manager entries to keep encryption, rotation, and governance under your control — step‑by‑step guidance for secure AI agents.

“AI agents are only useful to the degree they can access external tools and APIs—so securely passing credentials at runtime is a core challenge for production agent systems.”

Quick primer: what these terms mean

  • AgentCore Identity / AgentCore: The Amazon Bedrock component that manages credentials for AI agents so they can call external APIs (Outbound Auth) when acting on behalf of workflows.
  • Outbound Auth: AgentCore’s outbound credential providers—configurations that let agents use API keys or OAuth client credentials to reach third‑party services.
  • AWS Secrets Manager: AWS service for storing secrets (API keys, client secrets, DB credentials) as structured values; supports rotation and replication.
  • ARN: Amazon Resource Name — the unique identifier for an AWS resource (for example, a Secrets Manager secret).
  • CMK (customer‑managed KMS key): A KMS key you manage that encrypts Secrets Manager values; keeps cryptographic control inside your environment.

What changed and why it matters

AgentCore Identity now supports referencing an existing Secrets Manager secret by its ARN plus a JSON key path for the value. That means instead of letting AgentCore create and own a Secrets Manager entry, platform teams can reuse their preconfigured secrets and KMS settings.

For security‑first organizations, this removes a recurring blocker: teams retain tagging, rotation schedules, CMKs, replication rules, and precise resource policies while still giving AI agents runtime access to credentials for API calls. It aligns agentic AI with enterprise secrets governance.

Business impact — the practical benefits

  • Keep your encryption setup: continue using customer‑managed KMS keys and the key policies you already audit.
  • Preserve rotation and lifecycle: automated rotations defined in Secrets Manager are picked up by AgentCore on next read—no extra work to reconfigure agents.
  • Maintain tagging and replication: integrate agent secrets with your billing, compliance, and cross‑account patterns.
  • Fit into existing workflows: support for cross‑account secrets (same Region) and Secrets Manager external connectors lets you use secrets imported from third‑party vaults.

Mini case: fintech exposes a Google OAuth client to an agent—without changing governance

A payments platform had a Google OAuth client secret encrypted with a CMK and replicated to several accounts. Instead of copying or re‑creating a secret for AgentCore, the team granted AgentCore Identity GetSecretValue and KMS decrypt permissions on the existing secret. Agents could then request Google Maps tokens at runtime while rotation, tags, and audit trails stayed intact—saving audit cycles and accelerating deployment.

How to configure (step‑by‑step)

High level: 1) Ensure the secret exists and has the right JSON structure (e.g., {“client_secret”:”…”}). 2) Give AgentCore permission to read it. 3) Create the Outbound Auth credential provider pointing to the secret ARN + JSON key. 4) Test and validate rotation and logs.

1. Prepare the secret

  1. Store the credential in Secrets Manager using a JSON structure (recommended for clarity): for example, {“api_key”:”…”, “client_secret”:”…”}.
  2. Confirm the secret is in the same AWS Region as AgentCore resources. If you need multi‑Region access, replicate the secret to those Regions.

2. Grant runtime permissions

Grant the AgentCore Identity service principal secretsmanager:GetSecretValue on the secret, and if you use a customer‑managed KMS key, give it kms:Decrypt on the CMK. Scope these privileges to just the secrets the agents need.

3. Create the credential provider

Console: When adding an Outbound Auth credential provider, choose “reference existing secret,” paste the secret ARN, and specify the JSON key (for example, client_secret or api_key).

CLI (example — adapt to your environment):

aws agentcore create-oauth2-credential-provider \
  --name "my-client" \
  --vendor "GoogleOauth2" \
  --secret-ref '{"SecretId":"arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret","JSONKey":"client_secret"}'

AI coding assistant: Prompt your internal agent to create an OAuth2 credential provider named <client-name>, using the vendor (e.g., GoogleOauth2) and referencing the Secrets Manager ARN plus JSON key.

Runtime behavior and rotation — what to expect

  • AgentCore reads the JSON key value at runtime when the agent needs to present credentials to an external API.
  • If the secret is rotated, AgentCore will pick up the new value on its next read—no need to recreate the credential provider.
  • CloudTrail records GetSecretValue calls; use those events to validate access and integrate with SIEM tools.

Testing checklist

  • Confirm the secret’s resource policy allows secretsmanager:GetSecretValue from the AgentCore principal (or role).
  • If using a CMK, confirm kms:Decrypt is allowed for the AgentCore principal in the key policy.
  • Trigger a secret rotation and verify AgentCore uses the new value in the subsequent outbound call.
  • Inspect CloudTrail for GetSecretValue events attributed to AgentCore and verify timestamps and source identifiers.

Security and governance (concrete guidance)

Treat AgentCore access like any other platform consumer of secrets—least privilege, clear audit trails, and separation of duties.

Example Secrets Manager resource policy (example — adapt to your environment)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAgentCoreGetSecretValue",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/AgentCoreIdentityRole" },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-secret-ABC"
    }
  ]
}

Example KMS key policy snippet (example — adapt)

{
  "Sid": "AllowAgentCoreDecrypt",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789012:role/AgentCoreIdentityRole" },
  "Action": "kms:Decrypt",
  "Resource": "*"
}

Notes:

  • Replace the Principal with the exact role or service principal your environment uses for AgentCore. Check AWS docs or your account mappings for the authoritative principal name.
  • Prefer roles over wildcard principals and limit actions to secretsmanager:GetSecretValue and kms:Decrypt only.

Pitfalls to avoid

  • Forgetting to grant kms:Decrypt when a CMK protects a secret — AgentCore will get access errors at runtime.
  • Using the wrong JSON key name in the credential provider configuration. Confirm spelling and path.
  • Expecting cross‑Region references — Secrets Manager secrets must be in the same Region as AgentCore; use replication if needed.

Enterprise considerations

Cross‑account: Supported as long as the secret and AgentCore are in the same Region and the resource policy grants access to AgentCore. Many teams use a centralized vault account and grant read access to platform roles in consuming accounts.

Cross‑Region: Not supported natively. If agents run across Regions, replicate secrets and any required CMKs or use a centralized agent in the secret’s Region.

Ephemeral credentials vs long‑lived secrets: Long‑lived secrets are easier to retrofit, but ephemeral tokens (short‑lived OAuth tokens, AWS STS‑issued credentials) reduce blast radius. Use ephemeral credentials where you can automate issuance and rotation; reuse Secrets Manager for services that still need long‑lived values.

Do this first — a quick migration checklist for teams

  1. Inventory agent credential needs and match them to existing Secrets Manager entries.
  2. Update Secrets Manager resource policies to permit AgentCore reads (secretsmanager:GetSecretValue).
  3. If using CMKs, add kms:Decrypt permissions in the key policy for the AgentCore principal.
  4. Create credential providers in AgentCore pointing to the secret ARN + JSON key.
  5. Run the testing checklist and validate CloudTrail logs for GetSecretValue events.

FAQ

Can AgentCore use secrets encrypted with my customer‑managed KMS CMK?

Yes. Grant the AgentCore Identity principal kms:Decrypt on your CMK in the key policy so it can decrypt the secret value at runtime.

Will AgentCore automatically pick up rotated secrets?

Yes. AgentCore reads the secret value at runtime and will retrieve the updated secret after rotation—no need to recreate the credential provider.

Can I reference secrets from another AWS account?

Yes, as long as the secret is in the same AWS Region and the secret’s resource policy grants the AgentCore principal GetSecretValue access. Cross‑Region references are not supported today.

What minimum permissions are required?

AgentCore needs secretsmanager:GetSecretValue on the secret and kms:Decrypt if a CMK encrypts the secret. Scope these permissions narrowly to follow least‑privilege principles.

Technical appendix — CLI example and monitoring hints

CLI example (pseudo):

aws agentcore create-oauth2-credential-provider \
  --name "example-client" \
  --vendor "GoogleOauth2" \
  --secret-ref '{"SecretId":"arn:aws:secretsmanager:us-east-1:123456789012:secret:example","JSONKey":"client_secret"}'

Monitoring hints:

  • Look for CloudTrail events: secretsmanager:GetSecretValue and correlate with AgentCore identifiers.
  • Tag secrets used by agents for easier filtering and billing reconciliation.
  • Feed events into your SIEM to alert on anomalous access patterns or failed decrypt attempts.

Next steps and a short playbook

  1. Pick one API your agents need and map it to an existing Secrets Manager secret.
  2. Update the secret and KMS policies to allow AgentCore access.
  3. Create the credential provider in a sandbox and validate rotation and CloudTrail logs (30–60 minutes).
  4. Document the pattern and roll it out to other agent workflows with per‑agent secrets where appropriate.

Swara Gandhi and Satveer Khurpa contributed the identity and AgentCore guidance that informed these recommendations.

Alt text suggestion for a diagram: “Diagram showing AWS Secrets Manager (with CMK) → AgentCore Identity fetching secret at runtime → Outbound Auth → External API (AI agent).

0