To require human approval before an AI agent takes an external action, put an enforced approval gate in the application or runtime immediately before the action executes. The agent should propose a specific operation, pause, and show a reviewer the target and relevant arguments. Execute only after an explicit approval; rejection, cancellation, or an unresolved review must not trigger the side effect.
Where to put the approval gate
Put the gate at the boundary between the agent’s proposal and the system that performs the action. Inventory tools that send messages, submit forms, make purchases, change records, delete data, run commands, or otherwise affect an external system. For each operation that needs review, execution logic—not merely the model’s instructions—must check for approval before calling the tool.
As an Amazon Associate I earn from qualifying purchases.
This distinction matters because asking a model to “ask first” does not enforce anything. A prompt can guide behavior, but the application or runtime must control whether a proposed action is actually allowed to proceed.
Three implementation patterns
| Pattern | How it works | Important boundary |
|---|---|---|
| Agents SDK tool approval | Mark a sensitive tool as requiring approval. When review is needed, the run records an interruption rather than executing the tool, and returns resumable state. | Approval is associated with the pending tool call; resolve the review and resume the same run. OpenAI’s Agents SDK human-review guide |
| Workflow approval node | Place a human approval step between the agent’s proposed work and the node that performs it. OpenAI’s Agent Builder documentation illustrates an agent drafting an email, followed by human approval, then an MCP node connected to Gmail. | Make sure the action node cannot run along a path that skips the approval step. OpenAI Agent Builder documentation |
| Application-controlled browser or runtime gate | Pause before a browser or other runtime performs a consequential action, and let the application enforce the reviewer’s decision. | Permission to access a website origin does not confirm each action on that site. OpenAI’s computer-use documentation says, “Origin approval does not enforce confirmation before individual actions.” OpenAI computer-use documentation |
Design the approval flow
- Classify the operations. Decide which actions require human review. Distinguish read-only operations from writes, and define whether your policy reviews every operation or only those it considers consequential. OpenAI’s Agent Builder safety guidance recommends enabling approvals for MCP operations, including reads and writes; a team adopting a different scope should make that choice explicit. OpenAI Agent Builder safety guidance
- Pause before execution. At the tool or workflow boundary, intercept the pending operation before the external system receives it. OpenAI describes human review as pausing a run so a person or policy can approve or reject a sensitive action. OpenAI’s human-review guide
- Show enough to make a decision. Present the proposed operation, its target, and relevant arguments in a form the reviewer can understand. Keep the decision tied to that pending operation rather than treating it as blanket permission for future actions. This is a design recommendation based on the documented per-tool interruption pattern.
- Require an explicit decision. Continue only when the reviewer approves. Rejection or cancellation should leave the external side effect unperformed.
- Resume the pending run. Resolve the approval interruption and continue from its saved state. If review may be delayed, persist that state and resume the same run after the decision instead of creating a new run that could lose the pending action’s context. OpenAI’s human-review guide
- Define failure behavior. Decide what happens if a reviewer is unavailable, a review times out, or a response is invalid. For consequential actions, fail closed: do not execute without a valid approval. This is a prudent engineering policy, not a universal timeout rule specified by the cited documentation.
Approval is one layer, not the whole security design
Human review decides whether a particular proposed operation should proceed. Automated guardrails can validate inputs, outputs, or tool behavior, but they serve a different purpose. Because guardrails have defined workflow boundaries, they do not automatically inspect every custom tool call; put validation at the tool that creates the side effect if every such call needs a check. OpenAI’s guardrails and human-review guide
#1 Best Overall
Keep additional controls in place around the approval gate. OpenAI’s Agent Builder safety guidance covers risks from untrusted content, and its computer-use guidance addresses runtime restrictions. Apply least-privilege access, restrict sites and actions where possible, bound the run’s steps, time, and cost, support cancellation, and verify the actual outcome after execution. An approval does not make content from a page trustworthy or make an overly broad credential safe. Agent Builder safety guidance; computer-use guidance
Quick Recap
Best Value
Rank #3
Implementation checklist
- List every tool or runtime operation that can affect an external system.
- Attach approval enforcement at the execution boundary for each action that requires review.
- Show the reviewer the exact proposed operation, target, and relevant arguments.
- Allow execution only after explicit approval; reject, cancel, timeout, and invalid responses must not silently proceed.
- Persist pending approval state when reviews can be delayed, then resume the same run.
- Use validation, least privilege, runtime limits, cancellation, and outcome checks alongside human review.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
