1.7 Human-in-the-loop and approval policies
Where to require human approval in agentic workflows and how approvals can fail under prompt injection, fatigue, or unsafe defaults.
Last reviewed: August 18, 2026
Human-in-the-loop and approval policies: what security teams need to know
AI agents often ask before they act. That approval step can be useful. It gives a person a chance to stop a risky command, a connector write, a file edit, a network request, or a privilege escalation. It also creates a record that a human accepted a boundary change.
Approval is not a full security model. A user may not understand the tool call. A prompt injection can frame a malicious action as routine. A long session can create approval fatigue. A vague prompt such as "continue" can hide a meaningful change in access or side effects.
Use approval policies to slow down actions that matter. Use RBAC, sandboxing, connector policy, network controls, and file controls to prevent actions that should not be available in the first place.
Common human-in-the-loop and approval policies security failures
The platform asks for approval too often, so users accept without reading.
The approval text describes a command, but not the data it can expose or the system it can change.
A user approves a connector write action without understanding who can see the result.
An admin enables high-autonomy mode for convenience and leaves it on.
Prompt injection convinces an agent to request an action that looks normal in context.
Approval logs exist, but they are not tied to the business owner, ticket, or incident trail.
Human-in-the-loop and approval policies security controls checklist
Define action classes: read-only, local write, external read, external write, network access, credential access, destructive action, and privilege escalation.
Require approval for external write actions, broad file writes, network access, command execution, credential access, and new tool or connector grants.
Block actions that the role should never perform, rather than asking users to reject them.
Use stricter approval rules for regulated data, source code, production systems, and customer-facing channels.
Keep approval prompts specific. The user should see the tool, target, data class, and side effect.
Monitor repeated approvals, denied approvals, and escalations from read-only to write modes.
Train users to stop when the prompt asks for an action unrelated to the original task.
Review high-autonomy configurations after incidents, vendor releases, and role changes.
Anthropic
Overview
Claude Code documentation says the tool uses read-only permissions by default and prompts when additional actions are needed, including file edits and commands. It also describes controls for network-request approval, new MCP server trust, command injection detection, fail-closed matching, and organization managed settings. Command injection detection means suspicious bash commands require manual approval even if a matching rule was previously allowlisted, and fail-closed matching means unmatched commands default to requiring manual approval. Permission rules add the hard-limit layer: rules can allow, ask, or deny specific tool use, deny rules take precedence over ask and allow rules, and managed settings can enforce those rules organization-wide.
Anthropic's Enterprise custom roles can also cap connector behavior. Connector or tool access can be always allowed, require approval, or be blocked. The organization-wide tool policy acts as a ceiling: role grants can narrow access inside that ceiling but cannot widen past it, and enforcement fails closed toward denial.
Cowork and Claude Tag need surface-specific review. Cowork supports ask-before-acting for sensitive work. Claude Tag channel work uses shared, admin-provisioned service accounts and can run routines without a new prompt, so human review must be enforced in the connected system or workflow when an action is high impact. Limit who can invoke Claude Tag, narrow each Access bundle, disable DMs if personal connectors are out of scope, and keep standing work visible to channel owners.
The practical pattern is to keep sensitive users on narrower roles, block tools that have no business need, and reserve always-allow settings for well-understood internal tools.
Anthropic documentation
Applicable Harmonic guides for Anthropic
OpenAI
Overview
OpenAI's Codex approval documentation describes approval policies including read-only, workspace-write with on-request approvals, never, untrusted command approval, and granular policies that separately control sandbox approvals, MCP prompts, request-permission prompts, and skill approvals. Auto-review is a routing capability rather than a policy: it can send eligible approval requests through a reviewer agent instead of interrupting the user. Dangerous full access sits apart from all of these; it removes sandboxing and approvals and is not recommended. Codex managed configuration adds the enforcement layer, letting organizations set approval policy, sandbox behavior, and MCP-related settings centrally rather than leaving each developer to pick their own floor.
OpenAI also documents Lockdown Mode for ChatGPT as a way to reduce prompt-injection data exfiltration risk by limiting outbound web and external-service access. In managed workspaces, Lockdown Mode is assigned through RBAC roles. OpenAI states that Lockdown Mode does not affect Codex network access, so Codex needs its own approval and sandbox policy. ChatGPT Work can draft, write, share, schedule, and execute through approved tools. OpenAI's Work admin guidance says higher-impact actions should combine human review with narrow roles, credentials, scopes, app action controls, and supported approvals; desktop Work follows the local Codex permission plane.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Frequently asked questions about human-in-the-loop and approval policies
Which actions should always ask?
Ask for external writes, broad file edits, command execution, network access from code, new connector grants, credential access, and any action that changes permissions or public visibility.
When should an action be blocked instead of approved?
Block it when the user has no legitimate business need for that action. Approval is useful for context-dependent risk. It is a poor substitute for role design.
How do prompt injections affect approvals?
Prompt injection can make a risky action look like part of the task. Approvals should show concrete side effects and should be backed by hard limits on tools, network paths, and write access.
What is human-in-the-loop approval for AI agents?
Human-in-the-loop approval is a control that asks a person to approve selected agent actions before they run. It works best for clear, high-impact actions with specific side effects.
Should approval prompts be logged?
Yes. Log the requested action, user decision, policy mode, tool, target system, timestamp, and final result. Approval history is useful during access reviews and incident response.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.2 EU AI Act obligations for deployers
Conditional: for an in-scope high-risk system, this supports competent, authorized human oversight.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports identity and access control.
G.4 Colorado AI Act and the US state patchwork
Conditional: for covered Colorado ADMT, this supports meaningful human review by a person able to approve, modify, or override an outcome.
G.5 SANS Critical AI Security Guidelines mapping
This article implements relevant SANS Access Controls guidance.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.7 Ownership and RACI for AI security
This control depends on the ownership and evidence responsibilities defined in the RACI.
G.8 ISO/IEC 42001 AI management system
This article supports ISO/IEC 42001 AIMS preparation through organizational oversight, approval authority, and documented exceptions.
G.9 HIPAA controls for AI systems handling PHI
Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?