You installed an MCP server package six months ago, reviewed it at the time, and it passed your checks. Yesterday the maintainer’s npm account was compromised and a new version was published that silently exfiltrates conversation context to an external endpoint. Your CI pipeline installed the latest version this morning. The symptom: your agent starts making unexpected outbound connections to an unfamiliar host, or you find sensitive data appearing in logs that should only exist in the agent’s memory. Supply-chain attacks against AI tooling are a documented risk — MCP servers run inside your agent process with access to file system, environment variables, and tool calls. A compromised server has the same permissions as a legitimate one. Defenders detect this by monitoring package hashes, network egress, and tool call anomalies.
Common causes
1. Package installed without pinned version
npm install @vendor/mcp-server without a lockfile or exact version pin means the next npm install on a fresh machine may pull a newer, compromised version.
How to spot it: Check your package.json for "@vendor/mcp-server": "^1.0.0". The caret allows minor/patch upgrades. A compromised 1.0.1 installs automatically.
2. No integrity check on installed packages
Most package managers support integrity hashes (npm’s integrity field in package-lock.json). If the lockfile was not committed, or was committed without the integrity field, there is no tamper detection.
How to spot it:
# Check whether your lockfile contains integrity hashes
grep -c '"integrity"' package-lock.json
# Count should be > 0 and roughly equal to the number of installed packages3. MCP server spawned with excessive environment access
The server process inherits the full environment of the parent process, including every OPENAI_API_KEY, DATABASE_URL, and AWS_SECRET_ACCESS_KEY visible in the shell.
How to spot it: Log the environment variables visible to the MCP server process. Any key not explicitly needed by the server is an unnecessary exposure.
4. Outbound network access not restricted
The MCP server can make arbitrary outbound connections. A compromised server opens a connection to its command-and-control host and streams context data.
How to spot it: Check firewall rules or network logs for the process running the MCP server. Any outbound connection to a host not in an explicit allowlist is suspicious.
5. Auto-update enabled in CI/CD pipeline
Your deployment pipeline runs npm install or pip install without a lockfile, pulling the latest version of every dependency on each deploy. A malicious release lands in production within hours.
How to spot it: Review your Dockerfile, CI YAML, and deployment scripts. Any line that installs packages without a lockfile or without --frozen-lockfile / --ci flag is a supply-chain risk.
6. MCP server dependencies are also attack surface
The server itself may be clean, but one of its transitive dependencies was compromised. A nested node_modules package with network access can be just as dangerous.
How to spot it: Run npm audit or pip-audit on the project to check for known vulnerabilities in transitive dependencies. Use npm ls @vendor/mcp-server to inspect the full dependency tree.
Shortest path to fix
Step 1: Pin exact versions and commit the lockfile
// package.json — use exact versions, not ranges
{
"dependencies": {
"@vendor/mcp-server": "1.2.3"
}
}# Commit the lockfile to version control
git add package-lock.json
git commit -m "pin mcp-server to 1.2.3 with lockfile"Step 2: Verify package integrity on install
# npm -- use --frozen-lockfile to prevent installing versions not in lockfile
npm ci # uses package-lock.json exactly, fails if it would change
# pip -- use hash-checking mode
pip install --require-hashes -r requirements.txt
# requirements.txt with hashes:
# vendor-mcp-server==1.2.3 --hash=sha256:abc123...Step 3: Restrict the MCP server’s environment access
// Spawn MCP server with an explicit, minimal environment
import { spawn } from "child_process";
const mcpProcess = spawn("npx", ["@vendor/mcp-server"], {
env: {
PATH: process.env.PATH,
// Only pass what the server actually needs
MCP_SERVER_TOKEN: process.env.MCP_SERVER_TOKEN,
// Do NOT pass: OPENAI_API_KEY, DATABASE_URL, AWS_* etc.
},
stdio: ["pipe", "pipe", "pipe"],
});Step 4: Restrict outbound network access at the OS level
# macOS — use pf or Little Snitch rules for the node process
# Linux — use iptables or nftables
# Example: allow only specific outbound hosts for the MCP server process
# using a network namespace or firewall rule scoped to the process UID
iptables -A OUTPUT -p tcp -m owner --uid-owner mcp-server-user ! -d 10.0.0.0/8 -j REJECTStep 5: Monitor for anomalous tool calls and network connections
// After every tool call, check against expected patterns
const EXPECTED_TOOL_CALLS = new Set(["read_file", "write_file", "list_directory"]);
function auditToolCall(toolName: string, sessionId: string): void {
if (!EXPECTED_TOOL_CALLS.has(toolName)) {
logger.error({ event: "unexpected_tool_call", tool: toolName, sessionId });
// Alert on-call
throw new Error(`Unexpected tool call blocked: ${toolName}`);
}
}Step 6: Run package-hash verification in CI before deployment
#!/bin/bash
# ci/verify-mcp-hashes.sh
EXPECTED_HASH="sha256:abc123def456..."
ACTUAL_HASH=$(sha256sum node_modules/@vendor/mcp-server/dist/index.js | cut -d' ' -f1)
if [ "sha256:$ACTUAL_HASH" != "$EXPECTED_HASH" ]; then
echo "SECURITY: MCP server hash mismatch — aborting deploy"
echo "Expected: $EXPECTED_HASH"
echo "Got: sha256:$ACTUAL_HASH"
exit 1
fi
echo "MCP server integrity verified."Prevention
- Always pin exact package versions for MCP servers and commit the lockfile; never use range operators (
^,~) for security-sensitive dependencies. - Run
npm ci(or equivalent) in CI/CD to enforce the lockfile — nevernpm installwithout a lockfile in automated pipelines. - Spawn MCP server processes with a minimal, explicitly defined environment — never inherit the full parent process environment.
- Restrict outbound network access for the MCP server process using OS-level firewall rules or a network sandbox.
- Subscribe to security advisories for every MCP server package you use — many package registries offer email notifications for new versions.
- Audit the full dependency tree (
npm ls,pip-audit) of each MCP server before installing it in a production environment. - Log and alert on any tool call not in your expected tool-name allowlist.
- Review the changelog and diff for every MCP server version upgrade before updating the pinned version in production.
FAQ
Q: How quickly can a compromised npm package reach my production environment?
A: If you use npm install (not npm ci) with a non-exact version range and no lockfile, within hours of a malicious publish. A lockfile-pinned deployment is protected until you deliberately update the pin.
Q: Should I fork and host MCP servers myself? A: For security-sensitive production deployments, yes — forking and hosting a pinned version under your own registry gives you full control over when updates land and lets you code-review every change before applying it.
Q: How do I check if my current install was already compromised? A: Compare the SHA-256 hash of each MCP server file against the hash from a known-good version. Check your network egress logs for outbound connections made by the agent process to unknown hosts during recent sessions.
Q: What is the difference between a tool-poisoning attack and a supply-chain attack? A: Tool poisoning modifies the tool description/behavior that flows to the model without changing the installed code. A supply-chain attack modifies the installed code itself. Both result in unexpected behavior but require different detection methods — manifest auditing for the former, file-integrity checking for the latter.