Least privilege service identities
Review who can assume the role, not only what it can read
Trust policy and effective resource access form one boundary. Either side can expose data if reviewed in isolation.
In this article
Trace the caller into the workload identity
Identify the service, external identity or deployment context allowed to obtain credentials. Inspect the relevant issuer, audience and subject restrictions for a federated design using the platform's supported guidance.
Avoid trust rules broader than the intended workload merely because several services currently share a repository or account. Their permissions and operational owners may differ.
Test an unintended caller in a controlled environment. A denied resource request does not prove that role assumption itself is appropriately restricted.
Map data access to purpose
List the datasets and operations the workload needs. Separate reading report input, writing output and deleting or administering either resource.
Review decryption and secret access alongside storage permissions. A storage grant may be insufficient without a required key permission, while an overly broad key grant can expand access in ways the storage policy alone does not show.
Keep environment boundaries explicit. A development worker should not receive production authority through a copied resource policy or shared secret.
Inspect privilege-changing paths
Determine whether the workload can alter its own code, pass a more powerful role, modify access policy or obtain another identity. Such capabilities can exceed the apparent reach of its ordinary data permissions.
Evaluate the provider's complete policy model rather than applying one simplified rule to every resource grant. Use supported analysis tools and targeted tests for the relevant configuration.
Record necessary exceptions with their business reason and compensating restrictions. The review should make them visible, not disguise them behind a broad managed policy name.
Verify lifecycle and observability
Confirm how credentials expire or are revoked and how the team identifies the principal in audit records. Logs should support investigation without containing credential values.
Exercise retirement of a synthetic workload and confirm that its unused trust and resource grants are removed. Deleting a compute instance does not necessarily delete its identity.
A complete review can answer who obtains the role, what data it reaches, which privilege-changing actions it can perform and who removes it when its job ends. Those are separate questions with connected consequences.
Primary sources
AWS: IAM security best practicesAWS: policy evaluation logicReferences checked 11 September 2026.