Your AI Agent Is a New Identity: Least Privilege for Non-Human Principals on AWS

Cloud security has spent a decade learning to manage the identities of people: give each human a unique login, enforce multi-factor authentication, grant the least privilege they need, and review access regularly. A quieter shift has been happening underneath that work. The identities that now do most of the acting in a modern AWS account are not people at all. They are roles assumed by services, functions, and pipelines, and the fastest-growing category among them is the AI agent: a language model given tools, credentials, and the autonomy to decide its own next step. When that agent can assume an IAM role, it becomes a principal in your account with the power to read data and call APIs, and it deserves exactly the identity discipline you already apply to humans, plus a few controls unique to how it behaves.

The reason this matters is that agent identities combine two properties that are individually manageable but dangerous together: they hold real permissions, and their behavior is driven by untrusted input at runtime. A traditional service role runs deterministic code, so its actions are bounded by what the developer wrote. An agent’s actions are bounded only by what its role permits, because the model decides what to do based on data it reads, and that data can be influenced by an attacker. The role’s permission boundary is therefore not a formality. It is the primary control that decides how much damage a hijacked agent can do.

Give every agent its own identity

The first rule is the oldest one in identity management, and it is the one most often broken in the rush to ship an AI feature: no shared credentials. Each agent, or each distinct agent function, should assume its own IAM role rather than reusing a general-purpose service role that a dozen other things also use. Shared identities destroy accountability, because when something goes wrong you cannot tell which workload did it, and they inflate privilege, because a shared role accumulates the union of everything its users need.

A dedicated role per agent buys three things at once. It makes CloudTrail legible, because every action the agent takes is attributed to a principal you can name. It makes revocation surgical, because you can disable or tighten one agent without breaking others. And it makes least privilege achievable, because a role that serves exactly one agent can be scoped to exactly that agent’s needs rather than the superset of many. Treat the creation of an agent as the creation of a new identity, with the same registration, ownership, and lifecycle you would give a new service account.

Scope the permissions to the task, not the possibility

Once an agent has its own role, the work is to make that role as small as the agent’s job allows. The temptation runs the other way. Agents are marketed on their flexibility, and it feels natural to grant broad permissions so the agent can handle whatever comes up. That instinct is precisely the one to resist, because the agent’s flexibility is the attacker’s flexibility once an injection or a compromised input takes the wheel.

Scope by action and by resource. If the agent’s job is to read from one DynamoDB table and call one internal API, its policy should name that table and that API and nothing else, with no s3:* or iam:* wildcards added for convenience. Prefer read-only permissions wherever the agent’s function allows it, since a role that cannot write, delete, or modify has a dramatically lower ceiling on harm regardless of what it is tricked into attempting. Where the agent genuinely must write, scope the write as narrowly as the API permits, using resource ARNs and conditions rather than service-wide grants. This is ordinary least-privilege IAM work, and it is the single highest-leverage control you have over an autonomous principal.

Two conditions deserve special attention for agents that assume roles. Use an external ID or a scoped trust policy so that only your intended calling principal can assume the agent’s role, closing the confused-deputy gap at the trust-relationship level. And set a short session duration on the assumed role, so that credentials the agent holds are short-lived by construction rather than long-lived secrets that leak and linger.

Never hand an agent a long-lived key

The credential model matters as much as the permission set. An AI agent should obtain its permissions through a role it assumes and short-lived STS credentials, not through a static access key baked into an environment variable or a prompt. Long-lived keys are the classic cloud breach vector: they end up in logs, in code repositories, in screenshots, and in the memory of a model that might reproduce them in an output. The public record of cloud incidents is full of leaked long-lived keys, and an agent, which processes and sometimes emits large volumes of text, is an unusually efficient way to spill one.

Roles solve this cleanly. When an agent runs inside a Lambda function, a container task, or an EC2 instance, it should inherit permissions from the execution role of that compute, retrieved automatically as temporary credentials, so there is no static secret to leak in the first place. Where an agent must reach across accounts, it should assume a cross-account role scoped with an external ID rather than carry another account’s keys. The goal is that at no point does a durable, replayable credential exist in a place the model can read or reproduce.

Contain the blast radius by design

Least privilege bounds what one agent can do; architecture bounds what a breach of the surrounding system can reach. Run agents that touch sensitive systems in isolated compute with tight network egress, so a compromised agent cannot freely call out to an attacker’s endpoint or pivot laterally. Route the agent’s AWS API traffic through private networking such as VPC endpoints, keeping it off the public internet and giving you a policy enforcement point. And separate duties across agents rather than building one omni-capable agent: an agent that reads should not be the same identity that writes, and an agent that drafts a change should not be the identity that approves it.

For the highest-consequence actions, keep a deterministic checkpoint outside the agent’s control. Anything that deletes data, moves money, changes access, or sends communications externally should pass through a human approval or a policy engine that the model cannot instruct away. The agent proposes; a control the agent cannot bypass disposes. This is the same separation-of-duties principle that governs privileged human access, applied to a principal that happens to be software.

Monitor the non-human principal like any other

An agent identity that acts in your account produces the same telemetry any principal does, and it should be watched with the same rigor, arguably more, because its behavior is driven by inputs you do not fully control. CloudTrail records every API call the agent’s role makes. The question worth instrumenting is behavioral: is this agent doing something outside its established pattern? An agent that has only ever read from one table suddenly enumerating buckets, reading secrets, or calling IAM is exactly the anomaly that behavioral monitoring and GuardDuty exist to catch, and because agents settle into fairly regular patterns of use, deviation is a strong signal.

Two practices sharpen the monitoring. First, baseline each agent’s normal set of actions and alert on new API calls it has never made, since the first appearance of an unfamiliar action is often the first sign of a hijack. Second, correlate the agent’s API behavior with its invocation logs, so that when something anomalous happens in CloudTrail you can look at what the agent was asked and what it read, and reconstruct whether an injected instruction drove it. Non-human identities are not exempt from access review either: agent roles should be inventoried, owned, and periodically re-examined for privileges that were granted for a task that no longer exists.

Takeaway

An autonomous AI agent with cloud credentials is not a feature detail; it is a new identity in your account, and the discipline that keeps it safe is the identity discipline you already know. Give every agent its own role, scope that role to the exact task rather than the broad possibility, deliver its permissions through short-lived assumed credentials instead of static keys, isolate the compute and keep irreversible actions behind a checkpoint the model cannot bypass, and monitor the agent’s API behavior for deviation the way you monitor any principal. Do that, and the growing population of non-human principals in your account becomes what it should be: a set of well-scoped, well-watched identities doing bounded work, rather than a fleet of over-privileged deputies waiting for the wrong instruction.