One Switch, Every Permission

On July 1, AWS taught your applications to wear your employees' faces. And that’s not hyperbole.

IAM Identity Center now let’s server-side applications assume AWS roles on behalf of human users. Flip one setting, "enable AWS account access," and an application can do anything that user can do.

Every account.

Every role.

Every permission.

AWS security researcher Aidan Steele tested it the day it launched, pulled the CloudTrail events, and published field notes that should be required reading before anyone in your organization touches that switch. Because here’s what the launch announcement will not tell you: the feature ships with a real problem baked in, and it lives in the two places auditors care about most. Scope and evidence.

The use case is legitimate…and that's the trap.

Steele's example is one every platform team recognizes.

Your Terraform setup is a straight up nightmare.

Developers can't run it locally. So, you what do you do? You build an internal service to run it for them. And, let me ask you….what permissions does that service need? Answer: A superset of every developer's permissions.

Make it make sense while you are doing the happy dance. Now you have a god-mode service, and you get to build your own authorization logic on top of it.

Ok.

Best case, you perfectly recreate IAM. Worst case? You built a privilege escalation machine and put a friendly UI on it.

But don’t fret! This launch solves that. The service borrows the user's actual permissions instead of hoarding its own.

Elegant. Overdue and genuinely useful.

And… that’s exactly why it will spread through your environment faster than your governance process can spell "risk assessment." Useful features get adopted. Guardrails get requested later, much later.

Problem one: all or nothing

It’s core to unlearning unhealthy thinking in psychotherapy – all or nothing thinking is, well unhealthy.

But I hear you screaming at me, “Yvette there’s no way to scope this. You can’t say "this application may only assume roles in these accounts. You can’t restrict it to specific role names, and you can’t attach a session policy that trims the application down to the subset of permissions it actually needs.”

The switch grants the application everything the user can reach, full stop.

One switch. Every permission the user has. No way to carve out less.

So, you want a restricted version?

Ok, that means your workaround is creating dedicated service users with narrower permission sets. Which also means you are back to managing shadow identities, the exact problem identity federation was supposed to kill. Right?

Problem two: the vanishing application

Now, this is the part that should keep whoever ends up being your SOC lead up when this goes completely and utterly sideways.

The CloudTrail story starts out perfectly fine. The initial token exchange, CreateTokenWithIAM, is attributed to the application's own role. But after that? Well, the application disappears from the record.

Every subsequent event shows the user.

ListAccounts, the user.

GetRoleCredentials, the user.

The actual API calls made with the borrowed credentials? You guessed it! The user.

There’s an onBehalfOf field carrying the user's ID, but no field naming the application that did the borrowing.

Steele's scenario makes it visceral.

• An S3 bucket gets deleted.
• CloudTrail attributes it to “Marcus in engineering.”
• Marcus swears up and down he didn't do it.
• The log says he did.
• And Marcus? Well, he has no way to prove an application acted in his name, and your investigators have no way to identify which application it was.
• The AssumeRoleWithSAML event isn't even reliably linked to the credential request that triggered it.

With the vehement denial from Marcus, what do you do? Well, what’s left is basically guess by matching timestamps. But I’m here to tell you; guessing is NOT forensics.

An audit trail that names the wrong actor is worse than no trail at all. It manufactures false confidence and false confidence is what you sign your name to when the regulator calls.

PSSTTT…We’ve seen this movie

AWS ships minimum viable products and iterates.

You don’t get to publicly state “AWS launches thousands of new features every year across its services” without it.

Sometimes that works beautifully and sometimes you get Control Tower v1, which the community roasted for YEARS before it became usable. Steele himself, a person who has wanted this exact feature for years, says he'll use it for hobby projects and skip it at his day job until the controls exist. When the researcher who loves the feature won't run it at work, believe him.

But here’s the bigger picture. This is below bar agent identity plumbing, arriving precisely as enterprises wire agents into everything. I wrote recently that cybersecurity owns whether AI can safely act, and product owns whether it acts correctly. You can’t own "safely act" without evidence of who acted. A delegation feature with broken attribution hands your agents human faces and hands your SOC a blindfold. That blast radius? Is by design.

What to do this week

1. Find the switch. Inventory who in your org can enable account access for customer managed applications. Restrict it now, before a platform team discovers the feature on their own.
2. If you absolutely must use it, shrink the identity. Dedicated service users with minimal permission sets. Ugly, absolutely. What’s even uglier? An untraceable admin access?
3. Force self-identification. Require every internal application to declare itself in the userAgent string. Weak evidence beats none.
4. Build the detection. Alert on CreateTokenWithIAM events. That’s your ONE clean, waving the flag signal that an application started impersonating a human. Treat it like the crown jewel that it is.
5. File the feature requests. Session policies for delegated access. An applicationArn field in onBehalfOf. AWS iterates on noise. So, be the noise.

The switch exists in your environment today. Somebody is going to find it. The only question is whether security finds it first.

So, go find it.