Least privilege service identities
Count unexplained permissions, not just wildcard characters
Permission quality depends on purpose, effective reach and tested boundaries. A policy can avoid an asterisk and still grant the wrong service too much authority.
In this article
Measure coverage of the operation inventory
Track whether each production workload has a named owner, purpose and mapping from required operations to permissions. Missing ownership is a review gap even when the current policy looks narrow.
Include trust relationships and deployment identity, not only runtime action lists. A service can inherit risk through who may assume it or change its code.
Record provider actions that genuinely require broader resource scope with their justification. A raw wildcard count can punish necessary service semantics while missing more consequential grants elsewhere.
Verify allowed and denied behaviour
For each important boundary, maintain a positive test and a deliberate negative case. The report worker should write its intended output and fail to modify unrelated source data.
Measure whether the tests run under the actual workload principal. Developer-credential success does not establish that production identity is configured correctly.
Keep effective-policy analysis in the evidence where supported. Other policies may introduce grants or denials absent from the file being reviewed.
Track exceptions and unused access
Review unused identities and permissions using activity evidence, while accounting for infrequent jobs and recovery paths. A quiet month does not prove a quarterly operation is obsolete.
Give exceptions an owner, reason and revisit date. Report their age and unresolved scope rather than burying them in a general accepted-risk category.
An illustrative inventory contains thirty roles, two retired workers and one temporary broad grant. The useful action is to retire the unused roles and resolve the exception, not merely report that twenty-seven roles pass a syntax check.
Keep operational failures visible
Monitor access denials after policy changes and classify them by intended operation. A surge can reveal an omitted recovery permission or an unexpected new behaviour in the application.
Do not optimise for zero denials at any cost. A prohibited request being denied is the desired result, while a required task failing needs a scoped correction.
Acceptance should show explained authority, verified boundaries and a workable lifecycle. The objective is not the smallest policy file, but the smallest justified effective access that supports the service's agreed work.
Primary sources
AWS: IAM security best practicesAWS: policy evaluation logicReferences checked 11 September 2026.