A VPC controls what network traffic can reach a resource. Identity and access management (IAM) controls a different, equally important question: once something can reach a resource, what is it actually allowed to do to it? Getting IAM wrong is one of the most common — and most consequential — categories of cloud misconfiguration.

What IAM actually governs

Cloud IAM systems govern three related things: authentication (confirming an identity is who it claims to be), authorization (determining what that identity is allowed to do), and the identities themselves — which include not just human users, but service accounts, applications, and infrastructure components that need to call cloud APIs on their own behalf. A modern cloud environment typically has far more non-human identities than human ones, since every piece of automated infrastructure that calls a provider’s API needs its own identity and its own permissions.

The principle of least privilege

Least privilege is a security principle stating that any identity — human or otherwise — should be granted only the specific permissions it actually needs to perform its function, and nothing more. NIST’s glossary entry for least privilege defines it in essentially these terms: the security objective of granting a system entity only the access necessary to perform its assigned functions.

The principle is simple to state and consistently hard to apply in practice, for a specific, recurring reason: it’s usually much faster, in the moment, to grant broad permissions (“just give it admin access”) than to work out the precise, minimal set of permissions a given task actually requires. That shortcut accumulates over time into broad, unaudited access that nobody remembers granting or why, which is exactly the gap attackers and automated scanners look for.

Common ways over-permissioning happens

  • “Just get it working” grants. Under time pressure, granting broad access to unblock a task is faster than scoping permissions precisely, with the intention to “fix it later” — a fix that often never happens.
  • Permissions that outlive their purpose. An identity granted access for a specific, time-limited task that’s never revoked once the task is done.
  • Copy-pasted policies. Reusing an existing, already-overly-broad permission policy as a starting point for a new identity, rather than defining the new identity’s actual minimal needs from scratch.
  • Service accounts with standing broad access, used by automated infrastructure — including CI/CD pipelines, discussed in What Is CI/CD? — that only actually needs narrow, specific permissions for its actual job, which matters even more once secrets and credentials are involved, covered in Secrets Management in CI/CD Pipelines.

AWS’s own IAM best practices documentation recommends addressing this directly: granting only the permissions required to perform a specific task, and using tools to identify and remove unused permissions over time, rather than treating an initial grant as permanent.

Why this is a continuous practice, not a one-time setup

Least privilege isn’t a configuration you set once. Systems and their permission needs change constantly — new services are added, old ones are decommissioned, people change roles — and permissions granted for a need that no longer exists don’t automatically expire on their own. Periodically auditing actual usage against granted permissions, and removing what isn’t being used, is the only way least privilege stays true over time rather than degrading back toward the broad-access default it was meant to avoid.

Key takeaway

Cloud IAM determines what an authenticated identity is allowed to do, and least privilege is the standard that identity should be granted only what it actually needs — a principle that’s easy to agree with and consistently hard to maintain, because the path of least resistance under time pressure almost always leads toward broader access, not narrower. Treating permission scoping as an ongoing audit, not a one-time setup step, is what keeps the gap between granted and actually-needed access from quietly widening.

This article explains general cloud security concepts; specific IAM features and defaults vary by provider. See our disclaimer.