# IAM Review Checklist

> **Intro:** This checklist focuses on human and non-human access, trust policies, privilege boundaries, and the path by which powerful actions happen.

## Best time to use this checklist

Use it for new roles, service accounts, federation trust, break-glass paths, admin workflows, and platform changes.

## Stop-the-line conditions

* wildcard or broad admin privilege without strong business justification;
* long-lived static credentials for automation where federation is possible;
* unclear mapping between identity, owner, and purpose;
* transitive trust that lets one compromised system pivot into another.

## Text-first review prompts

* Which actor or workload identity is using this permission?
* Is the privilege scoped to specific resources, actions, and environments?
* What trust assumption lets this identity exist or assume a more powerful role?
* How short-lived is the credential material?
* What logs prove that the identity acted, and what alerts watch for misuse?
* What would an attacker gain if this identity were compromised?

## Evidence table

| Control area        | What to verify                                                   | Typical evidence             |
| ------------------- | ---------------------------------------------------------------- | ---------------------------- |
| Identity purpose    | Every identity has a clear owner and business purpose            | IAM inventory, owner mapping |
| Privilege scope     | Permissions are limited to required actions and resources        | policy review, diff          |
| Trust               | Federation, assume-role, and service-account trust is understood | trust policy, OIDC config    |
| Credential lifetime | Short-lived credentials are used where possible                  | STS config, token lifetime   |
| Detection           | Use of privileged identities is logged and monitored             | audit logs, detections       |

## Common misses

* reviewing permissions without reviewing trust relationships;
* ignoring who can edit the role instead of who can use the role;
* failing to separate development and production authority;
* forgetting that an overpowered CI identity is often a production risk, not only a build risk.

## Related pages

* [Workload Federation and Non-Human Identities](/architecture-api-crypto-and-identity/index-2/workload-federation-and-non-human-identities.md)
* [Cloud Change Review Checklist](/learning-labs-interview-and-templates/index-3/cloud-change-review-checklist.md)
* [Provider-Specific Cloud Attack Chains](/attack-paths-testing-detection-and-hardening/index-1/cloud-attack-chains.md)

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/learning-labs-interview-and-templates/index-3/iam-review-checklist.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.