In November 2024, Anthropic open-sourced the Model Context Protocol (MCP) to give AI agents a standard way to call tools, read files, and query databases. Twenty months later, public MCP server directories like mcp.so and Smithery list well over 10,000 servers, and enterprise teams are wiring them directly into Slack, GitHub, Jira, and internal data warehouses. Each server is effectively a new, often unaudited, remote code execution surface sitting inside the blast radius of an autonomous agent with real credentials.
Security researchers have already shown this goes wrong in production: tool-poisoning attacks that hijack GitHub Copilot-style agents, a cross-tenant data exposure in a widely used SaaS MCP integration, and "rug pull" servers that behave safely during review and change behavior after installation. Traditional software composition analysis, built for pinned package versions and static dependency graphs, was not designed to catch a tool description that silently changes its instructions at runtime. This post breaks down how MCP servers and agent skills are actually being attacked, why conventional supply chain tools like Endor Labs stop short of covering this surface, and what a real MCP security program requires.
What Makes MCP Servers a Fundamentally New Attack Surface?
MCP servers are dangerous because they collapse three previously separate trust boundaries — code execution, data access, and natural-language instruction — into a single interface an LLM interprets at runtime. A traditional npm or PyPI package is reviewed once, pinned by hash, and only does what its compiled code does. An MCP server exposes a description of its tools in plain English, and the agent's behavior is steered by that description every time it plans a task. Invariant Labs' April 2025 research on "tool poisoning attacks" demonstrated that a malicious or compromised MCP server can embed hidden instructions inside a tool's metadata — invisible in the UI, but read and obeyed by the model — telling it to exfiltrate SSH keys or environment variables while performing an unrelated, legitimate-looking task. Because MCP has no built-in code signing, provenance attestation, or version-pinning convention as of mid-2025, an enterprise connecting to a third-party server is trusting a live, mutable surface, not a reviewed artifact.
How Are Attackers Already Exploiting MCP Servers and Agent Skills?
Attackers are exploiting MCP through prompt injection embedded in tool metadata, cross-server "shadowing" of trusted tools, and post-install behavior changes, and each has already produced real incidents. In May 2025, Invariant Labs disclosed a vulnerability in the official GitHub MCP server: a public issue containing hidden instructions could manipulate an agent with repo access into leaking data from the user's private repositories, entirely through normal-looking tool calls. In June 2025, Asana disclosed an MCP integration bug that exposed cross-tenant data between May 1 and June 4 due to insufficient session isolation in its server implementation. Researchers have also documented "rug pull" attacks, where an MCP server passes initial security review with benign tool descriptions, then updates them post-deployment once agents are already configured to trust it — a scenario static, point-in-time reviews cannot catch because there is no re-scan trigger tied to a description change. A related technique, "line jumping," lets a malicious server intercept and rewrite the output of a legitimate tool call before the agent sees it, bypassing approval prompts that only cover the initial request.
Why Do Traditional AppSec and SCA Tools Like Endor Labs Miss This Risk?
Traditional software composition analysis tools miss MCP risk because they were architected to score known packages against CVE databases and reachability graphs, not to evaluate natural-language tool descriptions or runtime agent behavior. Endor Labs has built genuinely strong reachability-based SCA — determining whether a vulnerable function in a dependency is actually called by your code, which cuts alert noise dramatically for traditional open source risk. But that model assumes a static call graph: function A calls function B, and a scanner can prove reachability by parsing code. An MCP server's "call graph" is decided by an LLM at inference time based on a tool description that can differ from what the server actually executes, can change between requests, and can be conditioned on the content of the conversation itself. There is no CVE for "this tool description contains an indirect prompt injection targeting Claude's planning step," and no package-manifest field capturing which internal data sources an agent skill is permitted to touch once installed. Enterprises running Endor Labs (or similar SCA/SBOM tooling) for their dependency tree still have a governance gap the moment an engineer adds an MCP server to Claude Desktop or a Copilot agent config, because nothing in that pipeline inspects tool semantics, monitors post-install drift, or gates what the agent is allowed to do with the access it's been granted.
What Does an MCP Security Program Actually Require?
An MCP security program requires inventory, provenance verification, and behavioral runtime controls, because the risk lives in both what a server claims to do and what it does after approval. Inventory comes first: most organizations piloting agentic AI in 2025 could not produce a list of every MCP server connected to a production data source, because installation happens at the developer-config level (a JSON file in ~/.config or a Claude Desktop settings pane) rather than through a central package manager with audit logging. Provenance verification means checking server publishers, diffing tool descriptions against a known-good baseline at every startup, and flagging semantic changes — not just version bumps — as re-review triggers. Behavioral controls mean enforcing least-privilege scopes per tool call (a Jira MCP server should not be able to also read .env files), sandboxing execution so a compromised server cannot pivot to the host filesystem, and logging every tool invocation with the same rigor as a production API call, since that log is often the only evidence available after an incident like Asana's.
How Should Enterprises Govern Agent Skills at Scale?
Enterprises should govern agent skills the same way they govern third-party OAuth apps — with a central registry, approval workflow, and continuous re-verification — rather than leaving adoption to individual developer configs. Anthropic's own Agent Skills format, introduced in 2025 alongside expanded Claude Code capabilities, packages instructions, scripts, and resources that an agent can load dynamically, which multiplies the same trust problem MCP has: a skill can look identical in its manifest and change what it instructs the model to do at load time. Without a registry, a single engineer installing an unreviewed community skill to save an afternoon of work can hand a production agent tool access it was never scoped to receive. A workable model treats each skill and server like a vendor: onboarding review, a documented least-privilege scope, an expiration or re-attestation date, and automatic quarantine if its published description or code hash changes unexpectedly — mirroring the SBOM discipline mature AppSec teams already apply to open source dependencies, extended to cover natural-language tool surfaces.
How Safeguard Helps
Safeguard extends software supply chain security to the parts of the AI stack that dependency-focused tools like Endor Labs don't reach. We maintain a live inventory of every MCP server and agent skill connected across your engineering organization — pulled from developer configs, CI pipelines, and agent runtimes — so security teams stop discovering exposure after an incident report. Every server is fingerprinted on first connection and continuously re-diffed against that baseline, so a tool-poisoning update or a rug-pull behavior change triggers an automatic quarantine and alert instead of silently persisting until an external researcher finds it. Our runtime policy engine enforces least-privilege scoping per tool call, blocking an MCP server from reaching data or systems outside its declared purpose even if its description tries to claim broader access mid-session. And because MCP and agent skill risk doesn't exist in isolation from the rest of your software supply chain, Safeguard correlates findings with your existing SBOM, dependency, and CI/CD posture, giving you one place to answer the question every CISO is now asking their AI teams: which agents, connected to which servers, can touch which data — and can we prove it changed since last week's review.