Require human approval for tool calls that are irreversible, leave your organization, spend money, change permissions or touch sensitive data. Let read only, easily undone calls run on their own. The MCP specification says there should always be a human in the loop with the ability to deny tool invocations.
What the sources say
The MCP tools specification says that for trust and safety, there should always be a human in the loop who can deny invocations. Applications should show which tools are exposed to the model, show clear indicators when tools are called, and present confirmation prompts. Clients should also show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration.
OWASP's excessive agency guidance names excessive autonomy as a root cause, and recommends human approval for high impact actions.
Neither says to approve everything. A prompt on every call trains people to click yes.
A sorting method
Ask four questions about each tool.
- Can the effect be undone? Sending an email, deleting a record and deploying code usually cannot.
- Does the data leave the boundary? Anything that posts to an external address counts.
- Does it cost money or change who has access?
- Does it touch sensitive data?
One yes means approval. Zero yes means automatic, with logging.
Examples
- Search the knowledge base: Approval: No
- Read a file in the project: Approval: No
- Create a draft: Approval: No
- Send a message to an outside person: Approval: Yes
- Delete or overwrite data: Approval: Yes
- Change a role or permission: Approval: Yes
- Run an arbitrary shell command: Approval: Yes
- Open a pull request: Approval: Depends on policy
Make the prompt worth reading
A good approval screen shows the tool name, the exact arguments, the target system and what will change. A vague line such as the agent wants to use a tool teaches nothing.
Batch low risk reads so that people see only the decisions that matter. Keep a record of each approval and denial, which fits the audit logging the specification asks clients to do.
Do not rely on the prompt alone
Approval does not fix a wrongly scoped credential. A user may approve something that looks fine and still exceeds what the task needs. Keep permissions narrow underneath the prompt.
Review the decisions every quarter
Approval rules go stale. A tool that was low risk becomes high risk when someone widens its credential. Revisit the list on a schedule, and look at the approval log for patterns. If people approve a given call every time without reading, either automate it with narrower permissions or make the prompt clearer.
Where Safeguard fits
Safeguard fix PRs from autonomous remediation are off by default, with every category on Manual, so a person decides. Safeguard also provides policies, gates and guardrails you can use to define what needs review in your own workflows.
Quick check
Should every tool call require approval to be safe?
No. Too many prompts lead to reflexive approval. Reserve it for irreversible, external, costly or sensitive actions.
Sources
Last reviewed: 19 October 2026.
