AI Plugin and Connector Supply Chain Risks

Third-party compromise is already the leading way breaches happen. SecurityScorecard's Global Third-Party Breach Report puts the 2025 figure at roughly 35.5% of breaches tracing back to a third party, up 6.5% year over year. AI doesn't sit outside that number. Treating it as a separate category, its own shelf next to supply chain risk, is worth questioning: does the mechanism actually differ, or just the speed? The evidence points to the latter — same hole, dug faster, with fewer people watching the shovel.

Why faster? Natural language becomes an attack surface, since instructions and malicious payloads look identical to a model unless something explicitly separates them, and most systems never build that wall. Agents act on tool outputs without a person checking first, so a bad result doesn't wait for review; it fires on the spot. When an agent connects to an MCP server, it hands that server the same trust it gives its own context window: no skepticism, no second look.

IBM's 2025 report puts average breach detection time at 276 days. Stack agentic AI's opacity on top of that number and the question changes shape entirely: what happens to detection time when the thing doing the acting is a model, not a person reading a log at 2am? The breach baseline the industry already struggles to manage sets a low bar, and AI risk clears it without much effort.

What the Model Context Protocol is and why it became the central attack surface

MCP, short for Model Context Protocol, is Anthropic's open standard for connecting AI agents to outside tools and data. It's become the default wiring for agentic AI, the thing everyone reaches for when they want a model to actually do something instead of just talk about it.

Here's the design choice that matters most: when a model talks to an MCP server, it treats whatever comes back as trusted context, and nothing sits between the model's reasoning and the server's output to check it. A developer can stand up a working MCP server in an afternoon. That's great for shipping fast and bad for security review, since the two move at completely different speeds, and most teams pick speed without naming the trade they just made.

The scale here isn't small. OX Security disclosed a systemic flaw in April 2026 affecting an estimated 200,000 vulnerable instances, across a supply chain touching more than 150 million package downloads. This was a design default baked into every official MCP SDK, and it spread into every downstream project that trusted the reference implementation without question. Anthropic confirmed the behavior was intentional and declined to change the protocol. The fix sits with individual developers downstream, and nobody at the center owns the repair.

Layer a governance gap on top of that. There's no package security standard for MCP servers: no signing requirement, no vetting baseline before publication. Registries run mostly uncurated; unlike npm, nothing scans in the background for known malware signatures. An enterprise pulling in a "community" MCP server may have no idea it just imported unaudited code with a direct line into internal systems. A look at more than 1,800 deployed MCP servers found over 30% carried at least one exploitable flaw, and most enterprise software categories don't run that hot at similar deployment scale.

The specific weaknesses inside MCP implementations that attackers exploit

Endor Labs looked at 2,614 MCP implementations and found the same dangerous patterns showing up again and again: 82% used file operations prone to path traversal, 67% used APIs tied to code injection, 34% used APIs open to command injection.

These are the same weakness classes that have haunted web applications for decades, now handed to an autonomous agent instead of a person clicking through a form. Trend Micro found 492 MCP servers exposed directly to the internet with zero authentication required. Anyone who found the address could reach the server, and every tool sitting on it.

The CVE count says something about how young this ecosystem still is. Thirty CVEs got filed against MCP servers, clients, and tooling in January and February 2026 alone. The Vulnerable MCP Project, maintained by researchers from SentinelOne, Snyk, Trail of Bits, and CyberArk, now tracks more than 50 known MCP vulnerabilities, 13 of them rated critical, and new disclosures kept landing through the first half of 2026 at a steady clip.

What actually separates this from an ordinary software bug is speed paired with autonomy. A path traversal flaw that a human developer might catch mid-review becomes, inside an agent pipeline, an automated data leak before anyone's opened a log.

Tool poisoning: how malicious instructions enter through the tool catalog itself

Tool poisoning is a specific flavor of indirect prompt injection, and it's sneaky because of where it hides: inside the MCP tool description the model loads as trusted configuration, often before a user has typed a single word.

Model-layer prompt filters miss this entirely, because the malicious instructions don't arrive looking like user input or retrieved content. They arrive as tool metadata, folded into the agent's reasoning context as though they belong there. OWASP classifies this attack as MCP03:2025, with a DREAD risk score of 46.5 out of 50, landing it in critical territory.

A proof of concept from April 2025 showed a single poisoned tool description could pull private repository contents and message histories out of a system with zero user interaction required. Research testing this across 20 different LLM agents found attack success rates reaching 72.8%, which is most of the time, not a rare edge case.

Every part of a tool's schema is fair game: the tool name, the description field, parameter descriptions, even enum values. There's currently no built-in MCP mechanism to catch or block any of it. Fixing this has to happen through outside monitoring, because the protocol itself offers no defense on its own.

The rug pull pattern and why post-deployment trust cannot be assumed static

Picture a server that publishes a genuinely useful, working tool. It builds a following, gets adopted across companies, earns trust. Then, quietly, the tool description changes to fold in malicious instructions, and that's the rug pull, working precisely because approval workflows aren't built to catch it.

