Downloading AI Skills and Plugins Comes With Security Risks Nobody Is Auditing

The protocol that prioritised speed over security

Anthropic launched the Model Context Protocol in November 2024 to solve a real problem: AI agents needed a standardised way to connect to external tools, databases, and APIs. The adoption was immediate. Google and Microsoft both integrated MCP quickly. Within ten months, over 16,000 MCP servers had been deployed across Fortune 500 companies, according to VentureBeat's October 2025 coverage of Pynt's security research.

The protocol was designed for frictionless connectivity. Authentication was optional. Authorization frameworks arrived six months after widespread deployment had already occurred. The same openness that made MCP the fastest-adopted AI integration standard in 2025 created what VentureBeat describes as enterprise cybersecurity's most dangerous blind spot.

What the security research actually found

Pynt's analysis of 281 MCP servers quantifies the risk in specific terms. 72% of MCP servers expose sensitive capabilities including dynamic code execution, file system access, and privileged API calls. 13% accept untrusted inputs like web scraping results, Slack messages, email content, or RSS feeds. When these two risk factors intersect, which happens in 9% of real-world MCP configurations, attackers gain direct pathways to prompt injection, command execution, and data exfiltration, often without any human approval required.

The compounding effect is the most alarming finding. A single MCP plugin carries a 9% exploit probability. At three plugins the risk exceeds 50%. At ten plugins it reaches 92%. These are not theoretical calculations. They are derived from the actual vulnerability distribution across 281 production MCP servers.

Merritt Baer, Chief Security Officer at Enkrypt AI, told VentureBeat directly: "MCP is shipping with the same mistake we've seen in every major protocol rollout: insecure defaults. If we don't build authentication and least privilege in from day one, we'll be cleaning up breaches for the next decade."

The supply chain attack that already happened

In September 2025, the Postmark MCP server package on npm received an update. Version 1.0.16 added a single line of code that silently BCC'd every outbound email to an attacker-controlled address. Every email sent through the plugin, internal memos, invoices, password resets, was copied to the attacker without raising any alerts, according to VentureBeat's coverage of Koi Security's discovery.

Idan Dardikman, co-founder of Koi Security, wrote: "Let me be really clear about something: MCP servers aren't like regular npm packages. These are tools specifically designed for AI assistants to use autonomously." The Postmark backdoor demonstrates that a single compromised plugin grants an attacker access not just to data but to the AI agent's full operational capabilities.

This was not the only documented attack. CVE-2025-6514, a critical vulnerability with a CVSS score of 9.6, was found in the MCP-remote package, which had been downloaded over 500,000 times. The vulnerability allowed arbitrary operating system command execution when the package connected to an untrusted MCP server.

The Skills blind spot

Noma Security's research, published by Help Net Security in May 2026, identifies a second attack surface that existing governance tools miss entirely: Skills.

MCP servers expose deterministic code functions that security teams can observe, log, and audit. Skills are different. They load textual instruction sets directly into the AI model's reasoning context, where their effect depends on conversational state and cannot be traced the way source code can. A security team can see when a Skill loads into an agent's context, but what happens afterward plays out inside the model's reasoning layer where observability tools cannot follow.

The downstream consequences, a deleted file, a sent email, exfiltrated credentials, are visible after the fact. But tracing them back to a specific Skill instruction is, as Noma's researchers describe it, guesswork. The majority of widely used Skills carry at least one risky characteristic, and the single most prevalent risk across both MCP servers and Skills is the ability to change state or data irreversibly.

Noma documented five real-world attack patterns already observed in production:

• ContextCrush: A developer asks an AI coding assistant for help. The agent pulls documentation from a poisoned library. Hidden instructions tell it to read local files and dump the contents to an attacker-controlled location. The developer sees ordinary coding assistance.
• ForcedLeak: Malicious instructions arrived inside a Salesforce CRM record submitted through a public form. The AI agent processed the record, treated the poisoned content as authoritative, and exfiltrated sensitive data.
• DockerDash: An attacker published a poisoned Docker image with a prompt injection in its metadata. When Docker's AI assistant inspected the image, the injection took over and ran attacker-chosen commands.
• Replit deletion: A coding agent deleted a production database holding more than 1,200 executive records during a code freeze, no attacker involved, just an agent with too much autonomy and insufficient guardrails.
• Amazon Q wipe: The Amazon Q VS Code extension was hijacked through a malicious GitHub pull request that ordered it to wipe the local filesystem and AWS resources.

Why this affects individual developers, not just enterprises

