A human approval step for an AI agent works only if the person can see the real action and its inputs. On a phone, that means a clear summary, the exact arguments, and a way to deny. If the prompt is cramped, vague or arrives constantly, treat the approval as weak and move the risky action to a bigger screen.
What the standards say
The Model Context Protocol specification (2025-06-18 revision, tools section) says that for trust and safety there should always be a human in the loop with the ability to deny tool invocations. It says applications should provide a UI that makes clear which tools are exposed to the model, add clear visual indicators when tools are invoked, and present confirmation prompts so a human is in the loop. Its security considerations say clients should prompt for user confirmation on sensitive operations, and show tool inputs to the user before calling the server to avoid malicious or accidental data exfiltration.
OWASP lists Excessive Agency (LLM06:2025) as the risk that an LLM-based system takes damaging actions in response to unexpected, ambiguous or manipulated output. Its mitigations include requiring a human to approve high-impact actions, enforcing authorization outside the model, and logging and monitoring tool activity.
Neither document says approvals must be on any particular device. The point is to make them real.
What a good approval prompt shows
If an agent asks you to approve something on your phone, you should be able to see:
- The action in plain words. "Delete branch release-2" beats "Run tool 4".
- The exact inputs. A path, a command, a recipient, an amount.
- The target. Which repository, host or account.
- The effect. Can it be undone?
- Why the agent wants it, in its own words, kept separate from the data it read.
If any of these is truncated or hidden behind a tap you did not make, deny and look at it on a laptop.
Approval fatigue is the real enemy
A prompt for every file read teaches people to tap Approve without reading. Reserve approvals for high-impact actions and allow low-risk reads by policy. This echoes the problem described in push approval fatigue. The more often you ask, the less each answer is worth.
What belongs on a phone and what does not
Fine to approve from a phone, if the prompt is clear:
- Read-only queries to a system you already trust.
- Creating a draft or a branch.
- Running a scan.
Hold for a bigger screen:
- Anything that sends data outside your organization.
- Deleting or overwriting data.
- Changing permissions, credentials or production configuration.
- Any action whose inputs you cannot read in full.
Prompt injection and the approval screen
Excessive agency often starts with manipulated input: a web page, document or tool result that tells the agent to do something. OWASP names prompt injection, including indirect, as a trigger. An approval prompt that shows an odd target or an action unrelated to your request is a signal. Deny, and check what the agent read before it asked.
Controls that do not depend on your attention
Approvals are one layer. Others:
- Give the agent only the tools it needs, and remove unused ones.
- Use narrow tools, such as a file writer instead of a general shell.
- Run tool calls with the minimum permissions, under the user's own identity where possible.
- Rate limit and log tool calls, so damage is bounded and reviewable.
See our guide on which agent actions should ask first.
Quick check
Does the MCP specification require approval prompts?
It uses should, not must, for the human in the loop. It says there should always be a human able to deny tool calls, and clients should confirm sensitive operations.
What if the approval prompt is too small to read?
Deny it. An approval you cannot read is not a control. Review the full action on a larger screen, then decide.
Sources
Last reviewed: 19 October 2026.
