Who is accountable when a user can both request and approve privileged access?

Why This Matters for Security Teams

When one identity can request privileged access and also approve it, accountability becomes a governance problem, not just an IAM problem. The failure is usually not a missing login prompt; it is a control design that lets a single actor shape both the approval path and the execution path. That collapses separation of duties, weakens auditability, and makes privileged access reviews less meaningful. In practice, many security teams only discover the issue after an access recertification, an incident review, or a control failure linked to a broader privileged access workflow. The NHI context makes this more serious because service accounts, automation, and privileged workflows often move faster than human review. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is why governance has to focus on the workflow, not the user’s intent. OWASP’s OWASP Non-Human Identity Top 10 similarly treats over-permissioning and weak lifecycle control as recurring failure modes. The accountable party is the governance owner, but the real remediation is to remove the possibility of self-approval in the first place. In practice, many security teams encounter this only after privileged access has already been granted and used, rather than through intentional policy design.

How It Works in Practice

Accountability should be assigned to the person or function that owns the access-control design, approval rules, and exception handling. That usually means IAM governance, PAM governance, or the service owner with explicit control accountability. The approved state must be enforced by workflow, not by trust in the requester. For privileged access, the safest pattern is to separate request, approval, and execution so no single identity can complete all three steps. This is especially important where NHIs, agents, or automation platforms can act faster than human oversight.

• Use RBAC only as a starting point; it does not replace approval separation when the same identity can influence both sides of the decision.
• Require JIT access for elevated permissions so approval results in a short-lived grant, not standing privilege.
• Bind approvals to an independent approver, ideally outside the requestor’s administrative domain.
• Log who requested, who approved, what was granted, and when it expired to support audit and incident analysis.
• For machine workflows, prefer workload identity and policy checks at runtime rather than manual exception handling.

The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because approval failures often sit next to excessive privilege, weak offboarding, and secrets sprawl. Where privileged access is mediated by automation, current guidance suggests evaluating access at the point of use, not only at the point of request. That aligns with the intent of Zero Trust and with the operational direction reflected in the OWASP Non-Human Identity Top 10. These controls tend to break down when emergency access paths, local admin overrides, or manual ticket closures allow the requester to bypass the independent approver.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, so organisations have to balance faster recovery against stronger separation of duties. That tradeoff is real in incident response, production support, and small teams where the same person wears multiple hats. The answer does not change: the governance owner still owns the design flaw, but exceptions need time-bound, reviewed, and fully logged handling. In high-urgency cases, best practice is evolving toward break-glass access with automatic expiry, post-event review, and mandatory second-party validation. There is no universal standard for this yet, but the principle is clear: emergency access should not become a back door for self-approval. For AI agents and other autonomous workflows, the same logic applies even more strongly because the actor may chain tools, escalate privileges, or repeat actions at machine speed. The 52 NHI Breaches Analysis and the BeyondTrust API key breach both underline how quickly privilege misuse becomes a broader compromise when approval and execution are too closely coupled. For governance and risk teams, the practical test is simple: if one identity can influence both the decision and the action, the control is not independent enough.

Related resources from NHI Mgmt Group

• Who is accountable when a single user can both approve and execute a sensitive action?
• Who is accountable when passwordless access fails in a healthcare workflow?
• Who is accountable when CJIS compliance breaks down in a multi-vendor access stack?
• Who is accountable when third-party remote access is overused in public safety environments?