Cloud Computing: The IAM Policy Loophole That Can Let Interns Delete Your Entire AWS Account

1. The Danger of the Asterisk (*): “Just Let Them Do Everything in Dev, Right?”

In an ideal world, developers get only the permissions they need, scoped tightly to the services and resources they actually use.

In reality?

Because you’re in a rush and facing deadlines. So you do the thing we’ve all done at least once.

{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}

Maybe you wrap it in a condition, or perhaps you don’t. Maybe you tell yourself it’s temporary, or you’ll “fix it later.” But we both know you won’t. This “quick fix” is the IAM version of duct taping a fuel line on a rocket.

The wildcard (*) is seductive. It’s fast, it works, and it breaks nothing — until it breaks everything.

2. Overly Permissive Roles: The “Trust Too Much” Trap

Let’s say you don’t go full wildcard. You create a role for the intern that only allows EC2 actions. Sounds responsible, right? But did you check the trust policy?

If your intern’s role can assume other roles with elevated privileges, congratulations: they can chain-role-hop their way straight into your production account.

The magic often happens like this:

{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*"
}

Oh, great. Now your intern can assume any role they can see , including ones that can delete your VPC, RDS instances, or, hell, the S3 bucket holding your backups.

3. Missing Condition Keys: The Security You Didn’t Know You Forgot

Here’s the underdog issue that bites hard: missing condition keys.

IAM policies are like polite bouncers. They’ll check the ID (the action) and maybe the club name (the resource), but if you forget to tell them which entrance (condition) matters, anyone with credentials gets in.

Condition keys like aws:RequestedRegion, aws:SourceIp, or aws:MultiFactorAuthPresent aren’t just security theater. They enforce contextual access.

Without them, your intern working from their laptop in your office can also act from a VPN in a random country. And guess what? That same s3:* permission you gave “just for logs”? Now it’s being used from someone’s Chrome browser at 3 am on a Sunday.

4. Least Privilege Is Not a Vibe — It’s a Commitment

IAM is like brushing your teeth. Do it wrong and things rot. But unlike teeth, your AWS environment doesn’t give you cavities — it gives you catastrophic data loss.

And while we all say we believe in least privilege, here’s the truth: in 99% of orgs, IAM is a dumpster fire of copy-pasted policies, half-written Terraform, and panic-driven role creation.

If you’re treating IAM as an afterthought, you’re building a mansion and

5. So, How Do You Fix It?

Here’s the no-fluff answer:

Never use * in production IAM policies. Ever. If you need to experiment, isolate it to non-prod, monitored sandboxes.
Scope your STS: AssumeRole actions to specific ARNs and use condition blocks to narrow use.
Use IAM Access Analyzer. It’s not perfect, but it will highlight roles that are more open than a midnight Waffle House.
Tag and monitor roles. Know who owns what. Alert when someone edits a product policy.
Build IAM policies like code, not like documentation. Use frameworks like AWS CDK, or Terraform to make changes repeatable and reviewable.
Train your team. IAM is not just for security engineers. It’s for every dev who’s ever run aws configure.