Configuring AI agents access to AWS with non-human identity

The fastest way to give an agent too much AWS is to hand it an access key pair tied to an IAM user with a wide policy. It works on the first try, it never expires, and it is exactly the non-human identity you will regret. The better target is least scope: the agent reaches only the AWS-hosted resources its task needs, for as short a time as possible, and holds no AWS credentials of its own.

This post is about configuring AI agents access to AWS with non-human identity and keeping that identity scoped to the minimum. Least-scope is the organizing principle, and every step below serves it.

Non-human identity on AWS, done right

The trap is treating the agent as an AWS principal at all. The moment the agent holds an IAM user key, or keys that can assume a role, you own a standing non-human identity inside AWS that lives until someone rotates it. The better shape is that the agent never becomes an AWS principal. It reaches the AWS-hosted resources it needs, a database on RDS, a cluster on EKS, an instance through SSM, an object in a bucket, through a gateway that authenticates itself to AWS with its own scoped IAM role. The agent's non-human identity stays an identity-provider identity, not an AWS one.

Configuring least-scope access

Name the AWS-hosted resources the task needs, not "AWS." A grant to "read objects from this one bucket" or "connect to this one database" is easier to scope than "the agent does AWS things." Naming the specific resource is the foundation of least scope.
Front those resources with hoop.dev and give the gateway a tightly scoped IAM role. hoop.dev's gateway uses its own IAM role, with sts:AssumeRole and RDS IAM auth where configured, to reach the resources it fronts. Write that role's permissions to the exact actions and resource ARNs, for example s3:GetObject on one bucket, and constrain it with conditions. This is hoop.dev authenticating itself to the infrastructure, not the agent.
Give the agent no AWS credentials. The agent authenticates to hoop.dev with its own identity and connects to the resource through the gateway. It never holds an access key and never assumes an AWS role.
Scope and time-box the agent's access at the gateway. A policy grants the agent the specific connection the task requires, per session, expiring in minutes. The agent's reach is defined at the boundary, above AWS, not by an IAM policy attached to the agent.
Close direct network paths to AWS so the gateway is the only route to the resource.

The architectural point is that least scope is not only about the IAM policy. A perfectly scoped role is still standing access if the agent holds credentials that can use it at any time. The requirement is that the agent reaches AWS-hosted infrastructure through something it cannot reconfigure, which authenticates itself to AWS and grants the agent a scoped, per-session, recorded connection. hoop.dev is built to that requirement. The getting-started docs cover fronting an AWS-hosted resource, and the learn pages explain how least-scope access is granted per session.

Continue reading? Get the full guide.

Non-Human Identity Management + AI Human-in-the-Loop Oversight: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Verify least scope actually holds

Test the boundary, not just the path. Have the agent perform its task and confirm it succeeds through the gateway. Then have it attempt to reach a resource just outside the intended scope, for example a different database, and confirm the gateway denies it. A non-human identity that can reach more than the task needs has not been scoped to least privilege, it has only been pointed at the right job. Also confirm the agent holds no AWS keys by searching its environment and config, and that its session expires by retrying after the time-to-live and watching the connection fail.

Pitfalls

Wildcards that creep. An s3:* added to the gateway's role "just to get unblocked" rarely gets removed. Grant the specific action and add more only when a task proves it needs them.
Long sessions. A twelve-hour agent session is a standing grant in everything but name. Keep the time-to-live short.
Auditing at the agent. CloudTrail shows the gateway's role acting on AWS, but if the only record of which agent and task drove a connection lives in the agent, a compromised agent can muddy it. hoop.dev records each session outside the agent so the trail is intact.

FAQ

Should the agent use IAM user keys or an assumed role?

Ideally neither. The cleanest non-human identity is one that never becomes an AWS principal: the agent reaches AWS-hosted resources through hoop.dev, and the gateway authenticates itself to AWS with its own scoped IAM role. There is no agent key to leak and no agent role to over-grant.

How small should the gateway's IAM role be?

As small as the resources it fronts allow. Name the exact actions and resource ARNs, add conditions, and widen only when a real task proves it needs more.

hoop.dev is open source. To give a non-human identity least-scope access to AWS-hosted infrastructure, start with the repository on GitHub.