The VentureBeat and Help Net Security coverage focuses primarily on enterprise deployments. But the same vulnerability profile affects individual developers using Claude Code, Cursor, Windsurf, or any tool that supports MCP servers and Skills.

A solo developer installing a community-built Skill from GitHub has no audit process. No security review. No way to verify that the instructions loaded into their AI agent's context are benign. The agent runs with the same permissions the developer has, full file system access, API keys in environment variables, database connections, SSH credentials. A compromised Skill inherits all of it.

Noma's proposed framework, No Excessive CAP, identifies three dimensions that determine how much damage a compromised plugin can do: Capabilities (what the agent can do), Autonomy (how much it decides without human approval), and Permissions (whose identity it runs under). The dangerous configuration is all three turned up simultaneously: an agent that can do anything, decides on its own, and runs with broad credentials. This describes the default configuration of most individual developer setups.

Proof signals

VentureBeat coverage of Pynt's 281-server analysis October 2025. The 92% exploit probability at ten plugins is derived from empirical vulnerability analysis across production MCP servers, not a theoretical model. The compounding risk curve from 9% at one plugin to 92% at ten is the clearest quantification available of how the plugin ecosystem compounds risk. The Postmark supply chain attack, CVE-2025-6514 with its CVSS 9.6 score, and the Trail of Bits "line jumping" attack are all documented in the same piece with specific technical detail.

Help Net Security coverage of Noma Security's whitepaper May 2026. The distinction between MCP servers (observable) and Skills (invisible to governance tools) is the most important architectural insight for understanding why existing security approaches are insufficient. The five documented real-world attack patterns, ContextCrush, ForcedLeak, DockerDash, Replit deletion, Amazon Q wipe, are not hypothetical. They are documented incidents that have already occurred in production environments.

Enkrypt AI CSO direct quote published by VentureBeat. The Chief Security Officer of a security company specialising in AI stating that MCP is "shipping with the same mistake we've seen in every major protocol rollout" is the most credible available characterisation of the severity of the design gap from someone whose professional responsibility is assessing exactly this kind of risk.

What to actually do about it

Existing attempts fall short in specific ways:

• Authorization frameworks added after the fact: MCP's own authorization spec arrived roughly six months after widespread deployment had already occurred. Retrofitting security onto tens of thousands of already-deployed servers means most existing deployments were built and adopted before the framework meant to secure them existed, and updating them requires every operator to act individually.
• Manual security review of plugins before installation: Reviewing a Skill's instructions or an MCP server's source code before installing it is possible in principle, but it does not scale to the pace at which individual developers and small teams adopt new tools, and it requires security expertise most individual developers do not have.
• Governance tools built for MCP servers: Existing observability and governance tooling can log and audit MCP server calls because they are deterministic code. Skills are not covered by the same tooling because their effect plays out inside the model's own reasoning context, which is exactly the blind spot Noma's research identifies as unaddressed by current products.
• Least-privilege permission scoping: Restricting what an agent's credentials can access limits blast radius when a plugin is compromised, but Noma's own framework notes that most individual developer setups run with high Capabilities, high Autonomy, and broad Permissions simultaneously by default, and changing that default requires deliberate configuration most users never do.
• Relying on npm and marketplace review processes: The Postmark backdoor shipped through a routine version update on npm and was not caught by the platform's existing review process. Package registries were not built to evaluate whether an update grants an AI agent new autonomous capabilities.

Before going further, it is worth pressure-testing the idea against these questions:

1. If exploit probability compounds from 9% at one plugin to 92% at ten, is the realistic fix limiting how many plugins a given agent can run at once, or does the compounding effect mean the underlying per-plugin vulnerability rate has to come down instead?
2. Noma's research shows Skills are invisible to the tooling that already exists for MCP servers because their effect happens inside the model's reasoning layer. What would a tool actually need to observe or intercept to close that gap, and is that even possible without changing how the model itself processes instructions?
3. The Postmark and Amazon Q incidents both involved a legitimate, previously-trusted package or extension being compromised after the fact, not a malicious package installed knowingly. Does that change what a solo developer or small team can realistically do to protect themselves, versus what only a platform-level fix could address?
4. Given that most individual developer setups already run with high capabilities, high autonomy, and broad permissions by default, is the fix better default configurations from tool makers, or does it require developers to actively opt into more restrictive setups that reduce the convenience that made these tools popular in the first place?
5. If 16,000+ MCP servers were deployed across Fortune 500 companies within ten months of the protocol launching, and authorization frameworks arrived six months later, what does the realistic remediation timeline look like for the deployments that predate the framework, and who is actually responsible for going back and fixing them?