Tool Calling and Human Approval: Designing the Permission Boundary

Evidence check: 25 October 2026. Product details reflect the referenced documentation observed at this cutoff; exact plans, prices, regional eligibility and unverified release dates are not claimed. This is an editorial guide, not a hands-on test.

The model requests; the application executes

A function-call interface exposes named operations and argument schemas to a model. The model can return a proposed tool call, but the application is responsible for validating its arguments, authenticating the caller, applying policy and actually invoking the service. Structured schemas reduce malformed arguments; they do not establish that an operation is sensible or permitted. Treat a model-generated customer ID, amount, path or URL as untrusted until independently checked against the authorized scope.

Make privileges specific

Offer a read-only get_order_status separately from refund_order, and a draft_email separately from send_email. Bind credentials to the user’s identity and minimum necessary scopes rather than letting an agent inherit a powerful service account. Time-limit any delegated credential. An approval must refer to a concrete proposed action, its target, the effect, and the exact payload—not to a broad sentence such as “you may help with billing.”

Approval is a state transition

A safe write path uses proposed → validated → awaiting_approval → approved → executing → verified, with rejected and expired branches. Record the approver, approval timestamp and content hash of what was approved. If the model changes a recipient or amount after approval, that is a new proposal. Do not approve a plan and silently permit unlimited later deviations.

Why framework guardrails are not enough

Guardrail hooks may apply only to certain categories of tools. OpenAI’s Agents SDK, for example, distinguishes function-tool guardrails from handoff behavior and hosted tools. A production application still needs central enforcement in the actual execution layer: authorization checks, rate limits, domain allowlists and transaction controls. Cross-agent handoffs should not expand a session’s capabilities.

Recovery and audit

Retry network reads conservatively, but avoid blindly replaying writes. Before retrying a charge, refund, shipment update or email, query whether the first operation committed. Attach a unique idempotency key where the service allows it. Audit both denied and approved attempts; keep raw secrets and unnecessary personal data out of traces. Test a compromised document trying to make the agent call a privileged tool, because good behavior on friendly prompts proves little.

When to choose an alternative

If every input maps unambiguously to an action, use a rules engine or conventional API client and reserve an LLM for explanation. For irreversible actions, prefer prepare-and-confirm rather than delegated autonomy.

Design a tool manifest before a prompt

For every tool, write a contract containing its owner, input schema, output schema, identity scope, data sensitivity, whether it is read-only, reversibility and maximum call frequency. For example, get_order(order_id) may return only the authenticated customer’s order, whereas refund_order(order_id, amount) must require an operator token and a signed approval bound to the exact order and amount. Tool availability should be derived from the calling user’s authorization, not an enthusiastic request in the conversation.

Bind approval to immutable inputs

Show reviewers the precise target record, action, destination, scope and a plain-language difference from the current state. Store the approval alongside a hash of those parameters. Reject execution if the object changed, a token expired or the model regenerated different arguments after approval. A dry-run can provide useful preview data, but it must be an independently implemented dry-run rather than a side effect hidden behind a “preview” label. Keep approval and execution timestamps for investigating duplicate requests and failed deliveries.