Risk-tier the prompts: batch low-risk reads, individually confirm destructive or high-privilege calls, and always show the user what the model actually sees.
Think of a building's security desk like a gatekeeper. If the guard stops every single person for a full ID check, the line backs up and the guard starts waving people through without looking. If the guard waves everyone through, there's no security at all. The smart desk lets badged staff walk straight in but stops anyone carrying a large box or heading for the vault. MCP tool approval works the same way. Reading a public web page is a badged employee, just let it through. Deleting files or sending money is the person heading for the vault, so the system stops and asks you, showing exactly what will happen, before it acts.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
MCP gives a host application a clean way to plug into external tool servers, but it deliberately does not enforce sandboxing at the protocol level. That design choice pushes the entire trust burden onto the host. The question of when to ask the user for approval, and what to show them, is therefore not a cosmetic UX detail. It is the primary security control in the whole system.
This question is really about a tension every host designer faces. Prompt too often and users stop reading. Prompt too rarely and consent becomes meaningless. The correct answer, risk tiering, resolves the tension by spending the user's limited attention only where harm can actually occur.
This deep dive covers why the two extreme designs fail, how a risk-tiered policy classifies operations, why the content of the prompt is the real defense against MCP's signature attacks, and how to harden the flow in production.
Why both extremes fail
Start with per-call approval, option B. It feels maximally safe because every action gets a human check. In practice it backfires. A coding agent might issue dozens of read calls in a single task. After the user clicks 'allow' ten times in a row, the eleventh prompt gets a reflexive click, not a decision. This is approval fatigue, and it is well documented across security UX, from browser permission prompts to mobile app dialogs.
The failure is subtle. The prompts still appear, so the system looks secure, but the human signal behind each click has gone to zero. The dangerous call that finally arrives gets the same reflexive yes as the harmless ones before it. Worse, fatigue is sticky: once a user has learned that prompts are noise, even a redesigned, genuinely important prompt inherits that learned dismissiveness. The cost of over-prompting is not just friction in the moment, it is the long-term erosion of the prompt's signal value.
Now the other extreme, options A and D. 'Allow all from this server forever' or 'auto-approve and log it later' both remove the boundary entirely. A log you read after a file was deleted or a payment was sent does not undo the harm. The notification log in option D is especially seductive because it feels like accountability, but accountability after an irreversible action is not consent. These designs optimize for zero friction and deliver zero consent, which is exactly the posture a malicious server is hoping you adopt. The lesson is that security and usability are not opposite ends of one slider here. Both extremes of that slider fail, which is precisely why a tiered policy in the middle is the answer.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Approach | Friction | Consent quality |
|---|---|---|
| Allow-all-forever per server | None | None; one click signs away everything |
| Per-call approval for everything | Maximum | Degrades to zero via fatigue |
| Risk tiering (batch reads, gate writes) | Targeted | High where it matters |
| Auto-approve plus after the fact log | None | None; harm already happened |
Real products, models, and research that use this idea.
- Claude Desktop and Claude Code prompt per tool call and offer an allow for this session grant rather than a permanent blanket approval.
- Cursor surfaces the MCP server name and tool arguments in its approval dialog so users can see what is being invoked.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you classify an MCP tool into a risk tier automatically, before any human has reviewed it?
Start from declared side effects and scopes, but trust nothing; default unknown or unannotated tools to the high-risk tier and require explicit human review to demote.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Treating approval UX as a checkbox instead of the real defense. If users click through prompts without reading, poisoned tool descriptions sail right past them.
60 second bullets to scan on the way to the call.
Why per-call approval causes approval fatigue
Why blanket approve-all destroys consent
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.