Least privilege is a design problem, not an audit finding

The usual sequence: someone builds the thing, it works, and then a policy gets written that describes what it happened to need. That policy is a transcript, not a design.

Start from the blast radius

Before writing any policy, answer one question: if this identity is fully compromised, what is reachable? Not “what does it call” — what is reachable, including everything it can assume, pass, or decrypt.

Answering that early usually changes the architecture rather than the policy. A service that needs iam:PassRole across an account boundary is telling you the boundary is in the wrong place.

Three constraints worth holding

• One identity, one job. Shared roles are how a low-value workload inherits a high-value permission.
• Conditions carry the weight. Resource: "*" with a tight condition key is often safer than a resource list nobody maintains.
• Permission boundaries for anything self-service. If teams create their own roles, the ceiling has to be enforced, not documented.

None of this is exotic. It’s just done at the wrong time, by the wrong person, under deadline — which is why it fails.