Describe the MCP host approval model and explain what granularity of consent a well designed host should require from the user.
In MCP the host, not the protocol, is the trust boundary: it surfaces every tool call for consent, scopes what each server may do, and picks the approval granularity.
Think of a building with one security desk. Vendors (the servers) show up offering services, but none can walk in and touch anything on their own. Every action goes through the front desk (the host), which asks you, the resident, before letting a vendor open a door or move a box. A lazy desk hands out a master key on day one, so a window-cleaner could empty your apartment. A careful desk asks before risky jobs but waves through harmless ones, like reading the lobby notice board. The protocol just defines how vendors describe their services. It is the desk that decides what they are actually allowed to do, and what to check with you first.
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.
The MCP host approval model is one of those topics that sounds like UX trivia but is really about where trust lives in an agent system. The single most important sentence to internalize: in MCP, the host is the trust boundary, not the protocol. Interviewers probe this because candidates routinely assume the wire protocol is doing safety work it never promised to do.
MCP is deliberately thin. It standardizes how a server advertises tools, resources, and prompts over JSON-RPC, and how a host invokes them. It does not define sandboxing, permissioning, or consent. Those are explicitly left to the host application, the piece of software the user already trusts and runs locally, such as Claude Desktop, Claude Code, Cursor, or Zed. The spec describes a contract for capability discovery and invocation, nothing more.
That design choice has a direct security consequence. If the host is sloppy about consent, nothing else in the stack will save the user, because there is no second line of defense below it. This deep dive walks through why the host carries the burden, what granularity of consent makes a prompt meaningful, the two ways approval models fail, and how allowlisting trades safety for usability against the rug pull threat.
Why the host is the trust boundary
An MCP server is just a process that advertises capabilities. It can describe a tool called delete_file with a friendly description, and the protocol will faithfully carry that description to the host. The protocol has no opinion about whether deleting a file is safe. It also has no sandbox: once the host dispatches tools/call, the server runs whatever code it wants with whatever privileges the host process holds.
That means the only place trust can be enforced is the host. The host is the component the user installed, configured, and granted access to their filesystem, credentials, and network. The model is an untrusted planner that proposes actions. A server is an untrusted capability provider. The host is the referee that stands between them and the user's actual resources.
A clean way to say it in an interview: the model proposes, the server provides, and the host disposes. Consent, scoping, and execution gating all converge on that one component. If you find yourself saying "MCP prevents the server from doing X," stop, because MCP almost never prevents anything. The host does.
This is also why the install-time decision to add a server is the heaviest trust act in the whole flow. Once a server is in the config, it is inside the same process boundary as the host's credentials. The runtime consent prompts are a second, finer layer of defense on top of that initial connection decision, not a replacement for thinking carefully about which servers you trust enough to spawn at all.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Granularity | User burden | Safety | Best for |
|---|---|---|---|
| Blanket approve-all | None after first prompt | Poor, hides destructive calls | Anti-pattern, avoid |
| Per-server | Low | Floor, weak inside a server | Trusted single-purpose servers |
| Per-tool or per-category | Moderate | Strong for side effects | Writes, network, secrets |
| Per-call always | High, causes fatigue | Strong on paper, weak in practice | Rarely, only highest risk |
Real products, models, and research that use this idea.
- Claude Desktop and Claude Code prompt the user before a discovered MCP tool runs, showing the server origin and tool name.
- Cursor and Zed both gate MCP tool execution through the editor host, so the user approves connection and risky calls.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does allowlisting safe tools interact with a rug pull attack on an MCP server?
An allowlisted tool can be silently redefined after approval; pin the schema, re-prompt on any change, and surface provenance so a swap is visible.
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.
Assuming the protocol enforces safety. MCP defines no sandboxing or consent. The host is the trust boundary, and a blanket approve all destroys it.
60 second bullets to scan on the way to the call.
Why the host, not the protocol, is the trust boundary in MCP
The three host responsibilities: connect, scope, gate
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.