Secure AI Agent Access to AWS: Least Privilege for Claude Code

Claude Code is remarkably effective at AWS operations — it writes CloudFormation, debugs Lambdas, manages S3, configures ECS, and troubleshoots networking. Give it credentials and a task and it figures out the API calls.

That’s the appeal and the danger. “Figure out the API calls” means the agent uses whatever permissions you gave it to accomplish the task most efficiently. If the shortest path is a public S3 bucket, an open security group, or an expensive instance type — the agent does it. Not maliciously. Efficiently.

AWS now has a published position on this. Its 2026 Security Blog on AI-agent access patterns is blunt: “You must assume an agent can do anything within its granted entitlements.” The guidance is least-privilege, short-lived credentials, and — critically — differentiating AI-driven from human-initiated actions with different IAM rules per actor type. This article is how to implement that for Claude Code.

The admin-credential anti-pattern

The most common Claude Code + AWS setup: the developer exports their AdministratorAccess profile into the agent’s environment. Every API is available; every resource is reachable. What follows, repeatedly:

• The cleanup incident. An agent deploying a new service notices “unused” resources and deletes an old Lambda (processing webhooks), an “empty” S3 bucket (nightly DB backups), and an EC2 instance (a bastion host).
• The cost escalation. An agent “optimizing” RDS resizes it to db.r6g.4xlarge. Monthly cost goes $400 → $3,200. Nobody notices for two weeks.
• The security exposure. An agent debugging connectivity adds an inbound rule for 0.0.0.0/0 on 443. Problem solved; public hole created.

None are Claude Code bugs. The agent did exactly what it thought was needed. Nothing constrained its scope.

Least privilege for Claude Code (AWS’s own prescription)

Start with the task, not the service. An agent deploying a Lambda needs lambda:UpdateFunctionCode on that specific function ARN — not lambda:* on *. AWS’s example is identical: grant s3:GetObject, not s3:*.

Scope to specific resources:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-app-deployments/builds/*"
}

This agent reads/writes one prefix of one bucket. It cannot list the bucket, delete objects, change bucket policy, or touch any other bucket.

Separate read from write. Most agent tasks (log analysis, config review, status checks) need read only. Keep separate read-only and read-write roles; default to read-only; escalate only when the task requires it.

Constrain with conditions:

{ "Condition": { "StringEquals": { "ec2:InstanceType": ["t3.micro", "t3.small", "t3.medium"] } } }

The agent can launch EC2 — but only small instances. A p4d.24xlarge just returns a permission error, invisible to the agent.

Differentiate the actor. This is the part most teams skip and AWS specifically calls out: an AI-driven action should not run under the same IAM permissions as the human who launched the session. Tag the session as agent-initiated and apply tighter rules to it — so “Jordan running a command” and “Jordan’s agent running a command” are governed differently.

Temporary credential vending (no long-lived keys)

Long-lived access keys are the biggest IAM anti-pattern for Claude Code. Use STS AssumeRole session credentials instead: when a session starts, a vending service mints temporary creds with a short duration (1 hour is usually enough); when the session ends or they expire, access stops automatically.

Session tags make attribution automatic:

{ "Tags": [
  {"Key": "agent-session", "Value": "sess_a8f3b21c"},
  {"Key": "developer", "Value": "jordan"},
  {"Key": "project", "Value": "backend-api"}
]}

Now every CloudTrail entry reads assumed-role/agent-deploy-role/sess_a8f3b21c with tags identifying the session, developer, and project.

When things go wrong anyway

Even with scoped IAM, agents do unexpected things within their allowed permissions.

• Real-time CloudTrail monitoring. Fire event rules on agent-tagged sessions performing sensitive actions — IAM changes, security-group edits, deletions.
• Session kill switch. aws sts revoke-session (revoke-session-credentials) instantly invalidates a role session’s temporary credentials; the agent’s next call fails. Practice this before you need it.
• Automated rollback. AWS Config rules detect drift (e.g., an opened security group) and auto-remediate.

The gateway approach: zero credentials in the agent

All of the above — role management, credential vending, CloudTrail alerting, kill switches — can be done by hand. It stops scaling the moment you have multiple developers running multiple agents across multiple AWS accounts.

A control plane centralizes it. The agent never receives AWS credentials. It makes requests through a gateway that:

1. Checks the request against a deny-by-default policy engine
2. Injects temporary, scoped credentials for that one operation
3. Logs it with full session context (immutable)
4. Enforces rate limits, cost controls, and human approval for sensitive actions

The agent never sees the credentials — it can’t leak them, cache them, or use them outside policy. The IAM policy is the floor; the gateway policy is the ceiling. This is also the cleanest way to implement AWS’s “differentiate the actor” guidance: the gateway is the agent’s identity, distinct from the human’s.

Getting started

Running Claude Code against AWS today without controls? Five standard-AWS steps that cut blast radius immediately:

1. Stop using admin credentials — create a task-specific role with only what the agent needs.
2. Switch to temporary credentials — STS AssumeRole, not access keys.
3. Add session tags — identify every API call by session, developer, project.
4. Set up CloudTrail alerting — know when agent sessions do sensitive things.
5. Test the kill switch — practice revoke-session before you need it.

Then decide whether to operate all of this yourself or route through a managed control plane that does it on every request.

FAQ

How do I give an AI agent secure access to AWS? Use least-privilege IAM scoped to specific actions and resource ARNs, temporary STS credentials (not access keys), session tags for attribution, and a separate agent identity from the human’s. AWS’s own guidance is to assume the agent can do anything its entitlements allow — so scope tightly and differentiate AI-driven from human actions.

What IAM permissions should a Claude Code agent have? Only what the specific task needs — e.g. s3:GetObject on one prefix, lambda:UpdateFunctionCode on one function ARN. Default to read-only; escalate per task; never *:*.

How do I stop an AI agent that’s misbehaving in AWS? Revoke its STS session (aws sts revoke-session-credentials) to instantly kill all its temporary credentials, or — if it routes through a control plane — flip the gateway kill switch, which stops it without touching IAM.

Should the AI agent use my AWS credentials? No. Long-lived keys in the agent environment are the top anti-pattern. Vend short-lived scoped credentials per session, or hold the credentials in a gateway so the agent has none at all.