CASE 98 · WILDER · 2026
Developers who can create IAM roles, safely.
A developer tools company had a "no, we won’t give you IAM:CreateRole permissions" stance from the security team and a "we file two tickets a week for new IAM roles" stance from the engineering team. We resolved it with IAM permission boundaries — engineers can create roles, but only roles bounded by a security-approved policy.
Developer tools
SECURITY
2026
RESULTS
What changed, by the numbers.
IAM-TICKET QUEUE
−92%
BOUNDED ROLES CREATED
127
OUT-OF-BOUND ATTEMPTS
23 BLOCKED
PRIVILEGE ESCALATION FINDINGS
0
HOW IT WENT
The security team’s reluctance was rational: a developer with `iam:CreateRole` can create roles with `*` permissions and effectively escalate privilege. The engineering team’s reluctance was also rational: filing a ticket for every IAM role is slow.
Permission boundaries split the difference. We crafted a boundary policy that defined the maximum permissions any developer-created role could have. Developers got `iam:CreateRole` and `iam:AttachRolePolicy` — but only if the role being created had the approved boundary attached. The security team kept the keys to the boundary itself.
Engineers created 127 bounded roles in 90 days. Twenty-three out-of-bound attempts (legitimate developers trying to attach a policy outside the boundary) failed safely with a clear error message. Zero privilege-escalation findings from Access Analyzer post-rollout.
RELATED · SAME DOMAIN
Other engagements in this space.
READY WHEN YOU ARE
Let's get your AWS bill (and architecture) in order.
The discovery call is free. You walk away with at least one concrete idea — even if we never work together.