Most IAM policies in 2026 are written the way the IAM team learned to write them, which is to say they are written to satisfy the auditor and not the attacker. The result is a sprawl of over privileged roles, a stack of unused permissions, and a service account inventory that has not been touched since the cloud account was created. The field guide to writing IAM policies that actually do the job.
AWS IAM has 14,000+ actions. Azure RBAC has 4,000+ built in roles. GCP IAM has 3,500+ roles. The number of ways to combine them into an effective policy is in the millions. The number of ways to write a policy that looks compliant and is actually over privileged is also in the millions. The field guide covers the four patterns that show up in 80% of the over privileged policies, and what to do about them.
The four patterns that get IAM wrong
Four patterns, in roughly that order of how often they show up in incident post mortems. Wildcard action, where the policy uses * instead of the specific actions, usually because the original author was not sure which specific actions the role needed. Resource wildcard, where the policy uses arn:aws:s3:::* instead of the specific bucket, usually because the author did not know which bucket the role would end up needing. Conditionless policy, where the policy does not have any conditions on when the actions can be taken, usually because the author did not think about the condition at all. Inherited permission, where the role inherits permissions from a parent role or a group, and the author never checked what those inherited permissions actually are.
How to write policies that work
Four moves, in order of impact. Start with the specific actions, the specific resources, and the specific conditions, and only widen the policy when there is a documented reason to widen it. Use the access analyzer tools (AWS IAM Access Analyzer, Azure Permissions Management, GCP IAM Recommender) to identify the permissions that are actually being used, and to remove the ones that are not. Write the policy in a way that is reviewable, which means the policy file is in version control, the policy has a comment that explains why each permission is there, and the policy has a TTL that forces a re review. Test the policy before it goes live, which means the IAM team can answer the question what does this role actually have access to with a tool, not with a guess.
What good looks like in practice
Three things to look for. A permissions boundary that the production roles operate inside, which limits the blast radius when a credential is compromised. A separation of duties between the person who can create the role, the person who can assign the role, and the person who can use the role, which is the kind of thing that prevents the kind of incident where one person had all the power. An inventory of every role, every permission, every resource, and every condition, that gets reviewed quarterly. Not annually. Quarterly.
The bottom line
Most IAM policies are written to satisfy the auditor, not the attacker. The four patterns that get IAM wrong are the wildcard action, the resource wildcard, the conditionless policy, and the inherited permission. The moves that get it right are start specific, use the access analyzers, write for review, and test before live.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
