How to give an AI agent AWS access without long-lived keys

The quickest way to give an AI agent AWS access is to paste an access key and secret into its environment. It is also the easiest way to lose your account. There is a better pattern that gives the agent exactly the access it needs, for minutes at a time, with nothing long-lived to steal.

Why not an access key

An IAM user's access key is long-lived and, in practice, over-scoped. In an agent it is exposed to prompt injection, logs, traces, and memory, and a single leak is standing access until someone rotates it. AWS's own guidance is to avoid long-lived access keys in favor of temporary credentials; for an agent that advice is not optional.

The pattern: identity in, short-lived credentials out

1. The agent proves who it is. In CI (GitHub Actions, GitLab) or in the cloud (an instance or pod), the platform can issue the agent a short-lived OIDC identity token. No stored secret.
2. A broker verifies that identity against the issuer's published keys and checks a default-deny policy for what this agent may do.
3. The broker calls AWS STS to assume a role, optionally narrowed further with an inline session policy, and gets back credentials valid for a short session.
4. The broker performs the operation and returns the result. The agent never holds the access key or the STS credentials.

What the agent sends

The agent makes a normal request to the broker, authenticated with its workload-identity token, naming the operation, for example listing a bucket:

POST /v1/actions
Authorization: Bearer <workload-identity-token>

{ "provider": "aws", "resource": "my-logs-bucket", "action": "S3_LIST" }

The broker assumes the configured role, runs the call, and returns the listing. You can pass a tighter inline session policy per call so the temporary credentials are scoped below the role itself.

Policy and expiry

Which agent may assume which role, for which operations, is a default-deny policy: an operation runs only if a rule allows it, and every call is audited. Session length follows the policy and AWS limits (STS sessions run from 15 minutes up to 12 hours), so you can keep a destructive operation on a very short credential while a read uses the default.

Set it up

With PastKeys, run a broker, seal your AWS bootstrap credential to it (or give it an instance role), configure the role to assume, and add the agent's identity issuer in the dashboard. The agent then authenticates with its platform token and asks for operations. See scoped, short-lived credentials for how the same applies to GitHub and Postgres, and the quickstart to set it up.