Key takeaway: Over-permissioning is a ratchet. Broadening a policy resolves an outage immediately; narrowing it risks one, so it never happens without a deliberate mechanism.
How Policies Actually Widen
The sequence is familiar. A deploy fails with an access denied error. Someone under pressure adds the specific action. It fails again on a different action. They add s3:*. It works. The incident closes.
Nobody returns to narrow it, because the only visible outcome of narrowing is the risk of breaking something that currently works. The reward is invisible, the risk is concrete, and the ratchet clicks one notch wider.
Repeat across a few years and several teams, and roles accumulate permissions nobody can justify — held by workloads that would function with a fraction of them.
Why It Matters Concretely
An over-permissioned role converts a small compromise into a large one. A leaked credential for a service that only needs to read one bucket is a contained problem. The same credential attached to s3:* across the account is a data breach.
The pattern that matters most is privilege escalation through IAM itself. A role holding iam:PassRole or iam:CreatePolicyVersion can grant itself anything. Those permissions look innocuous in a policy listing and are equivalent to administrator access.
Working Backwards From Reality
The effective approach is to derive policies from observed behaviour rather than from guesses.
| Method | What it gives you |
|---|---|
| Access Analyzer from CloudTrail | A policy containing exactly what the role used |
| Service last-accessed data | Which granted services were never touched |
| Permissions boundaries | A hard ceiling regardless of attached policies |
| Deny-by-default SCPs | Guardrails no individual policy can exceed |
Generating a policy from ninety days of actual API calls produces something far tighter than anyone would write by hand, and it is grounded in evidence rather than assumption. The caveat is coverage: rarely exercised paths — a quarterly job, a disaster recovery procedure — may not appear in the window. Review generated policies for those gaps rather than applying them blindly.
Making Narrowing Safe
The reason nobody tightens policies is fear of breakage, so remove the fear.
Deploy the narrowed policy to a non-production environment first and run the full workload. Then, in production, use CloudTrail to look for denials rather than waiting for user reports. Some organisations run a shadow evaluation period where the tighter policy is analysed against live traffic without being enforced.
Resource-level scoping usually delivers more risk reduction than action-level scoping. Restricting s3:GetObject to one bucket ARN matters more than enumerating individual actions across all buckets.
The Bottom Line
Treat IAM as code with review, generate policies from observed access, and schedule a recurring review that removes never-used permissions. Without a scheduled mechanism the ratchet only turns one direction.
