Insert explicit human approval steps into agent tool loops to block unintended outbound, financial, or destructive actions.
Mark high-risk tools at registration
At tool definition time, tag any function that performs external mutation: outbound messages, payment APIs, file or record deletion, or permission changes. Store the tag in the same registry the agent reads so the loop can branch before execution rather than after. Without this flag the agent treats every tool as safe and will fire it on the first plan that reaches it.
Common failure mode is missing the tag on a wrapper function that internally calls a risky endpoint. Review the full call graph during registration and re-check after any dependency update. A single untagged wrapper has produced duplicate sends and accidental deletes in multiple deployed loops.
Pause the loop and surface the proposal
When the agent reaches a tagged tool, halt the ReAct or graph step, serialize the exact arguments, and emit a pending action record to a durable queue or database. Return control to the user interface with the proposed payload and a unique approval token. The agent thread remains suspended until the token is resolved; this prevents the next LLM turn from proceeding on stale state.
Use the same queue for both human and automated approvals so the code path stays identical. Store the full argument JSON and a hash of the tool definition to detect drift if the schema changes between proposal and execution.
Gate payments and deletes with extra checks
For payment tools, require the confirmation record to include an explicit amount and currency match plus a second factor such as a one-time code or account-level approval. Cache the pending transaction ID on the approval token so a retry after network failure cannot create a second charge. If the payment provider returns a webhook, reconcile it against the same token before releasing funds.
Deletion tools need a preview of affected rows or objects plus a count. Present the count and a sample of identifiers; require explicit confirmation that the user accepts permanent loss. After confirmation, run the delete inside a transaction that also writes an audit row containing the approval token and actor. This gives a single place to query what was removed and why.
Log outcomes and handle denial or timeout
On approval or denial, write the decision, actor, and timestamp back to the same record that held the proposal. Feed the result into the agent state so the next turn can branch cleanly: approved paths continue with the tool result, denied paths receive an explicit “user declined” observation. Timeouts should default to deny and surface a clear error to the agent so it does not retry the same call in a loop.
Keep the approval records for at least the retention period required by any connected financial or compliance system. This log becomes the source of truth when debugging why an action did or did not execute and when tracing cost or rate-limit events back to a specific human decision.