An approval step protects you only when the person sees the exact action, with its target and arguments, and approves that action rather than a summary of it. OWASP recommends human approval for high impact actions and says the approval should be verified for the specific operation.
Which actions to gate
You cannot ask for approval on everything. People stop reading. Gate the actions that are hard to reverse or that move data out:
- Sending messages or email.
- Deleting or overwriting records.
- Spending money or changing billing.
- Changing permissions or credentials.
- Anything that calls an external system with data from the conversation.
Read only actions can usually run without approval, which keeps the approval queue short enough to be meaningful.
What the approver should see
OWASP's cheat sheet says approval should be based on the operation, the target, the arguments and the caller's authority. In practice, show:
- The tool name and the exact arguments, not a paraphrase.
- The target system or recipient.
- Who or what requested it, and on whose behalf.
- What content the model read just before proposing it, if that is practical.
The reason for item four is the confused deputy problem. If an email told the model to forward data, the approver should be able to tell that the request did not come from the user.
Bind approval to the action
Approving "send the report" and then letting the model send a different message is not approval. Tie the grant to the exact payload and make it single use. If the arguments change, ask again.
Avoid rubber stamp fatigue
Keep prompts rare and specific. Batch low risk items. Use defaults that are safe if ignored. Track how often approvals are granted without any edit or delay, because a near perfect approval rate is a sign that nobody is reading.
Approval is a backstop, not a substitute for narrow permissions. OWASP also advises minimising extension functions and permissions so there is less to approve.
Click through it at your own pace, or open it full screen.
Safeguard's MCP Guardrail and agent identity features are built for this kind of control over tool calls, with policies that set what each agent may do.
Common mistakes. Showing a natural language summary instead of the real call is the most common one, because the summary can hide a changed recipient or an extra argument. Another is approving once for a whole session. Approval should be per action, or per narrowly defined class of action with clear limits. A third is giving approvers no way to say why they refused, which removes the signal you need to tune the system.
Quick check
Is a confirmation dialog the same as human in the loop?
Only if the dialog shows the real action and the approval is tied to it. A generic "Continue?" is not enough.
Sources
Last reviewed: 19 October 2026.
