One compromised mcp-remote package silently reached over 437,000 developer environments before anyone caught it — CVE-2025-6514 enabled arbitrary command execution on every machine that had pulled the package. Your AI coding agents are now configured with a growing list of MCP servers, most of them added by individual engineers without a security review. The supply-chain hygiene you apply to open-source packages needs a direct equivalent for MCP.
Why MCP Servers Are Not Like Other Dependencies
A passive library sits inert until your code calls it. An MCP server actively returns tool definitions, outputs, and metadata — and your agent trusts all of it by default. A 2025 analysis of 1,899 open-source MCP servers found that 5.5% exhibited tool-poisoning vulnerabilities: modified tool outputs, injected command responses, or data flows redirected to unauthorized endpoints. A separate review of publicly exposed servers found 492 that lacked basic authentication or encryption entirely. These are not theoretical risks — they describe servers already running in developer environments today.
The Coalition for Secure AI's January 2026 analysis catalogued 12 core threat categories spanning nearly 40 distinct threats across MCP systems, with production incidents confirming the exposure — including a tenant isolation flaw that affected up to 1,000 enterprises. One consistent attack pattern is embedding malicious instructions inside tool metadata to prompt-inject the coding agent through its tool calls — bypassing code review entirely because the attack arrives at the tool layer, not in the diff. The MCP gateway threat landscape is broad enough that no single runtime control addresses it all — vetting before onboarding remains the most reliable upstream defense.
Before You Add Any MCP Server: Eight Checks
Run every candidate MCP server through these checks before it appears in any agent configuration file. Any failure is a block on production use until resolved.
Confirm repository provenance. Verify the repository is maintained by a known organization with a consistent, multi-year commit history. Flag recent ownership transfers, commit histories thinner than six months, or mismatches between the published package owner and the source repository org.
Verify authentication and transport security. The server must enforce authentication on every connection — OAuth 2.0 or API key with rotation support — and require TLS for all traffic. Servers missing either control have no meaningful isolation between sessions or tenants. This is the class of flaw that left 492 publicly exposed MCP servers open to abuse in 2025.
Audit tool definitions for injected metadata. Read the tool descriptions and parameter schemas manually. Any instruction-style text embedded in a tool description field — directives to the model, hidden context strings, unusual formatting — indicates tool-poisoning risk and should block onboarding.
Run SAST on the server codebase. If source code is available, apply your existing static analysis tooling to it. Look for hardcoded credentials, outbound network calls to unexpected hosts, and data exfiltration patterns that do not match the server's declared purpose.
Sandbox before production. Run the server in a container with restricted network egress and scoped file-system access. Observe what it actually calls and writes during normal operation — not just what its documentation states it does.
Review permission scopes against least privilege. Locking down MCP server permission scope means matching each server's declared scope to the actual function of its tools. A read-only query tool that requests write access to the file system, or network access it does not need, should not pass this check.
Check package integrity and name legitimacy. For npm-distributed MCP servers, verify checksum integrity and compare the exact package name against what your agent configuration requests. This catches slopsquatting — AI-hallucinated package names that attackers register before legitimate publishers notice the gap.
Set a re-vetting cadence. MCP servers update frequently and ownership can change silently. Schedule re-vetting after any major version bump and when maintainer accounts transfer. A server that passed review six months ago may carry new risk today. Add it to the same rotation as your open-source dependency audits.
re-entry.ai observes every pull request your AI coding agents open and flags when new code introduces calls to MCP servers not previously seen in your environment — giving security teams a review gate before novel tool access merges into production. Visit re-entry.ai to see how pull request risk scoring applies to your agent tool surface.
Start with the servers that hold the highest privilege: file-system access, git history, credentials stores, and database connections. Run each through the eight checks above. Treat any failure as a production block with a 30-day remediation deadline. Most teams have added far more MCP servers than their security posture reflects — the gap between an engineer adding a server and security reviewing it is exactly where incidents begin.