Identity Is Your Cloud Perimeter, and Least Privilege Dies the First Time It Blocks a Deploy

Nobody argues against least privilege. It survives every design review, every policy document and every audit question. Then a deployment fails at four on a Thursday with an access denied error, the release is blocked, the person with permission to widen the role is on the call, and the policy grows by one wildcard. The change ships. The wildcard stays.

That is how least privilege ends in practice. Not through disagreement, and not through a compromise. Through a sequence of small, defensible, individually urgent expansions that nothing in the system ever reverses.

The perimeter moved and the mental model did not

In a data centre, the boundary was physical and topological. Something had to be inside the network to talk to anything. Firewall rules were the control that mattered, and an attacker's first problem was getting network reachability.

In a cloud account there is no inside. The control plane is a public API endpoint, reachable from anywhere, and it authenticates by credential rather than by location. An access key with sufficient permissions does not need to be near your infrastructure to reconfigure it. It does not need to defeat a network control, because network controls are themselves objects the control plane can modify. That inversion is the whole security story, and it is why the cloud control plane is the asset that actually needs protecting rather than the workloads sitting underneath it.

Once you accept that, the question stops being "what is exposed to the internet" and becomes "which identities exist, what can each of them do, and how would we know if one of them did it." Most organisations can answer the first part and not the second two.

Why the failure is a delivery-process failure

The reason least privilege erodes is that permission errors are indistinguishable from bugs at the moment they occur, and the fastest route past them is always to grant more.

Consider the actual mechanics. A pipeline role needs to deploy a change touching a new resource type. Nobody knew in advance which specific API calls the deployment tool would make, because that depends on the tool version, the resource state and whether the change is a create or an update. The error message names one denied action, so someone allows that action. The next call fails on a different action. After the third round trip, somebody grants the whole service namespace, because iterating on policy at deploy time costs more than the narrow policy was ever going to save.

This is rational behaviour under the incentives present. The person widening the policy is measured on the release. The cost of the wide policy is diffuse, deferred, and belongs to nobody in particular. Writing policy that anticipates a deployment's full call graph is genuinely hard, which is why least privilege has to be designed around how delivery actually works rather than imposed as a rule that delivery will route around.

How a permission widens	Trigger	Why it never narrows again
Wildcard added to an action list	Deploy failed on an unknown API call	Nobody knows which of the covered actions are load-bearing
Role reused across two pipelines	Second pipeline needed something similar	Narrowing now risks breaking a service someone else owns
Resource scope changed to all resources	Naming convention changed mid-project	The original scope no longer matches anything
Human granted a pipeline role directly	Incident required manual intervention	The grant was temporary and had no expiry attached
Managed broad policy attached "for now"	Faster than authoring a policy	It works, so no error ever prompts a review

The last row is the quiet one. Nothing fails, so nothing draws attention. A broad policy attached in week one is still attached three years later, and the only artefact recording the decision is a commit message saying "fix permissions".

Workload identity is where this compounds

Human access at least gets reviewed occasionally, because joiners and leavers force the question. Workload identity gets reviewed almost never, and there is far more of it: pipeline roles, service accounts, function execution roles, node roles, pods assuming roles through a federation mechanism nobody on the team fully understands.

Containers make this sharper. A pod that assumes a role gets those permissions for everything running in it, including a dependency pulled in three layers deep that nobody audited. If the node role is broad, every workload on that node inherits reach it was never meant to have, and a container escape becomes a control plane problem rather than a host problem. The specific gap between what a managed cluster secures and what workload identity in managed Kubernetes leaves to you is where the interesting incidents live.

What actually holds

Rules that depend on people choosing the slower option during an incident do not hold. Controls that make the narrow path the fast path do. In rough order of how much they buy you:

1. Make permission requirements discoverable before deploy time. Run the deployment in a mode that records the API calls it makes, then generate the policy from the observed calls rather than from a guess. A policy derived from real behaviour is one nobody needs to widen under pressure.
2. Give every widening an expiry. A temporary grant with no expiry is a permanent grant with an apology attached. If the platform supports time-bound sessions or scheduled policy reversion, use it, because the alternative is a human remembering.
3. Separate the identity that deploys from the identity that runs. A pipeline needs to create and update resources. The running workload needs to read a queue. Merging them gives the workload the pipeline's reach for the entire time it is alive.
4. Remove standing human access to production entirely and replace it with an elevation path that logs. People will accept a slower door if it is the only door and it works reliably. They will not accept one that fails during incidents, so test the elevation path more carefully than you test the policy.
5. Alert on policy widening as an event, not as a periodic audit finding. A quarterly review discovers a wildcard eleven weeks after it mattered. A notification on the change puts it in front of someone while the context is still in their head.

Note that four of those five are about the delivery process rather than about permissions. That is the point. Least privilege is not a configuration state you reach and then hold. It is a property of how your organisation handles the moment when a policy blocks work.

Where to start

Pull the list of identities in one production account, human and non-human, and for each one write down the last time anything about its permissions was deliberately reduced. If the honest answer is never for most of them, you do not have a permissions problem to fix once. You have a ratchet that only turns one way, and the work is installing the mechanism that turns it back.

Doing that without stalling delivery is the hard part, and it is the part our cloud security services are built around: derive the policy from observed behaviour, put expiry on the exceptions, and make the narrow path faster than the wide one.