The Hidden Supply Chain in Your AI Agent: Why SBOMs for MCP Servers Matter Now

• Share on Facebook
• Share on LinkedIn
• Share on X

Your AI agent is only as secure as its weakest dependency. Here’s why you need to know what’s inside your MCP servers before you run them.

The MCP Blind Spot

The Model Context Protocol (MCP) has become the “USB-C for AI applications,” letting Claude, ChatGPT, and Cursor connect to external tools in real-time. Microsoft integrated it into Copilot Studio. OpenAI adopted it. Developers are spinning up MCP servers by the thousands.

But here’s the problem: most teams are running MCP servers blind.

They’re connecting AI agents to tools without knowing what dependencies those tools carry, what vulnerabilities exist, or what happens when a “trivia server” turns malicious after installation. The result? A wave of critical vulnerabilities throughout 2025 that security teams are still catching up to.

Real CVEs, Real Damage

CVE-2025-9611 (CVSS 7.2): Microsoft’s Playwright MCP Server failed to validate Origin headers, allowing DNS rebinding attacks. All versions prior to 0.0.40 were affected. Even Microsoft ships MCP servers with security gaps.

CVE-2025-6514 (CVSS 9.6): The mcp-remote OAuth proxy, with 437,000+ downloads and recommended by Cloudflare, Hugging Face, and Auth0, contained a command injection flaw. Malicious MCP servers could achieve full remote code execution on client machines. One bad server, complete system compromise.

CVE-2025-49596 (CVSS 9.4): Anthropic’s own MCP Inspector had an input validation flaw that turned a debugging tool into a remote shell.

Tool Poisoning: Prompt Injection’s Evil Twin

Beyond CVEs, there’s a broader threat. Invariant Labs discovered “Tool Poisoning Attacks” where malicious instructions hide in MCP tool descriptions, invisible to users but visible to AI models.

The key insight: Tool poisoning is prompt injection where the victim is the LLM itself. The AI is being “socially engineered” through tool descriptions it trusts implicitly. Unlike humans who can be trained to spot phishing, LLMs are designed to follow instructions in their context window.

Research found 5.5% of MCP servers exhibit tool poisoning characteristics and 33% allow unrestricted network access. Researchers demonstrated silent exfiltration of entire WhatsApp histories through poisoned servers.

Even worse: the “Rug Pull” method. Attackers submit clean servers for approval, then switch to malicious versions later. MCP servers return new tool descriptions on each connection. Most clients don’t re-verify.

The Shadow AI Crisis

Here’s what should concern every CISO: MCP isn’t just a server issue. It’s a workstation security crisis.

Developers using Cursor, VS Code, or Claude Desktop connect MCP servers to their IDEs without IT oversight, granting file system access, shell execution, and access to environment variables containing API keys. This is Shadow AI, and it’s happening on every laptop in your engineering org.

The MCP server runs locally, communicates over localhost, and looks like legitimate tooling. Your SIEM won’t see it. Your firewall won’t block it.

Case in point: Clawdbot. In January 2026, this AI assistant hit 60,000 GitHub stars in weeks. Then researchers found: no mandatory authentication, hundreds of exposed gateways, API keys and chat histories accessible to anyone. RedLine, Lumma, and Vidar infostealers added it to their target lists within 48 hours.

Why SBOMs Are the Answer

We’ve seen this movie before with containers and npm packages. The solution is the same: you can’t secure what you can’t see.

A Software Bill of Materials (SBOM) tells you what packages your MCP server depends on, what versions are installed, and what vulnerabilities exist. When CVE-2025-6514 dropped, teams with SBOMs immediately knew if they were affected. Teams without SBOMs had to manually audit every integration.

What Gets Scanned

Node.js servers: package.json, package-lock.json, native modules, bundled dependencies

Python servers: pyproject.toml, requirements.txt, poetry.lock, C extensions

The challenge: traditional SBOM tools often miss build-time dependencies that execute during npm install or pip install without leaving traces in the runtime dependency tree.

Beyond SBOMs: VEX

Not every CVE is exploitable in your context. VEX (Vulnerability Exploitability eXchange) is a companion to SBOMs that signals which CVEs are actually affected, not affected, or fixed in your specific implementation. This reduces “vulnerability fatigue” and focuses remediation on real risks.

SBOM Tools for MCP Servers

Syft: Open-source, generates CycloneDX/SPDX formats. Works with containers and filesystem paths.

syft dir:./my-mcp-server -o cyclonedx-json=sbom.json

Trivy: Vulnerability scanner with SBOM generation. Strong for containerized servers.

trivy fs ./my-mcp-server --format cyclonedx --output sbom.json

Incredibuild BuildGuard: For higher accuracy, BuildGuard generates SBOMs using build metadata and AI analysis rather than manifest parsing alone. It instruments the build process itself, capturing actual compiler invocations, build-time dependencies, and dynamic dependencies. This catches what manifest scanning misses, particularly valuable for MCP servers with native modules where “declared dependencies” and “actual dependencies” diverge.