Who is accountable for maintaining least privilege across human and machine identities in cloud platforms?

Accountability usually sits with identity and cloud security leaders, but it must be shared across platform, infrastructure, and application owners. CIEM governance works only when teams define ownership for entitlement reviews, remediation, and exception handling. If no one owns the policy lifecycle, permissions drift, excessive access persists, and compliance evidence becomes unreliable.

Why This Matters for Security Teams

least privilege is easy to endorse and hard to own because cloud access is distributed across identities, control planes, and delivery pipelines. Human users still need role clarity, but machine identities, service accounts, workload tokens, and agent credentials often drift faster than anyone can review. That is why accountability cannot live only in IAM operations: it must be shared with cloud platform owners, application teams, and security leaders who can enforce policy on entitlement creation, approval, and removal.

NHIMG’s research on The 2026 Infrastructure Identity Survey shows the gap clearly: 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments. That matters because static access makes over-permissioning persistent, especially where service accounts and automation pipelines never pass through the same review cycle as employees. Current guidance from OWASP Non-Human Identity Top 10 and NIST SP 800-207 Zero Trust Architecture both point to the same operational reality: access must be continuously verified, not assumed once and forgotten.

In practice, many security teams discover entitlement sprawl only after an audit finding, an incident, or a failed privilege review, rather than through intentional governance.

How It Works in Practice

Accountability for least privilege should be defined as a lifecycle, not a ticket queue. Identity and cloud security leaders usually set the policy, but platform, infrastructure, and application owners must be responsible for the business justification behind each entitlement. That means each team owns different parts of the control surface: who can approve access, who can remediate excessive permissions, and who can explain exceptions when they occur. Without that split, CIEM produces visibility without action.

For cloud platforms, the practical model is to tie every entitlement to an owner, a purpose, and a review cadence. Human identities typically map to job function and manager approval. Machine identities need tighter treatment because workload tokens, service accounts, CI/CD roles, and API keys often have broader reach than a person would ever need. NHI governance research from Ultimate Guide to NHIs Key Challenges and Risks reinforces that machine access is most dangerous when it becomes invisible to the teams that created it. In parallel, the NIST SP 800-53 Rev 5 Security and Privacy Controls family supports explicit access review, separation of duties, and traceable authorization.

• Assign an accountable owner for each identity class: employee, contractor, service account, workload, and agent.
• Require entitlement owners to approve access based on task need, not convenience or default templates.
• Automate continuous review for standing privileges, especially for privileged roles and dormant machine identities.
• Make remediation a platform responsibility and exception approval a security responsibility, with expiry dates attached.

This guidance tends to break down in multi-cloud environments with fragmented IAM providers and unmanaged service accounts because no single team can see all effective permissions at runtime.

Common Variations and Edge Cases

Tighter least-privilege controls often increase operational overhead, requiring organisations to balance faster delivery against stronger entitlement governance. That tradeoff becomes sharper when human and machine identities share the same cloud roles, because one-size-fits-all policies can block automation or create unsafe exceptions. Best practice is evolving, but current guidance suggests separate treatment for human users, workloads, and agents rather than a single access model for all identities.

One edge case is delegated administration, where platform teams create access boundaries but application owners still control the resource-level permissions. Another is ephemeral automation, where access should be short-lived and scoped per job rather than permanently assigned. For those environments, policy should be evaluated at request time and reviewed after execution, not just during onboarding. NHIMG’s coverage of Azure Key Vault privilege escalation exposure and 230M AWS environment compromise shows how quickly excessive privilege becomes systemic when ownership is unclear. Security leaders should treat exceptions as time-bound risk decisions, not permanent design choices.

Where organisations rely on inherited roles, nested groups, or long-lived access keys, accountability often exists on paper but not in the control plane, which is where least privilege actually fails.

Related resources from NHI Mgmt Group

• Who should be accountable for cleaning up inactive identities across cloud platforms?
• Who should own least privilege governance across human and machine identities?
• Who is accountable for securing non-human identities across onboarding, rotation, and offboarding?
• Who is accountable for maintaining right-time, right-level access across cloud and business systems?