Free tools Windows power users keep installed
One-click scans. No signup required.
Put an approval gate in your application between an AI agent’s proposed tool call and the code that executes it. When policy marks an action as consequential, show an authorized person the exact tool and arguments, require a decision for that specific request, and execute only if it is approved. A model instruction to “ask first” is not a substitute for controlling the execution path.
What the approval gate must do
The agent can propose an action, but the application—not the model alone—must decide whether the corresponding tool call is allowed to run. The gate should intercept the proposal before execution, determine whether review is required, and hold the action until an authorized reviewer responds.
As an Amazon Associate I earn from qualifying purchases.
OpenAI’s Responses API reference describes an MCP approval request containing the tool name and arguments, information an application can use to present the proposed invocation for review (Responses API streaming reference). The approval object is a control point; the application still needs to connect it to the code that executes the tool.
Decide which actions require approval
There is no universal high-impact threshold in the cited API references. Define one in your application policy according to the consequences, authority, and domain of the action. As a starting checklist, consider requiring review before an agent:
#1 Best Overall
- Sends an external message or publishes content.
- Spends, transfers, or commits money.
- Deletes or materially changes important data.
- Changes access controls or permissions.
- Initiates an operation in the physical world.
These are policy-design examples, not categories or thresholds prescribed by OpenAI’s API documentation. Decide whether the rule applies to every action in a category or only above a limit, and identify who is authorized to approve it.
Build the approval flow into execution
- Intercept the proposal. Let the agent produce a tool proposal, then route it through your application’s policy layer before invoking the tool.
- Create a request for the exact action. Bind the approval request to the tool and its arguments. Show the reviewer those details alongside a plain-language summary of the likely effect.
- Collect a request-specific decision. Require an explicit approval or rejection tied to that request. Silence, a timeout, or confirmation for a different request is not approval.
- Freeze the proposed arguments. Execute only the arguments that were reviewed. If the tool or any argument changes, create a new approval request.
- Execute or stop. Invoke the tool only after approval. On rejection or expiration, do not execute the proposed action; return a safe status to the agent or user.
- Record the outcome. Log the request, relevant action details, reviewer identity, decision, time, and execution result under your organization’s access and retention rules.
Choose the mechanism for the API you use
Approval workflows differ across APIs. These documented mechanisms are not one interchangeable protocol; select the one that matches your API and tool integration.
| API mechanism | Documented behavior | What your application must handle |
|---|---|---|
| Responses API MCP approval request | The approval request object includes the tool name and arguments, according to the Responses API streaming reference. | Present the proposed invocation to a reviewer and connect the approval outcome to the tool’s actual execution path. |
| Realtime API approval response | The response is associated with an approval request ID and includes an approve boolean; an optional reason can preserve an explanation, according to the Realtime API server events reference. |
Associate the decision with the correct pending request and define what happens after approval, rejection, or no response. |
| Assistants API function-call run lifecycle | A function call can put a run in requires_action. The application runs the functions and submits outputs before the run proceeds; the run expires if required outputs are not submitted before its expiry time, according to the Assistants API run lifecycle guide. |
Handle the pending run and its expiry without executing an unapproved function. Confirm current platform behavior when implementing. |
Define rejection, timeout, and error behavior
A pending approval must not become permission by default. If the reviewer rejects the request or the request expires, do not run the tool. Return a safe status so the agent or user can respond appropriately. For the Assistants API, the run-lifecycle guide specifically describes expiration when required outputs are not submitted in time; that behavior is API-specific, so check the current documentation for the API you implement.
Also decide how your application handles duplicate submissions and execution errors. A repeated approval signal should not accidentally trigger duplicate high-impact actions, and an execution failure should be distinguishable from rejection in the recorded outcome.
Rank #3
Test the gate, not just the reviewer screen
Test the full route from proposal through policy, review, and execution. Include approval, rejection, timeout, changed arguments, duplicate requests, and errors. Confirm that each test produces the intended tool behavior and audit record. The cited API references document workflow mechanisms; they do not establish that an application’s policy, failure handling, or audit trail is automatically implemented.
Quick Recap
Best Value
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.
