Unused cloud permissions are widening enterprise blast radius

At a glance

What this is: This is an analysis of why unused cloud permissions persist and how that hidden privilege expands enterprise attack surface, with most inactive access concentrated in machine identities.

Why it matters: It matters because IAM, PAM, and cloud security teams must govern non-human identities as active privilege holders, not as one-off exceptions, or overprovisioned access will keep compounding risk.

By the numbers:

• Sonrai Security says 92% of all identities with access to sensitive permissions did not use them over 90 days.
• Sonrai Security says 87% of that inactive access was tied to machine identities.
• The global average cost of a data breach was $4.44 million in 2025, according to IBM.

👉 Read Sonrai Security's analysis of why 92% of cloud permissions go unused

Context

Unused cloud permissions are not just a hygiene issue. In practice, they are a structural IAM problem created when roles, service accounts, integrations, and pipeline credentials accumulate more access than they use, then remain in place long after the original business need has disappeared.

In cloud estates, that residual access becomes a standing expansion of blast radius for both human and non-human identities. The governance challenge is not simply visibility. It is deciding how to reduce privilege without breaking production, especially where machine identities now dominate the privileged access surface.

Key questions

Q: How should security teams reduce unused cloud permissions without breaking workloads?

A: Start by identifying permissions that have not been used over a meaningful window, then quarantine them rather than deleting identities outright. Preserve the account or role object, strip standing access, and require a request-and-approve path for any legitimate exception. This approach reduces blast radius while keeping recovery options available for undocumented or intermittent jobs.

Q: Why do non-human identities accumulate more unused privilege than human users?

A: Non-human identities are often created quickly for pipelines, integrations, and vendors, then left behind after the original work changes. They are rarely subject to the same review cadence as employees, so permissions copied in at deployment time remain in place. In cloud estates, that turns convenience into persistent overprovisioning.

Q: What breaks when just-in-time access is applied only to users and not permissions?

A: The permission surface stays standing even if the login path is gated. That means any compromised credential tied to the role can still invoke unused rights the identity does not actually need. Real JIT reduces exposure only when the privilege itself is absent until a task requires it.

Q: How do IAM teams know whether cloud least privilege is actually working?

A: They should look for declining counts of dormant privileges, fewer overprivileged machine identities, and a measurable shift from standing access to task-scoped access. If access reviews keep approving broad roles without evidence of recent use, the programme is documenting risk rather than reducing it.

Technical breakdown

Why cloud permission sprawl persists in non-human identities

Cloud permission sprawl emerges when access is granted broadly at deployment time, then copied forward through templates, inherited roles, and undocumented integrations. Non-human identities are especially exposed because they are provisioned for tasks, not reviewed like employees, and their permissions often outlive the project, pipeline, or vendor relationship that created them. Over time, policy documents drift away from actual runtime behaviour, so the identity estate looks controlled on paper but not in practice.

Practical implication: teams need usage-based visibility before they can safely remove standing permissions.

Why legacy PAM does not solve cloud least privilege

Traditional PAM was built around a small population of named privileged accounts, usually human-administered and clearly bounded. Cloud estates are different because privileged capability can sit inside service accounts, roles, tokens, and automation paths that are not obvious from account labels alone. If the control only gates login, it leaves the permission itself standing. That is why legacy PAM can reduce access frequency without reducing the underlying privilege surface.

Practical implication: review the privilege model, not just privileged login workflows.

How just-in-time access should move from users to permissions

Just-in-time access is most effective when the privilege itself is absent until the task requires it. In cloud terms, that means sensitive permissions are denied by default, granted for a specific operation, then removed when the task ends. This is materially different from putting a human through an approval queue while the role remains over-permissioned. The control target shifts from who can log in to what the identity can do at a given moment.

Practical implication: make ephemeral access the default for high-impact actions, including for machine identities.

Threat narrative

Attacker objective: The attacker wants to turn one compromised cloud identity into broad access across resources the legitimate workload never actually uses.

1. Entry occurs when a compromised credential belongs to an overprivileged identity whose unused permissions were never removed from the cloud estate.
2. Escalation follows when the attacker discovers that the identity can reach sensitive resources far beyond the permissions it actually needs.
3. Impact occurs when those standing privileges allow lateral movement, destructive actions, or data exposure that would not have been possible under a least-privilege model.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unused privilege is the identity security debt that cloud teams keep rolling forward. When 92% of sensitive permissions sit unused for 90 days, the environment is not merely noisy. It is accumulating dormant blast radius that survives long after the business justification is gone. That makes access review a lagging signal, not a preventive one, because the estate has already grown beyond what manual governance can reliably rationalise. The practitioner conclusion is simple: unused access must be treated as a standing liability, not a housekeeping task.

