> 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/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy.md). # 3.2 Approval policies and least-privilege autonomy How to tune how much an agent can do without asking, based on posture, data sensitivity, user role, and task risk. *Last reviewed: August 18, 2026* {% hint style="info" %} Agent autonomy should match the task risk. Let agents move quickly where the blast radius is small, and slow them down where actions change systems or expose data. {% endhint %} ## Approval policies and least-privilege autonomy: what security teams need to know Autonomy is a policy decision. It decides how much an agent can do without a person approving each step. The right answer depends on data class, action type, environment, and user skill. High-trust modes are useful in disposable environments. They are risky in production folders, customer systems, and workspaces with live credentials. ## Common approval policies and least-privilege autonomy security failures * A team uses a high-autonomy mode because the pilot was low risk. * Approvals are disabled for write actions after users complain about friction. * Read-only tasks later grow into maintenance tasks without a new policy. * An automated reviewer agent is treated as equivalent to human review. * Break-glass access is left enabled after an incident. ## Approval policies and least-privilege autonomy security controls checklist * Define autonomy profiles for read-only, local write, external write, production, and break-glass work. * Require approval for external writes, destructive actions, credential access, and network changes. * Use full access only in disposable environments. * Record the policy mode in logs and runbooks. * Review autonomy settings after incidents and major feature releases. ## Anthropic ### Overview Claude Code encodes least privilege directly in permission rules: each tool or command pattern can be set to allow, ask, or deny, and deny rules take precedence over ask and allow. Two defaults do real work here. Suspicious bash commands trigger command-injection detection and require manual approval even when a matching rule is allowlisted, and permission matching fails closed, so a command that matches no rule defaults to asking. Managed settings can enforce these rules organization-wide, which turns a team convention into policy. Outside Claude Code, approvals live in different places. Team and Enterprise owners can enable connectors and restrict what actions they take, with connector permissions set to require approval, block, or always allow. Cowork can run without per-call approval prompts; Anthropic recommends ask-before-acting for sensitive files, accounts, sites, new tools, and hard-to-reverse actions, while permanent file deletion still requires approval. Managed Agents run unattended, so their approval posture is the deployment configuration itself. Claude Tag routines are another unattended path. A scheduled job, channel watch, or pull-request subscription uses the same Access bundles as a typed channel request. Restrict who can invoke Claude, narrow the channel's shared service accounts, and require downstream approval for high-impact writes; do not rely on a person being present in Slack when the routine fires. ### Anthropic documentation * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [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) * [Set up Claude Tag routines](https://claude.com/docs/claude-tag/users/proactivity) ### 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 Codex approval policies are named and configurable: on-request (the agent asks when it needs to escalate), never, untrusted, and granular policies that separately control sandbox approvals, MCP prompts, permission requests, and skill approvals. Auto-review is not a mode but a routing capability: it sends eligible approval requests through a reviewer agent instead of a person, which makes it a throughput tool rather than an accountability substitute. Managed configuration can set organization floors so local settings cannot drop below policy. Two adjacent controls round out the picture. Codex hooks can intercept tool calls, but they remain a guardrail rather than an enforcement boundary. In ChatGPT, Lockdown Mode limits outbound web and external-service access, though it does not affect Codex network access. ChatGPT Work introduces read, draft, write, share, scheduled, and execute action classes; apply human review, narrow credentials, app action controls, and supported approvals to the higher-impact classes. Desktop Work follows the local Codex permission and managed-configuration plane. ### OpenAI documentation * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex hooks](https://developers.openai.com/codex/hooks) * [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 approval policies and least-privilege autonomy ### What is least-privilege autonomy? It is granting an agent the minimum ability to act on its own that the task requires: the narrowest file scope, tool set, network reach, and write permissions that still let the work finish. In practice it means choosing a named autonomy profile per task type rather than one global setting. The profile should be visible in logs so reviewers can tell what the agent was allowed to do. ### When should agents run read-only? Use read-only modes for investigation, reporting, code review, and analysis, which produce recommendations rather than changes. Read-only is also the right default for a new workflow until someone has reviewed what write access it actually needs. Both Claude Code and Codex support read-only operation, so this is a configuration decision, not a product limitation. ### What actions should require approval? Writes outside the workspace, deletes, external messages, production changes, credential access, and new network destinations. The test is reversibility and blast radius: anything hard to undo, or visible outside the team, deserves a human pause. Keep the approval list short enough that users do not click through it on reflex. ### Is automated review enough for risky actions? No. Automated reviewers such as Codex's auto-review can filter routine approvals, but they are themselves model-driven and can be steered by the same injected content that steered the agent. Keep hard denies and human approval for destructive, external, or credential-touching actions, and treat automated review as a throughput optimization inside that boundary. ### How should break-glass be handled? Time-limit it, isolate it to a disposable environment, log every action taken under it, and review the session afterwards. Break-glass autonomy should be an incident-response tool with a named owner, not a convenience setting a frustrated user can leave enabled. Expire it automatically rather than trusting cleanup. ## 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 human intervention, override, and stop controls. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports meaningful human review and override authority. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security 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 risk-based human oversight and action-approval records. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards. | *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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy.md) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies.md) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox.md) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk.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/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy.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.