Do not answer yes or no for the whole system. Split agent actions into read, write and destructive, say which need a human approval, who that human is, what the approval prompt shows, and where decisions are logged. A blanket "yes" will be tested by the next question.
What the specification expects
The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations. It suggests applications provide a clear interface showing which tools are exposed, visual indicators when tools are invoked, and confirmation prompts for operations. For clients, it says they should show tool inputs to the user before calling the server to avoid accidental or malicious data exfiltration, and should log tool usage for audit purposes.
Note the word "should". These are recommendations for clients, so your control is a decision you made, not a protocol guarantee. Say so.
Answer by action class
| Action class | Example | Typical control |
|---|---|---|
| Read | Search tickets, read a file | Allowed, logged |
| Write | Open a pull request, comment | Allowed within a scope, reviewed later |
| Destructive or external | Delete data, send email, deploy | Per action approval by a named role |
Then state which classes are enforced by technology and which by habit. Approval prompts that a user can switch off are a setting, not a control. If you rely on a setting, say who locks it.
What the prompt should show
Reviewers sometimes ask what the human sees. Good approval prompts show the tool name, the full arguments and the target system, not a summary written by the model. A model can describe a command in friendly words while the command does something else. Showing the real input is the point of the check.
Beware approval fatigue
If every action prompts, people click through. A better design allows safe reads automatically and reserves prompts for actions that change something. Say how you decided which is which. See how to review approval prompts and widening tool access in stages.
Sample wording
"Agents may read from approved systems without prompting. Actions that change data in production, send external messages or modify access need approval from the system owner, with the full tool input displayed. Approvals and denials are logged with user and timestamp. Approval settings are managed centrally and cannot be changed by individual users."
If the last sentence is not yet true, remove it.
Evidence to attach
A screenshot of the approval prompt, the policy table above, and a sample log entry with sensitive values redacted.
Safeguard provides policies, gates and guardrails, and autonomous remediation that opens fix pull requests. That feature is off by default and every category starts on Manual, so a human decides first.
Quick check
Can a human in the loop be a pull request review?
For code changes, yes, if the agent cannot merge its own work. For actions outside code, you need an approval step before the action happens.
What if our agents run unattended?
Say so and describe the compensating controls: narrow scopes, allowlisted tools, rate limits and after the fact review of logs.
Sources
Last reviewed: 19 October 2026.