Machine identities now dominate the unused-permission problem, which means NHI governance is the centre of gravity. Sonrai Security’s analysis shows that 87% of inactive access in this sample belonged to machine identities, not people. That changes the control question from employee lifecycle management to runtime privilege governance for service accounts, integrations, and pipelines. The implication for security programmes is that human-centric review processes will keep missing the bulk of exposure unless they are redesigned around non-human behaviour.

Standing privilege was designed for environments where access could be reviewed after the fact. That assumption fails when cloud permissions are continuously inherited, copied, and left in place across machine identities that do not naturally signal when they no longer need access. The implication is that identity governance has to stop assuming stable entitlement boundaries and start treating runtime usage as the only reliable proof of need.

Quarantine is becoming the more realistic governance pattern for cloud privilege than deletion. Removing identities entirely is often too disruptive when ownership is unclear or when an integration still depends on the object existing. Preserving the identity while stripping unused rights reflects how cloud operations actually behave. For practitioners, that means the market is moving toward access suppression and temporary re-grant workflows rather than all-or-nothing cleanup campaigns.

Identity teams should expect least privilege to be measured in operational friction, not policy elegance. A model that looks clean on a slide but breaks workloads is not a usable model. The real test is whether an organisation can remove dormant privilege without creating a production exception pathway that quietly restores it. The practitioner conclusion is that effective least privilege must be enforceable, observable, and reversible at scale.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader view of how this problem scales across estates, the 2026 Infrastructure Identity Survey shows how access overgranting and weak policy adoption are already reshaping identity governance.

What this signals

Unused privilege is converging with agentic AI governance, so identity programmes can no longer treat machine access as a static inventory problem. With 70% of organisations already granting AI systems more access than they would give a human employee performing the same job, per the 2026 Infrastructure Identity Survey, the same overprovisioning logic that inflates cloud blast radius is now being imported into agentic workflows.

Practical programme impact: teams should expect access review, entitlement suppression, and usage-based governance to become the default control pattern for both cloud roles and autonomous systems. That pushes IAM, PAM, and platform engineering into the same operating model, where privilege is only defensible if it is both observable and time-bounded.

For practitioners

• Inventory sensitive permissions by actual use Correlate cloud entitlement data with 90-day usage history so you can separate active privilege from standing residue. Focus first on service accounts, pipeline roles, vendor integrations, and test environments.
• Quarantine unused access before deleting identities Strip permissions through policy while preserving the identity object, then route any legitimate break-glass request through an approval workflow. This reduces the chance of breaking undocumented workloads.
• Move JIT controls to the permission layer Grant sensitive capabilities only for the duration of a task, then revoke them automatically when the task closes. Use this model for both human operators and machine identities that handle high-impact actions.
• Rebuild access reviews around runtime evidence Require proof of recent use, owner validation, and workload relevance before certifying privileged access. A role that has not been exercised should not be recertified by default.
• Use NHI-specific governance for cloud roles Treat service accounts and automation identities as first-class identities with ownership, purpose, and expiry criteria. That gives PAM and IAM teams a consistent way to assess inherited cloud access.

Key takeaways

• Unused cloud permissions create a large standing blast radius, especially where machine identities hold privileges they never exercise.
• The scale of the problem is operational, not theoretical, because overprovisioned access multiplies breach cost, audit exposure, and cleanup effort.
• Effective governance now depends on usage-based enforcement, quarantine-first cleanup, and just-in-time access at the permission layer.

Key terms

• Unused Privilege: Unused privilege is access that remains granted even though the identity has not exercised it over a defined period. In cloud and NHI programmes, it is a governance debt that expands blast radius, complicates reviews, and creates opportunities for compromise without adding business value.
• Quarantine Access: Quarantine access means stripping an identity’s permissions while preserving the identity object itself. The identity stays available for recovery or rare use, but its standing rights are removed so teams can reduce risk without deleting potentially needed workloads or integrations.
• Permission Layer Just-in-Time: Permission layer just-in-time is a model where the privilege itself is granted only for the duration of a task, then removed automatically. For machine identities and cloud roles, this is more effective than gating login because it reduces the exposed capability, not just the access path.

Deepen your knowledge

Cloud least privilege and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to reduce standing cloud privilege without disrupting production, it is a useful starting point.

This post draws on content published by Sonrai Security: Why 92% of Cloud Permissions Are Never Used, and What That Costs You. Read the original.