AWS Secrets Manager for AI Agents: IAM Roles vs Tokens

Quick answer: AWS Secrets Manager combined with IAM roles is the right answer for AI agents running inside AWS — Lambda functions, ECS tasks, CodeBuild jobs. The moment your agent needs to reach Stripe, GitHub, Vercel, or any service that isn't AWS-native, IAM roles can't help you, and you need scoped tokens issued by a credential broker instead.

What AWS Secrets Manager + IAM roles solve well

If your AI agent runs as an AWS workload — a Lambda function, an ECS container, a CodeBuild step — IAM roles are genuinely elegant. The agent assumes a role automatically. No credentials to store, no keys to rotate, no config to manage. AWS handles the token lifecycle.

Secrets Manager pairs with that cleanly: you store a secret, grant the role secretsmanager:GetSecretValue on that specific secret, and the agent retrieves it at runtime. The key is encrypted at rest (KMS), versioned, and can be rotated on a schedule. You get audit logs via CloudTrail. It's a well-engineered system.

For purely AWS-native workloads, this is fine. The blast radius is bounded by the IAM role's permissions, and AWS's own IAM is granular enough to scope that role tightly.

Setting up Secrets Manager for an AI agent on AWS

The recommended pattern for an AI agent running as an ECS task or Lambda function:

1. Create a dedicated IAM role for the agent — don't reuse service roles. Name it after the agent: cursor-billing-agent-role, not ai-agent-role. One role per agent type.

