Accountability sits with the identity governance and control owners who allow request and approval to collapse into one path. In audited environments, that weakness can also trigger SOX exposure because it undermines logical access controls. The fix is separation of duties in both process design and system enforcement.
Why This Matters for Security Teams
When one identity can both request and approve access, the issue is not just workflow design. It is a control failure that collapses separation of duties, weakens auditability, and makes it harder to prove who authorised what. That matters for NHI governance because service accounts, API keys, and automation identities often operate faster than human review cycles and can bypass the friction that normally exposes conflicts.
NHI Management Group has shown how broadly this problem scales in practice: only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which means many teams cannot reliably tell whether request and approval authority has been merged. OWASP also treats over-permissioned and poorly governed non-human identities as a recurring weakness in the OWASP Non-Human Identity Top 10. In practice, many security teams discover the conflict only after an audit exception, an access review failure, or an incident has already exposed the gap.
How It Works in Practice
The accountability question sits at two levels: process ownership and technical enforcement. Process owners define who may request access, who may approve it, and which combinations are prohibited. System owners enforce those rules so the same identity cannot act in both roles, even if a user or automation pathway tries to route around the policy. For NHIs, this usually means separating the workflow identity from the approver identity and treating approval as a distinct, independent control.
In mature environments, this is enforced through RBAC, policy-as-code, and workflow segregation in the identity platform. The standard pattern is to ensure requesters cannot approve their own requests, cannot approve requests for identities they administer, and cannot self-grant elevated secrets or tokens. For automation-heavy estates, that often requires separate workload identities, explicit approval chains, and logging that records the full decision path. NHI Mgmt Group’s Top 10 NHI Issues research highlights how excessive privilege and poor visibility make these conflicts harder to detect once they exist.
- Separate request, review, and approval into different identities or roles.
- Block self-approval in the IAM or GRC workflow, not just in policy documents.
- Log the requester, approver, target asset, and justification in a tamper-evident record.
- Review privileged exceptions more frequently than standard access grants.
For auditability, the control owner should be able to show both the written policy and the technical safeguard that prevents bypass. These controls tend to break down when approval paths are embedded in scripts, chat workflows, or admin consoles that do not preserve reliable evidence of who actually approved the change.
Common Variations and Edge Cases
Tighter separation of duties often increases operational friction, requiring organisations to balance control strength against provisioning speed. That tradeoff is real, especially in engineering teams that rely on fast-moving CI/CD pipelines or on-call operators who need urgent access during incidents. Current guidance suggests that emergency access should be time-boxed and independently reviewed rather than exempted entirely.
There are a few common exceptions. Small teams sometimes let one person request and approve access temporarily, but that should be treated as a compensating control exception, not a normal operating model. In regulated environments, the risk is higher because collapsed approval chains can undermine SOX-relevant logical access controls. The underlying concern is not just policy violation, but the inability to prove independent oversight.
Best practice is evolving for agentic and automation-heavy environments, where an AI agent may trigger access workflows but should not also be the approving authority. For those cases, the workload identity should submit requests, while a separate human or independent control service makes the approval decision. NHI Mgmt Group’s Ultimate Guide to NHIs and the breach patterns in the 52 NHI Breaches Analysis both show that weak governance becomes most visible after compromise or audit scrutiny, not during routine operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Self-approval and excess privilege are core NHI governance failures. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and enforced with separation. |
| NIST AI RMF | GOVERN | Accountability for autonomous or automated access decisions needs ownership. |
Assign clear owners for access policy, approval logic, and exception handling.
Related resources from NHI Mgmt Group
- Who is accountable when a user can both request and approve privileged access?
- Who is accountable when a control failure lets one identity approve and execute the same transaction?
- Who should be accountable for lifecycle governance across IAM and privileged access?
- Who is accountable when identity failures affect DORA compliance?
