The Problem
Every MCP security guide ever written — including the one in this module — teaches you to secure a server you built. Validate the paths. Issue capability tokens. Write an audit log. All of it good, all of it correct, and all of it applies to code you control.
Now look at what you actually have installed.
Supabase. Stripe. Gmail. Slack. Notion. Vercel. A browser-control extension. A dozen
connectors you clicked "Connect" on, written by people you will never meet, running on
infrastructure you cannot inspect. You did not write one line of any of them. You cannot add
validate_file_path() to somebody else's Notion server. There is no
CapabilityManager you can drop into Stripe.
This is the normal case now, and it is not the case the security literature covers. When we ran a real audit across our own estate, every single server was third-party. The "patches applied" section of the report came back empty — not because we were lazy, but because there was nothing to patch.
The Core Insight
When you are the client, you cannot change what a tool does. You can only change what is reachable, what is approved, and what shares a context.
Three levers. That's the whole toolkit. Everything below is about using them deliberately instead of by accident.
The server-side model and the client-side model are not the same shape, and confusing them is how people end up feeling secure while being wide open:
| If you built the server | If you installed it | What it actually controls |
|---|---|---|
| Input validation | Scope | Which tools are reachable from this session at all |
| Capability tokens | Approval | Which tool calls actually fire, and how long that consent lasts |
| Audit logs | Isolation | What untrusted text is allowed to sit next to which tools |
Note what fell off the bottom. As a client, you largely cannot audit. We'll come back to that — the honest answer matters more than a comfortable one.