2. Attach a least-privilege policy that grants secretsmanager:GetSecretValue only on the specific secrets the agent needs, and kms:Decrypt on the KMS key used for encryption:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:us-east-1:123456789:secret:prod/billing-agent/*"
  }]
}

3. Use resource-based conditions to restrict access to specific secret versions or stages. secretsmanager:VersionStage: AWSCURRENT prevents the agent from reading rotation staging values.

4. Enable resource-based policies on secrets for cross-account access or additional conditions. A resource policy can restrict which IAM roles can access a secret even within the same account — useful for separating dev, staging, and production agents.

5. Configure CloudTrail to log Secrets Manager API calls. Every GetSecretValue call appears in CloudTrail with the role ARN, request timestamp, and the secret ARN (but not the value). This is your audit trail.

The IAM role approach works because ECS and Lambda inject temporary credentials via the instance metadata service. The agent never stores credentials directly — it calls GetSecretValue and the SDK handles SigV4 signing with the temporary credentials automatically.

SSM Parameter Store vs Secrets Manager

AWS has two secrets storage services and the choice matters for AI agents.

SSM Parameter Store is cheaper (free tier for standard parameters) and simpler, but has lower throughput limits (40 TPS standard, 1000 TPS advanced) and doesn't support automatic rotation natively. For agents that retrieve credentials infrequently, it's a reasonable choice. For agents running at scale or requiring rotation, Secrets Manager is more appropriate.

Secrets Manager supports automatic rotation via Lambda, has higher throughput (10,000 TPS), and integrates natively with RDS, Redshift, and DocumentDB for database credential rotation. It costs $0.40/secret/month plus API call fees. For production AI agent workloads, the rotation support and audit capabilities justify the cost.

One practical difference: Parameter Store supports hierarchical paths natively (/prod/billing-agent/stripe), making it easy to grant IAM access to an entire namespace. Secrets Manager uses tags and resource ARN patterns to accomplish the same result.

Where it gets harder

Most agents don't stay inside AWS. A coding agent like Cursor or Claude Code needs to reach GitHub. An automation workflow needs Stripe webhooks configured. A deployment agent needs Vercel environment variables set. None of those are AWS services — IAM has no authority over them.

At that boundary, IAM roles stop helping, and the workaround is usually a Secrets Manager secret containing a raw API key for the external service. Now you have a different problem: every agent sharing the same IAM role gets the full key with no differentiation, the access log only shows "retrieved secret" with no record of what the agent actually did with it, and if multiple agents share the same role, revoking one agent's access means either rotating the underlying key or restructuring IAM — both of which ripple across everything else using that secret.

The integration page for AWS Secrets Manager covers this in more detail — specifically how Gazebo can bridge your existing Secrets Manager setup rather than replace it.

The cross-service boundary problem

Here's the pattern that causes issues in practice:

1. Team stores STRIPE_SECRET_KEY in Secrets Manager
2. IAM role grants the AI agent access to that secret
3. Agent retrieves the full key and uses it for its task
4. Three months later: which agent retrieved it? What did it do? Can you revoke just this agent's access without rotating the key?

Audit logs show the retrieval. They don't show what the agent did with the credential afterward. And the "revoke" operation is key rotation — which breaks every other system sharing that secret.

This is the gap that IAM roles + Secrets Manager wasn't designed to close, because it was designed for services, not for autonomous agents making judgment calls across service boundaries.

Automatic rotation limitations for AI agents

Secrets Manager's automatic rotation is one of its most-cited advantages. A Lambda function rotates credentials on a schedule; applications pull the current version via AWSCURRENT. The underlying credential changes without any manual intervention.

For AI agents, rotation creates a specific operational challenge: agents that cache credentials (to avoid an API call on every request) will fail when rotation happens mid-session. The common recommendation — retry with the latest version on 4xx errors — works for some services but not all. Some services take minutes to propagate a newly rotated credential; during that window, requests using either the old or new key may fail unpredictably.

The mitigation: if your agents cache credentials, implement a short TTL (5-10 minutes) and force rotation windows to off-peak hours. Or avoid caching entirely and accept the Secrets Manager API call on each credential retrieval — at a few milliseconds per call, the latency is generally acceptable.

CloudTrail monitoring for agent credential access

CloudTrail logs every Secrets Manager API call, but the default event history retention is 90 days. For compliance and incident response, configure CloudTrail to deliver logs to S3 with appropriate retention. Enable CloudWatch Insights on the CloudTrail log group to query for patterns:

filter eventSource = "secretsmanager.amazonaws.com"
  and errorCode exists
| stats count() by userIdentity.arn, errorCode

This surfaces IAM roles hitting access denied errors — a signal that an agent is trying to reach a secret it isn't authorized for, which could indicate a misconfigured profile or a prompt injection attempting to exfiltrate credentials.

Scoped tokens as the cross-service answer

The alternative is a credential broker that sits in front of your external service credentials — whether those are stored in Secrets Manager, 1Password, Doppler, or anywhere else. The agent never gets the raw key. It presents its own identity (a scoped token), the broker checks what it's allowed to do, and returns either a scoped credential or a denial.

What this adds over plain Secrets Manager + IAM:

• Per-agent revocation — cut off one agent's access profile without rotating the underlying key
• Action-level audit — the broker logs which agent called which service endpoint, not just "retrieved secret"
• Cross-service policy — one profile can define what an agent can do across Stripe, GitHub, Vercel, and any other connected service, regardless of where the underlying credentials are stored

For AWS workloads, this can run alongside your existing Secrets Manager setup. You keep the IAM-controlled secrets for your AWS infrastructure. The broker handles the non-AWS credentials your agents need. The two coexist.

What to use when

Keep using IAM roles + Secrets Manager for:

• AWS-native services (RDS credentials, SQS queue URLs, internal service tokens)
• Agents that only ever need to call AWS APIs
• Workloads where the IAM role itself is the scoped identity

Add a credential broker for:

• Agents that cross the AWS boundary (external APIs, SaaS tools)
• Workflows where you need to revoke a specific agent without rotating shared secrets
• Any situation where you need a record of what the agent did, not just that it retrieved a secret

The approach isn't either/or. Teams already on AWS can keep Secrets Manager for infrastructure secrets and route external service credentials through a broker — Gazebo can pull from your existing Secrets Manager rather than duplicate what's already there.

For background on the IAM model itself, IAM for AI agents covers why the controls need to move to the credential boundary rather than relying on the agent to self-limit.

This is an independent editorial post — not affiliated with or endorsed by Amazon Web Services. Last reviewed: July 2026. Check AWS documentation for the latest IAM and Secrets Manager capabilities.