Skip to main content
ARTICLE

The unvetted supply chain: agent skills repeat every plugin lesson

Two disclosures this month — a version pin that never verified what it installed, and injection flaws latent in more than one in six popular skills — say the same thing: the extension layer is where agent security gets decided, and nothing currently vets it.

OR
Orithos Research Team
Security Research · Orithos
FIG. 5 — UNVETTED SUPPLY

Two disclosures this month, one conclusion. The first: a bypass across all four major AI coding agents' plugin systems, where a plugin is fetched at a review-locked commit but the landed code is never verified against that lock — on permissive hosts, a branch named like the commit hash resolves instead. Attacker code installs; the agent reports a clean install at the reviewed version. As of the disclosure, two vendors patched, one left it open, one said it won't fix.

The second: research across agent skills found more than 17% of popular skills carried latent injection vulnerabilities — and triggered real incidents without modification. The flaws weren't payloads waiting to be delivered. They were behaviors already in the skills people install, activated by ordinary use.

Neither story is about a model being tricked. Both are about the extension layer: the skills, plugins, and servers that agents load and then trust with their tools.

Every ecosystem rehearses this, and still gets caught

npm had its install-script era. Browser extensions had permission escalation. VS Code extensions had marketplace malware — repeatedly. The pattern is always the same shape: the ecosystem grows faster than review, and "install" silently means "trust."

Agent skills inherit that pattern with higher stakes. A browser extension at least runs in a sandbox the browser maintains. A skill runs next to your agent's credentials, its tool reach, and — in the common case — a user who believes a name, a star count, or a marketplace listing is a security signal. This month's disclosures say the same thing about that belief that every previous cycle did: it isn't one.

And we'll hold our own side of the industry to it too: a pin without verification is theater, whether it's in an agent vendor's updater or anywhere else. Verification is a property of what runs, not of what was reviewed.

What we're shipping

Today we're releasing the first version of orithos skill scan — a static vetting pass for skills, plugins, and MCP packages that runs offline, on your machine (or your CI), before anything executes.

  • Seven check classes, one pass: manifest hygiene (wildcard grants, unpinned servers), declared-vs-implied scope (code that shells or calls out while the manifest says [Read]), outbound destinations (webhook catchers, paste sites, tunnels, raw IPs), shell and install hooks (curl | sh, postinstall, build hooks), credential access (SSH keys, .env, cloud stores, keychains, env dumps), encoded payloads (eval(atob(…), base64 blobs that decode to runnable code), and known-bad signatures (reverse shells, authorized_keys injection, cron persistence).
  • Every finding cites file, line, and evidence. No scores to argue with — an inspectable list, deterministic under the published rule set.
  • Text, JSON, SARIF. Exit codes for CI gates: 0 clean, 1 findings at/above your threshold, 2 error. --fail-on medium when you want to be strict.
  • Offline by default. Zero outbound calls; archive URLs are unpacked with traversal protection. Nothing about your stack leaves your machine.

The scanner ships with the Orithos CLI in the private beta — request access if you want it early.

What it catches, and what it doesn't

The honest split matters more than the launch. Static analysis catches the patterns that matter at review time — the wildcard grant nobody reads, the base64 loader nobody decodes, the postinstall nobody scopes. In the disclosure above, a pin-verification gap is a process failure; a scan of the landed code is exactly what surfaces what the process missed.

It does not catch semantic trickery inside otherwise-clean skill prose, and it cannot see behavior that only appears at runtime. That's the dynamic pass (v1.1), and it's also why the platform runs the same patterns as end-to-end probes against deployed agents rather than trusting a static verdict.

Why us

Our check set isn't assembled from vibes. The Orithos probe catalog runs against real agent deployments daily, and our Q3 benchmark publishes what that data actually shows — failures included. The dogfooding case study is the same discipline pointed inward.

The extension layer is where the next twelve months of agent security incidents will live. Vet before you run — that's the whole idea.

OR
Orithos Research Team
Research and engineering at Orithos. We publish adversarial findings from our probe catalog, platform telemetry, and continuous dogfooding of our own agents.
Run the scan

Point the probe catalog at your own agent.

124 probes across 25 categories, ≈41K executions per deep scan — ALLOW/DENY verdicts mapped to OWASP, NIST AI RMF, and EU AI Act controls.