Who should approve high-risk agent actions such as password resets or payout changes?

Why This Matters for Security Teams

High-risk agent actions need approval because the control objective is not just access, but accountable decision-making at the point of impact. Password resets and payout changes can create immediate privilege escalation, fraud, or lockout if an agent is allowed to self-authorise. The right approver is the business process owner, because that group can validate whether the request matches the workflow, the target identity, and the expected outcome. This is aligned with how NHI governance failures usually show up in practice, not just in policy.

For autonomous and agentic systems, the risk is amplified because the agent may chain tools, retry requests, or act on partial context. Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime oversight and human accountability for consequential actions. NHI Management Group research in the Ultimate Guide to NHIs — Why NHI Security Matters Now shows why this matters: NHIs outnumber human identities by 25x to 50x in modern enterprises. In practice, many security teams encounter harmful approvals only after an agent has already reset access or triggered payment, rather than through intentional pre-approval design.

How It Works in Practice

The approval path should be tied to the business action, not to the agent as a generic actor. For example, a password reset request should route to the team that owns identity operations, while a payout change should route to finance or treasury approvers who understand the downstream obligation. The approver should see the exact identity, account, amount, destination, and reason, so the decision is based on context rather than trust in the agent.

In agentic environments, this is usually implemented as a runtime control rather than a static permission. The agent can draft the request, but a human gate must confirm it before execution. Best practice is evolving toward intent-based authorisation, where policy engines evaluate what the agent is trying to do, not just who the agent is. That means pairing approval with short-lived credentials, scoped tool access, and explicit revocation after the task completes. When available, workload identity helps prove what the agent is, while policy-as-code enforces what it may do at request time. References such as OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both reinforce the need for narrow privileges, explicit approval boundaries, and traceable control ownership.

• Use the business process owner as approver, not a shared operator queue.
• Require dual control for money movement, privilege elevation, or irreversible changes.
• Bind approval to the specific action, target, and outcome expected.
• Issue just-in-time credentials only after approval and revoke them on completion.
• Log the request, approver, and final system effect for audit and incident review.

These controls tend to break down when agents are embedded in legacy ticketing or ERP workflows that cannot pass task-level context into the approval step.

Common Variations and Edge Cases

Tighter approval routing often increases workflow latency, requiring organisations to balance fraud resistance against operational speed. That tradeoff is real, especially where resets are frequent or payment operations are time-sensitive. Current guidance suggests that low-risk actions can use lighter review, but there is no universal standard for this yet, so the threshold should be defined by the business owner and reviewed with security.

Edge cases usually involve delegated authority, emergency access, and bulk actions. A help desk may be allowed to approve routine password resets for a defined population, but the same team should not approve resets for privileged accounts or recovery channels. Similarly, a payout change may require one approver for small adjustments but dual control for new beneficiaries, limit increases, or cross-border transfers. For agent-driven workloads, the approval model should also account for retry loops and chained tool calls, because a single approved action can cascade into several unintended ones. NHI Management Group’s Top 10 NHI Issues and the AI LLM hijack breach case study illustrate how quickly control boundaries can fail when runtime context is weak or approvals are too broad. The practical rule is simple: if the action changes identity, privilege, or money, the approving human should own that process and be able to explain why the action is valid.

Related resources from NHI Mgmt Group

• Who should approve high-risk agent actions in production?
• Who should approve high-risk actions taken by an AI agent?
• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?