An MCP server is not a webpage the model reads. It is a program you have authorized your AI assistant to invoke, usually running with your user permissions, frequently holding an OAuth token to one of your accounts. The correct mental model is installing a dependency, not opening a link — and the security posture should match.
Most people install them with far less scrutiny than they would give an npm package.
What changed in 2026
- Server directories grew faster than vetting did. Public catalogs now list thousands of connectors, the large majority published by individuals with no review process between the code and your machine.
- Tool poisoning moved from theory to practice. Attacks that hide instructions inside tool descriptions — invisible to the human reading a UI list, fully visible to the model — have been demonstrated repeatedly.
- Cross-server interference got named. A malicious server can emit descriptions that alter how the model uses a different, legitimate server, which breaks the assumption that each connector is independently trustworthy.
- Scope hygiene became the practical control. Since vetting every server is unrealistic, limiting what each one can reach has become the defense that most teams can actually implement.
The threat model in plain terms
| Risk |
How it works |
Practical control |
| Tool poisoning |
Hidden instructions in a tool description steer the model |
Read raw tool definitions, not just the UI list |
| Prompt injection via returned data |
A fetched document contains instructions the model obeys |
Treat all tool output as untrusted data |
| Exfiltration |
A server with file read plus network access ships data out |
Never combine broad read and open network in one trust boundary |
| Over-scoped OAuth |
Connector asks for full account access for one narrow feature |
Grant least privilege; use a dedicated account where possible |
| Supply chain |
A trusted server updates to malicious code |
Pin versions; review diffs on update |
| Credential capture |
Server logs or forwards tokens it was given |
Prefer servers that use short-lived, scoped credentials |
The combination that deserves the most caution is a server that can both read local context and reach the network. Either capability alone is manageable. Together they form a complete exfiltration path, and the model can be talked into walking it by content it retrieves from anywhere.
Controls that actually hold
Start with inventory. Most people cannot list every MCP server currently connected to their assistant, which makes every other control theoretical. Enumerate what is installed, what each one can reach, and which have live OAuth grants.
Then apply least privilege at the account level rather than trying to constrain the model. If a connector needs calendar access, give it a token scoped to calendar, not to the whole workspace. If a server needs filesystem access, point it at a specific directory rather than the home folder. The model cannot misuse capability that was never granted, and this is far more reliable than instructing it not to.
Read the raw tool definitions on anything you install. The description string is what the model actually receives, and it may not match what the connector's README or your client's UI displays. This is where poisoning lives. Our guides to MCP servers and what MCP is cover the mechanics of how those definitions reach the model.
Finally, treat everything a tool returns as untrusted input, exactly as you would treat form data in a web application. The general defenses in prompt injection defense apply directly, and MCP makes them more urgent because the model now has real capability to act on injected instructions.
Common mistakes
- Assuming a popular server is a vetted server. Download counts measure convenience, not review.
- Granting workspace-wide OAuth for a single-feature connector. This is the most common and most consequential mistake, and it is entirely avoidable.
- Running unfamiliar servers on a primary work machine. A container or a spare account costs ten minutes and contains the blast radius.
- Trusting the client UI list of tools. It renders a friendly name. The model reads the full description, which can say something else entirely.
- Never reviewing after install. Servers update. A connector that was safe in March is not automatically safe in August.
FAQ
Is MCP itself insecure?
No — the protocol is a transport and a schema. The risk comes from what individual servers do with the capability you grant them, which is a trust and permissions problem rather than a protocol flaw.
Can a malicious server affect other servers?
Yes. Because all tool descriptions land in the same model context, a hostile description can influence how the model uses unrelated tools. This is the strongest argument for keeping the installed set small.
Are official first-party servers safe?
Safer, in that there is an accountable publisher and usually a review process. Still apply scope limits — a first-party server with an over-broad token is still an over-broad token.
How do I audit what is connected?
Check your client's configuration file for the server list, then check each linked account's third-party app permissions separately. The two lists diverge more often than you would expect, because revoking a server does not always revoke its OAuth grant.
Where to go next
For the underlying protocol, start with what is MCP. To harden the layer above it, read prompt injection defense, and for deciding what an agent should be allowed to do in the first place, AI agent permissions covers the policy side.