Tool descriptions are plain text, read by the model as part of its normal reasoning loop, and changing that text doesn't trigger a new approval request on its own. From the user's side, the tool looks exactly as functional and harmless as it did on day one.

The postmark-mcp incident is the clearest confirmed example so far, the first known malicious MCP server caught in the wild. An unofficial Postmark MCP server, pulling around 1,500 weekly downloads, got quietly modified in September 2025. The change added a single BCC field to the send_email function, silently copying every outbound email to an address the attacker controlled. Anyone with auto-update turned on started leaking email content, and the agent's behavior never visibly changed, because staying invisible was the whole point.

Here's the part worth sitting with: trust built at deployment doesn't hold steady. It decays continuously as the pieces upstream change behind the scenes, and a plugin that passed muster during onboarding can turn malicious six months later through an update nobody flagged. Code can at least be diffed and reviewed line by line, but a plain-language change to a tool description slips past standard diff-based monitoring without leaving a mark.

How dependency confusion and indirect package compromise reach agent frameworks

Plenty of agent frameworks fetch MCP servers and plugins through ordinary package managers like npm and pip, and every existing supply chain trick against those ecosystems now works against agent frameworks too, no modification required.

Dependency confusion is a good example. One researcher demonstrated the attack by publishing a package under the same name as an internal package used by a popular agent framework, but on the public npm registry instead. Developer machines that fetched the "internal" package actually pulled the attacker's public version, backdoor included. Separately, reported flaws in MCP server packages have shown that compromise can happen at install time, before the server even started running.

The September 2025 npm cascade showed how far indirect dependencies carry this kind of damage. Attackers got hold of maintainer credentials for 18 widely used packages, packages that sit as indirect dependencies inside widely used MCP tooling. The malicious versions, capable of running arbitrary code, reached an estimated 2.6 billion weekly downloads across the affected packages combined. Any MCP server built from that SDK during the exposure window was potentially compromised, even if the developer's own code was completely clean; the foundation underneath it wasn't.

An enterprise that audits a vendor's MCP server but skips the dependency tree underneath it has checked the visible tip of something much bigger, and left the base unexamined.

The LiteLLM compromise as a case study in how the integration layer becomes the breach point

LiteLLM is a widely used open-source LLM proxy framework that sits quietly inside enterprise AI infrastructure, routing requests across multiple model providers through a single unified layer.

That position is exactly what made its March 2026 compromise so significant. A proxy sitting between enterprise applications and every model provider functions as all of them at once, funneled through a single choke point, and a breach there doesn't stay contained to one connection.

The attack ran through the integration layer, not the model itself. That fits the broader pattern: plugins and connectors are the structural entry point, not some side door people overlook. Worth asking directly: why do high GitHub star counts and heavy download numbers keep functioning as shorthand for trust, when neither actually measures security review? Open-source LLM infrastructure gets adopted faster than it gets audited, often by a wide margin. Compromise at the proxy layer hands attackers visibility into every model interaction routed through it, and the blast radius scales directly with how central that tool sits in the stack. Monitoring the connector layer can't be outsourced to the tool's maintainer, and it can't be inferred from a star count either. Reputation is not a security control.

Why traditional security tooling cannot see this attack surface

Standard application security assumes a clean line between trusted application code and untrusted input. That line doesn't hold up in agentic AI, at least not in the shape it used to take.

Signature-based and rule-based detection can't flag a tool description carrying malicious plain-language instructions, because the payload reads as ordinary, meaningful text rather than a known exploit pattern. Static SBOM-style inventories capture dependencies at one moment in time; rug pull attacks live in the gap between that snapshot and whatever the tool description or server behavior looks like right now, today, after the last silent update. Standard governance frameworks and compliance checklists got built around deterministic software behavior, and they have no category for plain language as attack surface or autonomous execution without human review, because nobody was writing those checklists with agents in mind.

Session hijacking attacks against MCP target already-authenticated sessions. That's a vector invisible to perimeter controls built on the assumption that authentication equals authorization for the life of the session. Combine that with the 276-day average detection lag IBM reported for 2025, and a compromise buried in a trusted tool description or an auto-updated dependency can survive several audit cycles without anyone catching it.

This runs deeper than a configuration problem. It's a mismatch in category, and it calls for visibility built specifically around AI assets, tailored to the threats this ecosystem actually presents rather than the ones legacy tools were built to catch. PromptArmor, for instance, is built around continuous monitoring of vendor AI deployments and the third-party risk they carry.

What continuous monitoring of vendor AI assets requires in practice

Start with inventory. An enterprise can't monitor what it hasn't counted, and that means mapping every plugin, connector, MCP server, and model across the vendor ecosystem, not just the headline models getting all the attention in the boardroom.

A one-time assessment misses the point entirely, and this is the mistake worth naming directly: treating certification as a finish line instead of a starting point. The rug pull pattern and the dependency cascade cases make the same argument from different angles. The threat state of a given component keeps shifting after deployment, and a server can pass every check on Monday and start leaking data by BCC come September. Monitoring has to track that ongoing drift. Checking a box once and calling the job done is exactly the failure mode every case above traces back to.