A customer approves an agent's plan to update one CRM record. The next tool call targets a different account with a larger set of changes. A generic approval banner cannot tell the operator whether the action still matches the plan. Before a customer rollout, define exactly what approval covers, what data leaves the application and which checks run at execution.
Start with the Responses API approval boundary
OpenAI's Responses API supports MCP tools that connect a model to external servers. Its guide describes approval as the default before data is shared with a remote MCP server. The require_approval setting controls that flow. The values always and never make the distinction explicit, and selective configuration can skip approval for named tools.
These are Responses API controls, not a promise that every MCP client or every agent framework has identical behavior. Check the API, model and integration your product actually uses. The workflow controls below are recommended application design, not features automatically supplied by a protocol connection.
| Control | What it addresses | What still needs application logic |
|---|---|---|
| allowed_tools | Which server tools are imported | Who can access each customer record |
| require_approval | Whether a call needs approval | Who may approve and what the screen shows |
| mcp_approval_response | Response to a particular approval request | Stale state, changed targets and customer policy |
| Server authorization | Access enforced at the destination | Correct customer context and scope selection |
Filter tools before the model chooses an action
The allowed_tools parameter limits which tools are imported from a server. Use it to present the smallest set needed for the task. A support assistant searching documentation does not need a tool that deletes customer records. Keeping that tool out of the request makes the intended scope easier to review and test.
Do not mistake the import filter for server authorization. Your backend should still verify the authenticated customer, acting user and permitted resources. A record identifier supplied by a model is a proposed target. Resolve and authorize that target through trusted application context rather than trusting the identifier alone.
Treat private reads as data sharing
A tool does not need to write data to cause a disclosure. A search query sent to a remote server might contain a candidate's email, an internal document excerpt or customer account details. Review what leaves the model request and who receives it. A read-only label says little about whether those arguments are appropriate.
OpenAI recommends separating public research from private record access. For example, gather public facts in a request that has only public search available. Pass the relevant facts into a separate request limited to internal retrieval. Your implementation should avoid carrying private records into later public searches or URLs.
Build the approval screen around exact arguments
When approval is requested, the Responses API returns an mcp_approval_request item with the tool name, server label and arguments. Review the requested tool and arguments before continuing. The application responds with an mcp_approval_response that references the returned approval request identifier. OpenAI describes each approval as applying to one tool call.
For customer use, translate the arguments into an operator-readable preview without hiding important fields. Show the destination service, customer, target record and proposed change. For a data-sharing action, show the categories of information being sent and the receiving server. Keep the underlying arguments available for a technical reviewer where appropriate.
Bind your own approval record to the acting user and exact proposed operation. If the target or arguments change, request fresh review. A general instruction to finish onboarding should not silently become permission to perform every tool action that might help.
Recheck state when approval is used
An approval can sit in a queue while the underlying record changes. Add an application policy for expiration and stale state. Before execution, confirm that the reviewer remains authorized and that the destination record still matches the approved operation. If another user changed the relevant fields, show the difference rather than overwriting it unnoticed.
Keep this check in the execution path. A review screen that validates the target but a worker that later accepts arbitrary arguments leaves a gap. Test the actual handoff between the approval event and the server action, including delayed jobs and restarted workers.
Handle denied and uncertain calls deliberately
A denied action should stop that proposed operation. Give the user a clear result and a way to revise the request. Do not ask the model to find a different tool that achieves the same rejected outcome. Log the decision using record identifiers and redacted arguments rather than copying sensitive payloads into general support logs.
A connection error after a write attempt can leave an uncertain result. Before retrying a consequential action, reconcile destination state through an authorized read or an operation record your integration maintains. Approval does not make a duplicate write safe. Our AI agent runbook guide covers the ownership and recovery work that follows deployment.
Run a customer-specific approval test
- Confirm that only the intended tools are imported into the request.
- Request a sensitive action and inspect the exact approval item and customer-facing preview.
- Deny the action and verify that the destination remains unchanged.
- Change the target after review and confirm that your application requires fresh approval.
- Remove the acting user's permission before execution and verify that the action is blocked.
- Simulate a delayed or uncertain result and check reconciliation before any retry.
- Inspect outgoing read arguments for private information sent to an unintended server.
Write down the observed result for each case. These checks should be part of customer acceptance testing, not a screenshot of a confirmation dialog. Use an agreed test setup and records that will not disrupt real customer work.
Common rollout mistakes
- Copying require_approval never from a public documentation example into a private workflow.
- Approving a plan while hiding the tool's actual destination and arguments.
- Treating allowed_tools as a customer access-control system.
- Keeping one approval valid after the record or proposed action changes.
- Retrying an uncertain write because the earlier call had approval.
- Recording full private payloads in logs without a defined access and retention policy.
How Remqa helps with MCP customer rollouts
Remqa provides forward deployed engineers for AI integrations and customer implementations. Work can include a narrow tool surface, approval screens, execution checks and tested recovery paths. Bring one real customer task and the systems it touches. The first design decision is which calls can run automatically and which need a person to see the exact operation.