Anthropic CCA-F: Claude Agents and Human Approval

Human approval is valuable in Claude agents when the model can move from reasoning to actions that change files, systems, customer records, money, infrastructure, or external communication. The goal is not to interrupt every tool call. It is to put a real decision boundary in front of actions whose consequence requires human accountability or business context.

Anthropic’s Agent SDK exposes several mechanisms for controlling tool execution, including permission modes, allow and deny rules, hooks, and a canUseTool callback that can allow, deny, or modify tool inputs. Anthropic’s official SDK examples demonstrate automatically allowing read operations, blocking dangerous commands, redirecting writes, and prompting a user for approval when a tool is not covered by prior rules.

Human approval therefore belongs inside Claude Production Engineering as an authorization pattern rather than a prompt-writing trick.

Separate intent from authority

Claude can decide that a tool is useful, but trusted code should decide whether the action is permitted.

Tool control is strongest when the model proposes an operation and the host application validates identity, parameters, resource scope, and business rules before execution.

A system prompt that says “ask before deleting” is not equivalent to an execution layer that cannot delete without approval.

Approve high-impact actions

Reading a local file, searching an approved repository, or querying a public API usually has a different risk profile from modifying production data or sending an external message.

Use permission rules to auto-allow low-risk operations and reserve interactive approval for actions where user intent or accountability matters.

Too many prompts train users to approve reflexively and make the approval surface less meaningful.

Show what will happen

An approval should include the target, action, important parameters, and expected effect.

Human approval is useful only when the reviewer can make an independent decision.

“Allow tool?” provides much less control than “Send this message to these three customers” or “Delete these two production files.”

Use permission callbacks for policy

The Agent SDK’s canUseTool callback can programmatically allow or deny tool requests and can modify inputs before execution.

This is useful for restricting file paths, blocking dangerous shell commands, enforcing allowed destinations, or routing unknown operations to a user.

The callback should encode stable application policy rather than duplicate every decision in natural-language instructions.

Use hooks for broader control

Anthropic’s permission model also supports hooks such as pre-tool execution controls in the agent runtime.

Hooks can provide a stronger central gate when every relevant call must be checked regardless of the agent’s allow rules or permission mode.

Keep approval and policy logic testable outside one long prompt.

Keep authentication separate

A user approving an action does not automatically mean the agent has the right credential to perform it.

Agent boundaries should combine user authorization with a workload identity whose tool permissions are already limited.

Approval narrows intent; least-privilege identity limits blast radius if the approval logic is bypassed or the agent is manipulated.

Handle unavailable reviewers

Production agents need deterministic behavior when approval never arrives.

Expire pending actions, preserve the proposal for later review where appropriate, or fall back to a read-only result.

Do not leave an external transaction in an ambiguous partially completed state because the conversation ended.

Audit approvals and denials

Record who approved, which tool and parameters were proposed, what version of the agent was running, and whether execution succeeded.

Agent observability should connect the approval event to the tool result and final business outcome.

A high-impact audit trail is more useful than storing every raw intermediate detail.

Test bypass attempts

Adversarial prompts should attempt to disguise dangerous actions as harmless ones, modify paths, split one action into several calls, or exploit broad tool schemas.

For Claude agents, the durable pattern is read freely where policy allows, validate deterministically, require approval at consequence boundaries, execute through narrow identities, and audit the result. Human approval works when it is one enforceable layer in a larger authorization system.

Approval policy should be derived from consequence, reversibility, and confidence. Reading a repository is usually reversible and low-impact; sending a payment, changing production infrastructure, deleting files, or communicating externally can have consequences the model cannot repair by simply trying again. Those actions deserve stronger gates even when Claude appears confident.

The approval surface should also make uncertainty visible. If the agent is unsure which customer record is correct, the user should see the ambiguity before approving the update. Hiding uncertainty behind a polished summary turns the human into a rubber stamp instead of a meaningful control.

Permission design should use allowlists for expected safe behavior. A file-editing agent can be limited to one workspace; an email agent can be limited to approved domains; a deployment agent can be limited to nonproduction environments until another workflow promotes the change. Narrow tool boundaries reduce the number of cases that require judgment at runtime.

Tool schemas should carry business meaning. A function named transfer_funds with typed destination and amount fields is easier to govern than a generic execute_api_request tool that can call arbitrary endpoints. Clear tools make approval easier because the user sees a concrete operation rather than a low-level request whose impact is hard to infer.

Approval should occur as late as practical but before the irreversible step. The agent can gather data, draft a message, calculate an amount, or prepare a patch automatically, then ask the user to approve the final action. This keeps the workflow efficient while ensuring the human reviews the exact payload that will be executed.

In multi-step work, one approval should not automatically authorize every later action. If the workflow changes target, amount, or scope after approval, the application should either revalidate the original authorization or ask again. Authorization is tied to a proposed action, not to a vague statement that the user “trusts the agent.”

Approval systems also need concurrency control. If two sessions propose conflicting changes to the same record, the second action should re-read current state before execution. A human may approve something that was safe five minutes ago but is now stale. Optimistic locking, version numbers, and transaction checks help keep approval meaningful.

For asynchronous agents, approval can be modeled as a pending task with expiry. Store the proposed action and enough context for the reviewer, but do not keep privileged execution tokens alive indefinitely. When the user approves later, obtain fresh credentials and revalidate the target state.

Security teams should monitor approval patterns. Repeated denials can reveal poor tool descriptions or risky agent behavior. Repeated approvals without review may indicate too much friction. High rates of modified inputs can show that the agent frequently proposes unsafe parameters. These signals should feed prompt, tool, or workflow redesign.

Human approval is therefore strongest as one layer in a permission architecture: narrow tools, least-privilege identity, deterministic validation, explicit consequence, useful review context, fresh-state checks, audited execution, and adversarial tests. The human does not make the agent safe alone; the system makes the human decision enforceable.

Approval policy should be versioned with the agent. If one release adds a new tool or changes a tool from read-only to write-capable, the permission and approval configuration should change in the same deployment. This prevents an agent from gaining operational capability while the old approval model still assumes a smaller blast radius.

Organizations should define who is allowed to approve each class of action. The end user may approve a customer-facing draft, while a production deployment might require an operator or change manager. Identity and role checks should happen at the approval service, not be inferred from who happens to be present in the chat.

Approval should also preserve separation of duties where required. The person who prepared an action may not be the person allowed to authorize it, particularly for financial, privileged, or regulated workflows. A production agent can support that process by packaging the evidence and proposal without collapsing both roles into one click.

When approval is denied, capture the reason where practical. A denial caused by wrong parameters should lead to a corrected proposal; a denial caused by policy should terminate the workflow. Treating all denials as “try again with different words” can turn the agent into a pressure mechanism against the human control.

The approval experience should be tested with real users under time pressure. Long technical payloads are difficult to review, but oversimplified summaries can hide material details. The right interface shows the consequence first and gives reviewers a way to inspect supporting evidence before deciding.

Approval architecture should be reviewed whenever the agent becomes more autonomous. Adding scheduled execution, memory, background sessions, or new MCP tools can create actions when the original user is no longer present. The system should decide whether those actions require pre-authorized policy, deferred approval, or a hard stop. A control designed for an interactive chat should not be assumed to remain sufficient after the same agent starts operating asynchronously.

Keep approval owners and policy tests current as tools, user roles, and asynchronous capabilities change so the human gate remains tied to real consequence.