Least privilege that survives contact with delivery

Why does least privilege usually fail?

Because the cost of an over-broad grant is invisible and the cost of a missing one is a blocked release. A developer who cannot deploy at four on a Friday will attach a broader policy, and that decision is rational in the moment and permanent afterwards. Nothing in the system ever comes back to say the extra permissions were unused, so the estate accumulates access monotonically until someone runs an audit.

The second cause is that nobody knows which permissions an application needs before it runs. Least privilege written from a design document is a guess, and the guess is either too tight, producing failures in staging that get resolved by widening, or too loose, in which case it was never least privilege. Permissions are discovered empirically, which means the process has to include a narrowing step after the workload is live.

So judge any least privilege programme by two things: whether it has a mechanism that reduces permissions after the fact, and how long it takes to get a legitimate new permission approved. If elevation takes two days and admin takes ten minutes, the outcome is already decided regardless of what the policy says.

What does identity as the perimeter actually mean?

That there is no network position to defend, so a valid credential is the whole of access control. Every action against a cloud account, creating a machine, reading an object, changing a firewall rule, is an authenticated API call to a public endpoint. An attacker with a working key does not need to be inside anything. They are as inside as your deployment pipeline is, from anywhere, and the only checks applied are the authorisation policies attached to that identity.

This is why credential lifetime dominates every other identity control. A long-lived access key in a developer's home directory, a CI variable or a container image is a permanent grant to whoever finds it, and it will still work months later. A short-lived session token obtained through federation expires whether or not anybody notices the leak, which converts a breach into a window rather than a standing entitlement.

The practical implication is that removing static keys is usually a bigger risk reduction than refining policy documents. Workload identity federation, where a pipeline or a workload proves what it is with a signed token from its own platform and exchanges it for a short-lived cloud credential, removes the asset an attacker most wants. It is available on all the major providers and is now the default recommendation rather than an advanced technique.

Which credential types carry which risk?

Treat the credential type as the primary variable, because it determines what a compromise costs you. The permissions attached matter, but the lifetime and the number of copies in existence determine whether you are dealing with an incident or an ongoing exposure.

Which permissions matter more than the others?

The ones that let an identity grant itself more permission. Read access to a data store is a data risk, and it is bounded. The ability to modify policy is unbounded, because it converts any foothold into full control of the account, and it is routinely handed out inside broad administrative grants without anyone intending it.

Name them explicitly in your model. On AWS that includes attaching or versioning policies, updating a role's trust policy, passing a role to a service that runs code, and creating access keys for another user. On Azure it includes the Owner and User Access Administrator roles, and anything that can write role assignments. On Google Cloud it includes setting IAM policy on a project and acting as a service account. Each of those is an escalation primitive on its own.

The second category is anything that can run code on a machine that already holds an identity, such as remote command execution through the provider's management agent, or the ability to create a compute resource and attach an existing role to it. Both bypass policy entirely by borrowing another identity's permissions, which is why they belong in the same tier as policy modification rather than in a general compute grant.

What guardrails hold under delivery pressure?

Denials enforced above the account, because those are the only ones a team under pressure cannot edit their way around. Organisation-level policy that denies changes to logging configuration, denies use of regions you do not operate in, denies deletion of security tooling roles and denies disabling of key protections applies even to an account administrator, and it costs nothing in delivery speed because it blocks actions nobody legitimately needs.

Then separate the ability to grant permissions from the ability to use them. Delivery teams get generous permissions inside their own boundary and no ability to widen that boundary, while the widening is a small, reviewed, and preferably automated request handled by a platform or security function. This is the arrangement that removes the incentive to hoard access, because getting more is quick.

Time-limited elevation completes it. A named engineer requests an elevated role with a stated reason, holds it for a few hours, and it expires without anybody chasing them. Providers ship mechanisms for this, and the important detail is not the tool but the expiry: permanent elevation granted during an incident is the most common origin of the standing administrator accounts an audit later finds.

What can you check this week?

Run three queries. List every identity with an administrative or wildcard grant and ask, for each, what would break if it were narrowed. List every long-lived access key with its age and its last-used date, because keys unused for months are pure exposure and delete cleanly. And list every role whose trust policy allows an external party or a whole repository namespace to assume it, which is the misconfiguration that turns a public pipeline into a route into your account.

Then use the providers' own unused-access reporting, which compares granted permissions against actually used ones over a window. It is the narrowing mechanism most estates lack, and it turns least privilege from an argument about intent into a report you can act on. Start with the identities that hold escalation permissions rather than the noisiest ones.

The single most revealing test takes ten minutes: try to use your deployment pipeline's credential to modify its own permissions. If it succeeds, the pipeline is an administrator with extra steps, and every dependency in every build is now part of your access control model.