> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies.md). # 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* {% hint style="info" %} Approval prompts are authorization controls, but they are weak when users are tired, rushed, or misled by injected instructions. Use approvals for meaningful decisions, and pair them with hard limits on tools, network access, files, and write actions. {% endhint %} ## 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 * [Claude Code security](https://code.claude.com/docs/en/security) * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## 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 * [Agent approvals & security](https://developers.openai.com/codex/agent-approvals-security) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## 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 | Governance page | Relationship to this article | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | 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 * [1. Identity & Access](/handbook/1.-identity-and-access.md) * [3.2 Approval policies and least-privilege autonomy](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy.md) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk.md) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.