There is now solid defensive research on Model Context Protocol security. Academic threat modelling of tool poisoning, a defence-placement taxonomy with coverage analysis, and NSA guidance on MCP security all converge on a sensible layered approach: static metadata analysis, decision-path tracking, behavioural anomaly detection, and user transparency.
Every one of those defences shares an unstated precondition. You have to know which MCP servers your organisation is actually connected to.
In most organisations, nobody does. That gap is the reason the research has not translated into deployed defence.
Why MCP inventory is uniquely bad
Traditional software arrives through channels that leave records. Procurement, a change request, a Dockerfile, a dependency manifest, a deployment pipeline. Even shadow IT usually leaves a SaaS invoice or an SSO grant.
MCP servers arrive differently:
A developer edits a local JSON config. No approval, no ticket, no artefact. The config lives on a laptop.
They are trivial to write. An MCP server is a small program. Developers write internal ones in an afternoon, for themselves, and never register them anywhere.
Installation is often a copy-pasted command. From a README, a blog post, or a model's own suggestion — into a config file that no scanner reads.
They run as local processes. No container image in a registry, no port on a load balancer, nothing for network discovery to find.
Every agent client keeps its own config. Claude Desktop, Cursor, VS Code extensions, CLI agents, and internal tooling each store their MCP configuration separately, in different formats, in different locations.
The result is an integration layer with production-level access and consumer-level governance. Each server holds credentials for whatever it fronts — a database, a ticketing system, a cloud account, an internal API — and the aggregate is invisible.
The incident record is not theoretical
A timeline of MCP security incidents already includes:
- CVE-2025-49596 — remote code execution in Anthropic's MCP Inspector, CVSS 9.4.
- GitHub MCP server data exfiltration, May 2025 — an agent induced into leaking private repository content.
- "NeighborJack", April 2025 — hundreds of public MCP servers bound to all interfaces rather than localhost, reachable by anyone on the same network.
- The Nx compromise, August 2025 — malware that used locally installed AI CLIs to harvest roughly 2,180 GitHub tokens and 20,000 files.
That last one is the important one for this argument. The attack did not exploit an MCP vulnerability. It used the agent tooling that was already installed and already authorised as the mechanism. The configured integration surface was the attack surface.
Tool poisoning, briefly
Tool poisoning is the most prevalent and impactful client-side MCP weakness: malicious instructions embedded in tool metadata — the name, description, or parameter documentation the model reads when deciding what to call.
The model has no reliable way to distinguish a tool description written by your platform team from one written by an attacker. Both are text in the context window, and the model was built to follow instructions in text. We have covered the mechanics of these attacks and the broader threat model previously.
The mitigations are real but conditional. Static metadata analysis requires knowing which servers to analyse. Behavioural anomaly detection requires a baseline per server. Transparency mechanisms require knowing what to show. Inventory is upstream of all of it.
Building an inventory that stays current
Collect agent client configurations from managed endpoints. MCP configs live in known file locations per client. If you manage developer machines at all, you can collect them. This is the highest-yield first step and most organisations have never taken it.
Instrument at the agent runtime, not the config file. Configs go stale and miss the servers started ad hoc. What a client actually connected to during a session is ground truth.
Record what each server fronts. A server name is not useful. What matters is which system it reaches and with what credential — that mapping is your blast radius model.
Distinguish first-party from third-party. An MCP server your platform team wrote and deploys has a different risk profile from one installed from a public repository. Both belong in the inventory; they warrant different scrutiny.
Track versions and diff tool metadata between them. Tool descriptions are the poisoning vector, so a description that changes between versions is precisely the event worth alerting on. Without version-over-version comparison, a poisoned update is indistinguishable from a legitimate one.
Give people a sanctioned path. If registering a server is slower than not registering one, your inventory will be wrong by construction. A short approval path with a curated internal catalogue beats a policy nobody follows.
The organisational reality
MCP adoption is bottom-up. Developers adopt it because it makes their agents dramatically more useful, and they are right. Any approach premised on stopping that will fail and will push usage further out of view.
The workable posture is the one that worked for cloud adoption: make the sanctioned path the easy path, maintain a curated catalogue of approved servers with vetted configurations, and monitor for what falls outside it. Prohibition produces invisibility, which is the thing you were trying to avoid.
How Safeguard helps
MCP servers as a first-class inventory type. Safeguard's Supply Chain Core inventories MCP servers alongside packages, containers, models, and IDE extensions in one continuous CycloneDX and SPDX SBOM — with the credential mapping that turns a server name into an exposure statement.
Per-tool gating with feature flags. Safeguard gates MCP tool exposure at the individual tool level, so a server's reach is an explicit, reviewable configuration rather than whatever its author shipped by default. That converts the post-injection blast radius into a bounded, documented set.
Metadata delta analysis across versions. Because tool descriptions are the poisoning vector, Safeguard compares tool metadata version-over-version and flags changes — the one signal that separates a poisoned update from a routine one, and one that no CVE feed will ever carry.
Lion for the credentials behind the servers. Lion enforces just-in-time secret brokering so MCP servers hold no resident long-lived tokens, capability scoping so a poisoned tool call cannot exceed its bounds, egress allowlists so exfiltration fails, and signed audit trails so every agent-initiated action is attributable.
Eagle for scoping when something goes wrong. When an agent has been manipulated, the question is what it actually reached. Eagle answers it from the recorded tool-call history rather than from assumption.
Ask your platform team for the list of MCP servers in use across engineering. The length of the pause before you get an answer is your inventory maturity score.
Sources: NSA — Model Context Protocol Security · Authzed — A Timeline of MCP Security Breaches · MDPI — MCP Threat Modeling and Tool Poisoning Analysis · arXiv — MCP-DPT Defense Placement Taxonomy · Practical DevSecOps
