No. NHI governance should manage the agent’s token, scope, and ownership, while request verification should prove the human behind the action. Combining them hides the failure mode and gives a false sense of security, especially in delegated access and identity recovery flows.
Why Separate the Control Plane Matters
Organisations should treat nhi governance and human request verification as different controls because they protect different trust boundaries. NHI governance answers who or what owns the token, what scope it has, how long it lives, and how it is rotated or revoked. Human request verification answers whether a person truly authorised the action, which matters in delegated access, break-glass use, and identity recovery. When one control is asked to do both jobs, neither failure mode is visible.
That separation is not theoretical. The 2024 ESG Report: Managing Non-Human Identities notes that two-thirds of enterprises have already endured a successful cyberattack resulting from compromised non-human identities, which shows how quickly token governance becomes a live exposure when ownership and scope are weak. In practical terms, a good human approval step cannot compensate for an over-privileged or stale machine token, and a good token policy cannot prove the human intent behind a sensitive action. The 2024 ESG Report: Managing Non-Human Identities is useful here because it ties the risk to actual compromise patterns rather than abstract policy failure. In practice, teams usually discover the gap only after a privileged workflow has already been abused.
That is why the control objective must stay explicit: one control constrains machine authority, the other validates human intent.
How It Works in Practice
A workable design splits the workflow into two checks. First, the system verifies the NHI layer: which service, agent, or automation owns the credential, what permissions it has, whether the token is current, and whether the request is within its allowed scope. Second, a separate control verifies the human behind the action, usually through step-up approval, strong authentication, or a recovery workflow with clear accountability. The key point is that the two checks must produce different evidence, because they answer different questions.
-
For NHI governance, validate token ownership, environment binding, scope, expiry, rotation state, and revocation path.
-
For human request verification, verify user identity, approval authority, transaction context, and whether the request matches the stated business purpose.
-
For delegated or recovery flows, require both checks to pass, but keep their logs and failure states separate so you can see which layer broke.
This distinction is especially important when an automated workflow can act on behalf of a person. If the human approval is folded into the same mechanism that governs the token, auditors and operators lose the ability to tell whether the problem was bad delegation, weak approval, or credential misuse. The result is false assurance, because the control can appear to succeed even when the underlying authorisation path is compromised. The The State of Non-Human Identity Security report reinforces why this matters, since lack of credential rotation and over-privileged accounts are among the top reported causes of NHI-related attacks. These controls tend to break down when delegated access is implemented as a single approval screen backed by a long-lived token, because the approval event and the machine authority become indistinguishable.
Common Variations and Edge Cases
Tighter separation often adds workflow friction, so organisations need to balance assurance against operational speed. That trade-off becomes real in break-glass access, incident response, and identity recovery, where a person may need to approve an action that is executed through an automation or service identity.
Best practice is to keep the controls separate even when the user experience is unified. A single portal can collect both approvals, but the backend should still preserve distinct policy decisions, distinct logs, and distinct revocation paths. Current guidance suggests this is especially important when the same request can affect both a human account and a machine token, because the failure impact is different in each case. If the workflow is only about enabling machine execution, request verification should not be stretched into identity governance. If the workflow is only about human intent, NHI controls should not be weakened just to simplify approvals.
One useful rule is this: if you would still need to rotate, scope, or revoke the token after the human approval succeeded, then the controls are not the same control and should not be merged. That principle holds across delegated admin, third-party integrations, and recovery operations. Organisations that blur the two usually find it harder to prove who approved what, which in turn weakens auditability and incident reconstruction.
Risk and Threat Considerations
The main risk is control collapse by overloading one approval path with two different trust decisions. If human verification and NHI governance are merged, a compromise in one layer can hide defects in the other, especially where a valid user can trigger actions through a stale, over-privileged, or unowned token.
Failure mechanism: Attackers and insiders benefit when approval, ownership, and scope are collapsed into one mechanism, because the system may record a legitimate request while the underlying machine authority remains excessive, persistent, or reusable. That creates a path for delegated-access abuse, token replay, and weak recovery decisions to look “approved” even when they are not well governed.
Impact: Organisations lose visibility into whether they are facing a human authorisation failure or a machine privilege failure, which delays containment and makes revocation harder. The practical result is broader blast radius, weaker audit evidence, and a false sense of security in workflows that should be tightly bounded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Separates access governance from request verification for delegated actions. |
| DE.CM — Continuous Monitoring | Distinct logging is needed to see whether failures are human or machine control issues. | |
| Recommendation — Enforce access boundaries so token authority and human approval are controlled separately. Monitor approvals and token use separately so control failures remain attributable. | ||
| CIS Controls v8 | 6 — Access Control Management | Covers account and token governance where over-privilege and stale access create risk. |
| 8 — Audit Log Management | Separate evidence is needed to prove approval, ownership, and execution path. | |
| Recommendation — Review and revoke access paths independently from human approval workflows. Log approval events and token activity separately for audit and incident review. | ||
| NIST SP 800-63 | AAL — Authentication Assurance Level | Human request verification depends on stronger proof of the human behind the action. |
| Recommendation — Use appropriate authentication assurance before accepting high-impact human requests. | ||
| NIST Zero Trust (SP 800-207) | 1 — Verify Explicitly | Two distinct trust decisions fit zero trust's separate verification model. |
| Recommendation — Verify the actor and the access path independently before allowing the action. | ||
Practitioner Guidance
What to prioritise: Separate policy ownership first, then design the workflow so the human approval and the NHI authority check can fail independently. If the same control is expected to do both, it is usually under-specified.
What to verify: Confirm that every sensitive delegated action has a distinct record for who approved it, which token executed it, and what scope and expiry applied at the moment of execution. If those cannot be separated in evidence, the control is too blended to trust.
Decision rule: If revoking the token would still be necessary after a successful human approval, treat the machine control and the request-verification control as separate safeguards, not one combined control. If an incident would require proving both intent and authority, preserve both proofs separately.
Practitioner takeaway: The safest design is not the one that makes approval easiest, it is the one that keeps human intent, machine authority, and revocation evidence distinguishable when something goes wrong.
