Describe a repeatable vetting step: confirm the source and maintainer, read the tool list and requested permissions, scan the dependencies, test in isolation, and record a decision with a review date. Add how you recheck after updates, because approval at install time does not cover later versions.
Why supply chain language shows up here
An MCP server is software, often installed from a package registry, often run with user privileges. It brings its own dependencies. The MCP security guidance lists a malicious payload inside the server itself as one local attack path. Reviewers therefore apply the same questions they ask about any third party component, plus questions about what tools the server hands to a model.
The vetting steps
- Source. Is the code public? Who maintains it? Is the repository active, and does the published package match the repository?
- Dependencies. Generate an inventory of packages the server pulls in and check for known vulnerabilities.
- Tool list. Read every tool name, description and input schema. Descriptions are text a model reads, so treat them as untrusted input. Check whether any tool can write, delete or send.
- Permissions. What credentials does it need and at what scope?
- Isolation test. Run it in a sandbox with network capture. Does it contact hosts you did not expect?
- Decision. Approve, approve with limits, or decline, recorded with a person's name.
What package provenance does and does not tell you
Provenance can show where and how a package was built. It does not say the code is harmless. A malicious maintainer can publish a perfectly provenanced malicious package. Say that in your answer so the reviewer sees you understand the limit. See does npm provenance make an MCP server package safe.
Re-vetting after change
| Trigger | Action |
|---|---|
| New version | Diff dependencies and tool list before upgrading |
| New advisory | Check the register for affected servers |
| Maintainer change | Treat as a new approval |
| Tool list changes | Review before the agent can call the new tool |
| Abandoned project | Plan removal or a fork with an owner |
Pinning versions helps here, because an unreviewed update cannot slip in. See what to do when an approved MCP server is abandoned.
Sample wording
"Before approval, we review the source and maintainers, scan dependencies, read the tool list and test the server in isolation. Versions are pinned. Upgrades and advisories trigger a re-review, and each server has an owner and a review date in our register."
Evidence
One completed vetting record, the dependency scan output and the pinned version list.
Safeguard's SBOM and dependency scanning and reachability analysis help with the dependency step, since reachability shows which vulnerable code a server actually calls. Run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory is built, which is the same step you would run on a server package.
Quick check
Is a popular server safe by default?
No. Popularity is not a security review. Run the same steps for any server before it reaches company credentials.
Do we vet remote servers the same way?
You cannot read the code, so lean on the provider's documentation, data terms and your own testing of what the tools can reach.
Sources
Last reviewed: 19 October 2026.
