Your AI Agents Have More AWS Access Than Your Engineers Do

If you've deployed a Bedrock agent, hooked a coding assistant up to your AWS account, or let a workflow automation tool spin up its own IAM role this year, there's a good chance it can do more in your AWS environment than the person who built it.

In a Cloud Security Alliance study published this year, 53% of organizations said their AI agents had exceeded their intended permissions, and 47% had already had a security incident involving one. Non-human identities — service accounts, agents, and automation roles — now outnumber human identities in the average enterprise; different studies put the ratio anywhere from roughly 45 to 1 to over 80 to 1, and the exact multiple matters less than the direction: it's large, and growing. Researchers separately estimate that over 90% of the permissions attached to those identities go unused.

We're starting to see the AWS-specific version of this in our own security reviews: agent roles built from a copy-pasted IAM template, attached to a Bedrock agent or a CI/CD pipeline, and never touched again. It's the same root cause as the IAM misconfigurations we've written about before — permissions granted for convenience and never revisited — but the blast radius is bigger, because the thing holding the permissions doesn't get tired, doesn't take leave, and doesn't ask “wait, why do I have this?”

Why agent roles end up over-permissioned

It's rarely a single bad decision. It's a handful of small, reasonable-sounding ones that compound.

• Teams reuse IAM templates across agents. The fastest way to stand up a new agent's permissions is to copy the role from the last one and tweak it — which is how a role scoped for “read from this S3 bucket” quietly becomes a role with broad S3, Lambda, and Secrets Manager access across three different agents that never needed all of it.
• There's no offboarding process for a role. A human who changes teams gets their access reviewed, at least in theory. An agent's IAM role has no equivalent trigger — when the project it was built for wraps up, the role usually just stays attached, active, and unreviewed, sometimes for months.
• The agent can end up with more access than the person who built it. A developer with scoped, read-mostly access can configure an agent that assumes a role with write access, cross-service permissions, or the ability to call other AWS APIs on its own — the agent isn't bound by the human's access ceiling, it has its own, and it's often higher.
• Permissions get granted for the “just in case” path, not the actual one. When you're not sure exactly which API calls an agent will need in production, it's tempting to attach a broader managed policy rather than work out the precise action list — a decision that usually never gets revisited once the agent is working.

What this looks like in an AWS account

In practice, this shows up as things like:

• A Bedrock agent execution role with s3:* on a bucket when the agent only ever needs s3:GetObject on a handful of prefixes.
• An automation role that can invoke Lambda functions across the whole account instead of the one function it's meant to trigger.
• A coding-assistant integration with a long-lived IAM user key instead of a scoped, temporary role.
• Multiple agents sharing a single broad role because it was “already set up.”

None of these are exotic. They're the same shape of problem as the S3 misconfigurations and IAM policies we've flagged before — just attached to something that runs autonomously instead of something a person logs into.

How to fix it without slowing your team down

• Scope one role per agent, per workload. Shared roles are where permission creep hides — if an agent's job is to read from one bucket and write to one table, its role should say exactly that, nothing more.
• Use permissions boundaries, not just policies. A permissions boundary caps what a role can ever be granted, even if someone later attaches a broader policy to it by mistake.
• Make agent roles time-bound where you can. Just-in-time or session-based credentials mean an agent that's compromised or misbehaving loses its access automatically, rather than holding a standing role indefinitely.
• Quarantine roles instead of leaving them live. When a project ends or an agent is retired, move its role to a deny-by-default state rather than just leaving it alone — “unused but still active” is exactly the state that shows up in an audit six months later as a live risk.
• Actually look at what the agent uses, not what it was granted. CloudTrail will tell you which actions an agent's role has actually called over the last 30-90 days — if the answer is a fraction of what the policy allows, that's your remediation list.
• Give agent roles the same review cadence as human access. If you already have a quarterly access review for your team, add service and agent roles to it — most teams don't, which is exactly why the gap exists.

Where to start

If you've deployed any AI agents against your AWS account in the last year — Bedrock, a coding assistant, an automation tool, anything with its own IAM role — it's worth a 15-minute check: pull up the role, compare its attached policy to what CloudTrail shows it actually calling, and see how far apart they are. For most teams we work with, that gap is the finding.

This is exactly the kind of thing our AWS Security & Architecture Review is built to catch — we'll map every role in your account, including agent and service roles, against what it's actually using, and hand you a prioritized list of what to fix first.