Topic 8: Supply chain risk

Every server you install is code you run, and much of it is code you did not write. Installing a third-party MCP server is exactly as risky as installing any third-party dependency, with an extra twist: the server's tool descriptions and results feed a model that acts. A compromised or malicious server does not need a memory-corruption exploit; it can just poison a description or return a steering result, as the earlier parts showed.

Three practices reduce this risk, none of them novel, all of them worth insisting on.

Pin versions. Do not install a server (or its dependencies) at a floating "latest." Pin an exact version you reviewed, the way requirements.txt in this project pins mcp==2.2.0. A pinned version cannot silently update into a poisoned one, and it makes the rug-pull defence from Part 3 stronger: you are pinning both the tool definitions at runtime and the code that produces them at install time.

Review the code. Read what a server does before you run it, in proportion to the authority you will give it. Look for where it makes outbound network calls, what it reads from disk, what it puts into tool descriptions and results, and whether descriptions contain instruction-like text aimed at the model. The MCP Registry and a server's server.json (Module 9) help you find the source and version; they do not vouch for the code. A "verified" listing is a starting point for your own review, not a substitute for it.