Anthropic's own documentation for Claude Code states it plainly: installed plugins and MCP servers run with the user's full permissions, with no per-plugin sandboxing and no runtime isolation between plugins. That is not a hidden flaw — it is the documented threat model of agent extension ecosystems as they exist in mid-2026. A plugin that reads your calendar and one that reads your production database credentials get the same trust boundary: none, beyond the human clicking "install." Anthropic's own official plugin directory now runs external submissions through at least an automated security review, with a further "Verified" tier for plugins that get additional manual scrutiny — but its documentation is still explicit that even reviewed plugins aren't guaranteed to work as intended or be free of vulnerabilities, and the community marketplaces most third-party skills are actually distributed through carry no review at all. This mirrors a threat class the software industry has already lived through once with IDE extension marketplaces — in 2025, ReversingLabs tracked a campaign of 19 malicious VS Code extensions hiding payloads in dependency folders, a fake "Prettier" extension was published and pulled within roughly four hours on November 21, 2025, and a worm dubbed "Shai-Hulud 2.0" used stolen npm and OpenVSX publishing tokens to compromise hundreds of packages. Agent skills inherit the same shape of risk with a sharper edge: they don't just run in your editor, they act with your agent's tool access. This post lays out what to actually check — signing, sandboxing, and permission scope — before you let a third-party skill onto your machine.
Why can't you just trust a marketplace listing?
Because marketplace review, where it exists, checks for baseline hygiene, not for malicious behavior baked into the code. Even Anthropic's own official plugin directory — which puts external submissions through at least an automated security check, with a "Verified" badge reserved for plugins that get further manual review — is explicit that this doesn't guarantee a plugin works as intended or is free of vulnerabilities. Plugins installed from the far more common community marketplaces skip even that baseline: there's no review step before a listing goes live. That distinction matters because it is precisely the gap attackers have exploited in adjacent ecosystems. The fake Prettier extension on VS Code's marketplace was live and installable for roughly four hours before removal — long enough for a handful of installs, though caught before it spread widely. If you're evaluating an agent skill, treat "it's listed in a marketplace" as evidence of formatting compliance at best, not as a safety certification, and go read the actual source before granting it tool access.
What does agent sandboxing actually protect against?
Agent sandboxing constrains what the agent itself can do at runtime — it does not vet the trustworthiness of code you've chosen to install. Anthropic's 2025 Claude Code sandboxing feature adds filesystem isolation (restricting the agent to specific directories) and network isolation (allowlisting destinations), and Anthropic reported this cut permission prompts by roughly 84% in internal usage by letting the agent operate confidently inside a defined boundary. That's a real improvement for reducing prompt fatigue and containing an agent's own mistakes or a successful prompt injection. But sandboxing governs the agent's actions after a skill is loaded and trusted — it doesn't stop a malicious skill from exfiltrating data over an allowlisted domain you approved for a legitimate purpose, or from reading every file inside the sandbox boundary you granted it. Sandboxing and skill vetting are complementary controls, not substitutes for each other.
How have adjacent marketplaces already been weaponized?
Extension and package marketplaces have been weaponized repeatedly enough in 2025 that the pattern is now well-documented rather than speculative. Beyond the 19-extension dependency-hiding campaign ReversingLabs tracked (active since at least February 2025) and the Shai-Hulud 2.0 worm's abuse of stolen publishing tokens — including one belonging to the AsyncAPI project — security researchers reported detections of malicious VS Code extensions roughly quadrupled over the course of 2025. The common thread across every incident: unsigned or weakly verified publishing identities, auto-update mechanisms that push new code without re-review, and marketplace infrastructure trusted by default because it's the "official" install path. Agent skill and MCP server marketplaces share every one of those properties today, plus one the extension world didn't have: the installed code can direct an autonomous agent's actions, not just execute inline in an editor process.
Has this attack already been demonstrated against agent skills specifically?
Yes — security researchers at PromptArmor have documented marketplace-injection attacks specifically targeting Claude Code plugins, where malicious content embedded in plugin metadata or marketplace listings is used to hijack agent behavior through prompt injection. This moves the risk from theoretical to demonstrated: an attacker doesn't need to smuggle a traditional malware payload past review if they can instead craft a listing description or configuration field that the agent itself reads and acts on as an instruction. That's a distinct attack surface from classic supply-chain poisoning, and it means vetting a skill means reading its metadata and prompts, not just its executable code.
What should you actually check before installing a skill?
Before installing any third-party skill, verify the publisher's identity and signing where the ecosystem supports it, read the permission or tool-access scope it requests, and check whether it can auto-update without re-review. Prefer skills that declare a minimal, explicit tool allowlist over ones requesting broad filesystem or network access "to be safe" — the same principle behind scoping an MCP tool-whitelist to only what a given task needs, rather than granting blanket access up front. Check publish history: a skill with a single recent version and no track record deserves more scrutiny than one with a multi-year commit history and multiple maintainers. Combine that manual review with runtime controls — sandboxing your agent to specific directories and an allowlisted network path — so that even a skill that passes vetting is still contained if it's later compromised via a token theft like the one behind Shai-Hulud 2.0. No single control here is sufficient alone; the VS Code precedent shows that review, signing, and sandboxing all get bypassed individually, but rarely all at once.
How Safeguard helps
Safeguard's software composition analysis and SBOM tooling extend the same supply-chain discipline teams already apply to Python and npm dependencies to the agent-extension layer: tracking exactly which third-party packages and plugins are present across a build, flagging known-malicious or typosquatted package names, and giving security teams a queryable inventory to check the next time a marketplace incident like a compromised publishing token is disclosed. As agent skill and MCP marketplaces mature, applying that same "trust but verify with an inventory" discipline — rather than treating an install click as sufficient vetting — is the practical defense available today.