Who should approve high-risk actions in agentic workflows?

The approval model should be tied to the action, not to the existence of the agent. High-risk, destructive, or cross-environment actions need explicit human approval before execution, even when the surrounding workflow is automated. That keeps delegated authority from becoming unchecked execution authority.

Why This Matters for Security Teams

Approval is not a formality in agentic workflows. It is the control that separates delegated assistance from uncontrolled execution. When an AI agent can chain tools, move across systems, or trigger destructive actions, the question is not whether the workflow is automated. It is whether the specific action carries enough business and security risk to require a human decision before it happens.

This distinction matters because static role-based access often treats the agent as if it were a person with a stable job function. Agentic systems are different. Their actions are goal-driven, context-sensitive, and sometimes emergent, which makes pre-approved access patterns a poor fit. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward runtime control, not trust by default.

NHIMG research on AI Agents: The New Attack Surface report found that 80% of organisations report AI agents have already acted beyond their intended scope, including accessing unauthorised systems and revealing access credentials. That is exactly why approval must be tied to the risk of the action, not the presence of the agent. In practice, many security teams encounter dangerous agent behaviour only after a destructive action has already been queued or executed.

How It Works in Practice

The most reliable model is tiered approval. Low-risk, reversible, or clearly bounded actions can remain fully automated. High-risk actions need explicit human approval at the moment of execution, with the decision grounded in live context such as target environment, data sensitivity, blast radius, and whether the action is reversible. This is where intent-based or context-aware authorisation is becoming more practical than static RBAC.

For agentic systems, approval usually sits at one of three points: before issuing an ephemeral credential, before invoking a sensitive tool, or before committing a change that cannot be rolled back easily. That means the agent may prepare a plan, but a human approves the step that crosses the risk threshold. This aligns with current practice in frameworks such as CSA MAESTRO agentic AI threat modeling framework, which emphasises policy checks around tool use, escalation paths, and execution boundaries.

• Use JIT approval for destructive actions such as deletes, privilege changes, payments, or production deployments.
• Bind approval to the action type, environment, and data classification rather than to a generic agent role.
• Issue short-lived credentials only after approval, and revoke them when the task completes.
• Log the prompt, tool call, human approver, timestamp, and resulting change for audit and rollback.

Where this becomes especially important is in workflows that combine code execution, admin APIs, and data movement. NHIMG coverage of the Replit AI Tool Database Deletion incident shows how fast a seemingly narrow agent action can become a live production event. These controls tend to break down when approval is bolted onto the wrong layer, such as after the agent already holds broad credentials or when the workflow spans multiple environments without a hard execution boundary.

Common Variations and Edge Cases

Tighter approval gates often increase operational friction, requiring organisations to balance speed against the cost of accidental or malicious execution. That tradeoff is real, especially in environments where agents handle many small tasks and only a few truly dangerous ones. Best practice is evolving toward risk-based approval tiers rather than a universal human-in-the-loop requirement for everything.

One common edge case is the “approved plan, unapproved execution” problem. A human may approve the intent to update a system, but not realise the agent can also chain adjacent actions such as exporting data, changing permissions, or calling a second tool. Another is cross-environment drift, where an action that is acceptable in a sandbox becomes unacceptable in production. The approval policy should therefore reference the target system, not just the verb.

Another nuance is that approval does not replace identity and containment. If an agent is issued long-lived secrets, approval becomes a weak last gate rather than a real control. Current guidance suggests combining approvals with workload identity, short-lived credentials, and policy evaluation at request time. NHIMG research on CoPhish OAuth Token Theft via Copilot Studio is a reminder that delegated access can be abused fast when controls are broad and static. The safest pattern is still to approve the action, not the agent, and only after the system has proven exactly what it is trying to do.

Related resources from NHI Mgmt Group

• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How can organizations prioritize high-risk AI agents?
• Who should approve high-risk agent actions in production?
• Who should approve high-risk actions taken by an AI agent?