Gate consequential actions with human approval

Learning objective

Insert a human-in-the-loop approval checkpoint before an agent performs a high-impact or irreversible action. This lesson focuses on the approval gate and its execution semantics, not on general authorization or content filtering.

Core idea

Let the agent prepare an action, but make deterministic workflow code decide whether execution requires approval. The safe sequence is:

propose -> classify risk -> pause -> review -> revalidate -> execute

The approval must cover the exact action that will execute, not a vague goal such as “fix production.” Place the gate as close as practical to the side effect: after the agent has resolved the target and arguments, but before the final tool call. Google Cloud’s guidance for computer-use agents follows this placement: prepare the form or message, stop before the final action, and request confirmation. See Computer use model and tool.

Human approval reduces excessive autonomy. It does not make a forbidden action permitted, grant missing IAM permissions, or prove that an action is safe.

How it works

First, define an action-risk policy outside the model. Require approval when a side effect can cause material financial, operational, legal, privacy, security, or reputational harm, or when recovery is unavailable or costly. Examples include moving money, deleting records, changing production infrastructure, sending external communications, disclosing sensitive data, and accepting legal terms. Apply thresholds such as environment, amount, data classification, recipient, and scope of impact in deterministic code. A model may identify context for the classifier, but it must not waive the gate.

When the policy requires approval, create a pending-action record that includes:

• the action type, exact target, and normalized arguments;
• the expected effect, risk, and reason for the action;
• a preview or diff and any available rollback plan;
• the initiating user, acting agent, required approver role, and task ID;
• the creation time, expiration time, and a digest (cryptographic fingerprint) of the action.

Present the material facts in the approval interface. Offer explicit Approve and Reject decisions; silence, timeout, or an unavailable approval service must not mean approval. Authenticate the reviewer and verify that the reviewer has the required role. The initiating user can approve a personal purchase, for example, while a production change might require an on-call engineer or resource owner. NIST AI RMF calls for organizations to define human-oversight roles and responsibilities.

Bind the decision to the pending action’s digest. Before execution, the trusted executor must verify all of the following:

1. The decision is authentic, affirmative, unexpired, and from an authorized approver.
2. The action, target, and arguments still match the approved record.
3. Authorization and policy checks still pass against current state.
4. Preconditions still hold and the approval has not already been consumed.

If any check fails, cancel the pending action or generate a new proposal and request new approval. Do not let the model edit arguments after approval. Make the execution request idempotent: a retry or duplicated resume event must not repeat a charge, deletion, or message.

Only an approved action whose checks still pass reaches execution.

For a long wait, persist the pending state and release compute resources. Resume from the durable approval event rather than relying on conversational memory. Gemini Enterprise Workflow Builder similarly distinguishes an approval step that pauses execution before downstream steps from a request-for-information step.

Finally, record the proposal, risk decision, reviewer identity, decision, revalidation result, tool result, and timestamps in an audit log. Protect the log from tampering and avoid placing secrets in it.

Key distinctions and trade-offs

Approval versus authorization: Authorization answers whether an identity may perform an operation. Approval answers whether an accountable person accepts this particular operation now. A valid approval cannot override a deny policy, and existing permission does not remove an approval requirement.

Approval versus clarification: Clarification supplies missing information. Approval accepts a fully specified consequence. Asking “Which project?” is not approval to delete that project.

Approval versus notification: A notification reports an action before or after it happens. A real gate prevents the side effect until an affirmative decision arrives.

Plan approval versus action approval: Approving a plan can guide later work, but it is too broad for a consequential tool call. Require another decision if the resolved target, amount, recipient, command, or relevant state changes.

Human review adds latency, workflow state, interface work, and operational staffing. Requiring it for every read or reversible low-risk update also creates approval fatigue. Use risk tiers: automate low-risk actions, require approval for defined consequential actions, and block prohibited actions entirely. Google Cloud notes that human review can still fail when reviewers approve malicious or destructive suggestions without sufficient scrutiny; see AI security and safety for MCP servers.

Architecture / decision scenario

A production-operations agent diagnoses an outage and proposes removing a firewall rule. It may inspect logs, test connectivity, identify the exact rule, and generate a configuration diff without approval because those preparation steps do not modify production.

The risk policy classifies firewall deletion in production as high impact. The workflow stores the proposed rule ID, project, diff, affected services, evidence, and rollback command, then pauses. An authenticated on-call engineer reviews and approves that exact digest.

On resume, the executor verifies the engineer’s role, checks that the approval is fresh, rereads the firewall configuration, and reruns authorization and policy checks. If another process changed the rule after review, the digest or precondition no longer matches, so the executor does not delete it. The agent must create a new diff and obtain new approval. If the state matches, the tool performs one idempotent deletion and records the outcome.

This design keeps diagnosis fast while preserving accountable control over the irreversible boundary.

Common exam traps

• Putting “ask before dangerous actions” only in the system prompt. A hard gate belongs in trusted workflow or tool execution code.
• Requesting approval before the target and arguments are known, then treating it as permission for whatever the agent later chooses.
• Letting the model report that approval occurred instead of verifying an authenticated approval record.
• Treating approval as authorization or as an exception to an explicit deny.
• Executing changed arguments, stale state, or an expired approval without a new review.
• Assuming a timeout, missing reviewer, or approval-service failure means continue.
• Requiring approval for every action and ignoring reviewer fatigue.

What to remember

• Put a deterministic approval gate immediately before a consequential side effect.
• Show the reviewer the exact target, arguments, effect, risk, and recovery plan.
• Bind approval to the action and invalidate it when the action or state changes.
• Revalidate identity, authorization, policy, and preconditions before execution.
• Treat rejection, timeout, and approval failures as no permission to proceed.
• Keep human approval, least privilege, guardrails, and audit logging as separate layers.

Knowledge check

References

• Google Cloud Architecture Center, Choose a design pattern for your agentic AI system
• Google Cloud, Computer use model and tool
• Google Cloud, Use human-in-the-loop steps
• Google Cloud, AI security and safety for MCP servers
• NIST, AI Risk Management Framework Core
• OWASP, LLM06 Excessive Agency