Add approval gates to OpenAI Agents SDK tool calls

Key takeaways

• Use SDK interruptions to signal "this tool call needs approval."
• Preserve run state across the pause so resume is deterministic.
• Keep read-only tools outside the approval path.
• Deduplicate approval requests by run id plus tool call id.
• Route risky tool calls through the organization: role ownership, shift coverage, escalation, signed callbacks, and an audit trail.

Start with the risky tool boundary

OpenAI Agents SDK approval design starts with the tool catalog. Some tools are safe for the agent to call freely: search, retrieve, classify, summarize, draft, enrich, or inspect. Other tools change the world. Those are the tools that should interrupt and wait for a human decision.

Do not make approval a vague prompt instruction. Make it part of the runtime contract around specific tools: refunds, payments, access changes, customer sends, production writes, policy exceptions, or anything with legal, financial, security, HR, or brand impact.

• Keep read-only and low-impact tools fast.
• Gate write tools before the action executes.
• Use a stable run id plus tool call id for idempotency.
• Resume with an explicit approved or rejected result, not an ambiguous free-text message.

Pattern for OpenAI Agents SDK

• Identify tools that need approval vs read-only tools.
• Create a request at each interruption with run + tool call ids.
• Resume on approve or reject explicitly.
• Persist correlation data and deduplicate retries.

Organization-in-the-loop, not approval theater

Contro1 is human-in-the-loop done right, and then it goes further: it puts the whole organization in the loop, giving you the full suite to govern agents: policy triggers, approval hierarchy and quorum, shift coverage, role routing, and SLA escalation, now wrapped around OpenAI Agents SDK tool calls. Every risky action lands with whoever would have owned the decision anyway, not just whoever happens to be online.

The agent still does the hard work: gathering context, preparing the action, drafting the response, and moving the workflow forward. The management, accountability, and final business decisions stay with the people who owned them before agents entered the process.

That matters most when the agent is ready to call a dangerous tool. The reviewer sees the context, the request routes to the right owner, the SLA starts, missed decisions escalate, the callback is signed, and the audit trail records what happened. Agents should not perform dangerous actions on their own authority.

Use the OpenAI Agents human approval connector

If you are building on OpenAI Agents SDK, use the Contro1 connector instead of wiring every interruption, approval request, callback verification, and resume branch yourself. It gives you the framework-specific bridge for mapping tool-level interruptions to Contro1 approval requests and returning decisions to the run.

Open the OpenAI Agents human approval connector

Minimal implementation flow

• Classify tools into autonomous, approval-gated, and forbidden categories.
• For each approval-gated tool, create a Contro1 request before executing the underlying action.
• Use the OpenAI Agents run id as the correlation id and the tool call id as the external request id.
• Pause the run while the operator approves, rejects, comments, or escalates.
• Verify the signed callback and resume the run with a structured approval result.
• Log both approved and rejected outcomes so the audit trail reflects the real decision path.

What the approval request should include

A human reviewer should not need to reverse-engineer the agent trace to understand the decision. The approval request should read like a compact business case for the tool call.

• The tool name, proposed arguments, and system the tool will affect.
• The customer, account, ticket, payment, deployment, employee, or record involved.
• Why the agent believes the action is appropriate, with evidence and uncertainty.
• The risk of approval, the cost of rejection, and the fallback path on timeout.
• The owner, SLA, escalation route, and audit metadata required by the organization.

Failure modes to avoid

• Letting the model decide whether a policy-required tool call needs approval.
• Approving a natural-language intent while the actual tool arguments can still change later.
• Routing every approval to a shared channel with no named owner or escalation path.
• Resuming from an unsigned callback or a manually triggered endpoint.
• Creating duplicate approval requests when the same run retries the same tool call.
• Treating rejection as an exception instead of a normal tool outcome the agent can handle.

Frequently asked questions

Can one run create multiple approval requests?

Yes. That is normal when a workflow touches multiple risky tools or distinct approval domains.

How do I keep the non-risky tools fast?

Do not route them through approval. The SDK will only interrupt for tools you explicitly mark as requiring approval.

What if the human rejects?

The SDK emits a rejection event. Handle it like any other tool result - the agent can choose a fallback or end the run.

Related resources