Installing a community MCP server takes thirty seconds and grants it the right to execute actions with your credentials. No other vendor decision in the company has that ratio between effort and consequence.
What exactly you are trusting
When you add a third-party server you simultaneously trust four things: the code it runs today, the tool manifest it will declare tomorrow, its dependency chain, and the account that publishes updates.
Ecosystem numbers do not help. The official registry passed 9,600 servers by May 2026 and marketplaces list tens of thousands more. An independent scan of 1,808 servers found security issues in 66% of them. And Trend Micro reported CVSS 9.8 command-injection flaws in unofficial AWS and Azure MCP servers — components whose names imply a provenance they do not have.
Typosquatting works because the name is the only thing most people check.
An admission process that fits on one page
- Provenance. Who maintains it, for how long, how many maintainers. A single-maintainer project is both a continuity risk and an account-takeover risk.
- Declared surface. List the tools. Does any execute commands, write to disk or make arbitrary requests? If so, the scrutiny level changes.
- Version pinning. Never install from the latest tag. Pin version and digest, the way you already do with container images.
- Isolation. Run it under its own identity, with no metadata service access and an egress allowlist.
- A named internal owner, responsible for tracking the project's security advisories.
The question that settles most cases
Before installing, ask: would I email this same person a production API key? If the answer is no, installing their server with credentials attached is the same thing, with less of a trail.
