A human forgets a password and gets locked out. An AI agent never logs out, so the credential it holds is awake every second of every day, whether a task is running or not. That resting credential is the whole problem with non-human identity for AI agents on AWS: the identity exists continuously, but the need for it is intermittent.
The fix is not a better secret. It is changing when the identity has power at all. Standing access keeps the door open and trusts the agent not to walk through it. Per-task access opens the door for one trip and closes it behind. One of these survives a compromised agent. The other does not.
What non-human identity has to mean for an agent
A non-human identity is the principal an automated workload presents when it reaches a resource. For an AI agent on AWS, that resource is infrastructure: an RDS database, an EKS cluster, an instance reached over SSM, a DynamoDB table. The naive version hands the agent a long-lived access key and calls the key its identity. That conflates two things that should stay separate: who the agent is, and what it is allowed to do right now.
Keep them separate and the picture clears up. The identity is stable and attributable. The access is scoped, granted per task, and gone when the task ends. The agent is always identifiable, but it is only powerful while it is working.
Standing access versus scoped, per-task access
Standing access means the agent holds credentials that work at any time. The blast radius is everything those credentials reach, multiplied by every minute they exist, which for an always-on agent is all of them. A leaked key, a prompt injection that redirects a tool call, a confused agent looping on the wrong resource: each of these turns standing access into standing damage.
Scoped, per-task access inverts the resting state. Between tasks the agent holds nothing usable. When it needs to read one table, it requests access to that one table, for the minutes the task takes, against its named identity. The same compromise that drains a standing key finds an agent with no live grant to abuse. The non-human identity is still real and still logged, but its authority is a thin, moving window rather than a permanent grant.
Where the identity boundary has to sit
Here is the architectural requirement, stated plainly: the thing that decides what an agent's identity may do, and records what it did, has to sit outside the agent. If the agent mints its own grants and writes its own log, then a compromised agent rewrites both, and the non-human identity becomes a name with no enforcement behind it.
That requirement is the shape of hoop.dev. The agent connects through hoop.dev, a Layer 7 access gateway, instead of holding AWS keys. hoop.dev verifies the agent identity, applies policy per task, and reaches each AWS-hosted resource using its own scoped IAM role. The agent never becomes an AWS principal and never sees a credential. Its identity lives at the boundary, where the agent cannot reconfigure it, and each session is recorded on the gateway side. The getting-started docs cover registering an AWS-hosted resource, and the learn pages describe how identity and per-task scope fit together.
A concrete trace
An agent needs to read a row from an RDS reporting database. With per-task access the sequence is: the agent asks hoop.dev for a connection, hoop.dev checks the request against the agent identity and the allowed scope, opens a short-lived connection to that database using its own IAM-authenticated role, the session is recorded, and the connection closes. The agent held no database password and no AWS key at any point. Nothing about that access persists into the next task.
Compare the standing version: the agent holds a database secret and an access key it can use forever. The read it needs once is authorized always. If the agent is turned against you tomorrow, the access is already granted. The per-task model simply has no resting authority to steal.
FAQ
Is a non-human identity just a service account?
A service account is one way to name a workload, but on its own it is usually a standing credential. A strong non-human identity for an agent adds per-task, expiring scope and a record produced outside the agent, so the identity is attributable and its authority is temporary.
Does the agent need AWS credentials at all under this model?
No. The agent connects through hoop.dev, which reaches the AWS-hosted resource with its own scoped IAM role. The agent never becomes an AWS principal, so there is no agent-held key to leak.
hoop.dev is open source. To give an AI agent a non-human identity scoped per task in front of AWS, start from the repository on GitHub.
