Your agent's skill marketplace is a malware supply chain

Nine hundred malicious skills. Roughly one in five packages on the marketplace agents pull from. One typosquat, disguised as a popular dependency, cleared 8,000 downloads before anyone caught it. It shipped as a password-protected zip; unzip it and a base64 blob decoded into a bash script that ran with whatever privileges the agent had.

That is the current state of the agent skill marketplace, per a recap in O’Reilly Radar that cites a Bitdefender advisory. The pattern, not any single named product, is the point: a distribution channel built for convenience became a distribution channel for malware, and most teams running agents in production have not adjusted their controls to match.

Skills are dependencies with an extra trust problem

A skill package looks like a small, useful thing: a bundle of instructions and code an agent can install to do one task well. Teams add them the way developers add npm packages, by searching a name, skimming a description, and installing. Few read the code inside. Fewer still verify what it does at runtime.

That habit was already risky for conventional package registries. It is worse for agent skills, because a skill does not just sit on disk waiting to be imported. It gets read into a model’s context and, often, executed with the agent’s own credentials: filesystem access, API keys, database connections. A malicious skill does not need a supply-chain-grade exploit. It needs a plausible name, a working demo, and a payload that only fires once trust is established.

The 8,000-download typosquat followed exactly that script. A fake dependency name close enough to a real one to survive a quick glance. A password-protected zip, which is itself a signal (legitimate skill packages have no reason to hide their contents from static scanners). Inside, a base64-encoded string that decoded to a bash command. Nothing about that chain required a novel technique. It required an agent, and a human, who trusted the marketplace listing more than they should have.

The exposure problem compounds it

The marketplace risk does not exist in isolation. The same recap notes thousands of agent instances discoverable on the public internet, exposed because of a gateway misconfigured to bind on the wrong interface. An agent that should only be reachable from an internal network was reachable from anywhere.

Put the two findings together and the picture sharpens. A malicious skill gives an attacker code execution inside an agent’s context. A misconfigured gateway gives that same attacker a public front door into agents that never should have been reachable at all. Neither problem is exotic. Both are the kind of operational detail that gets skipped when a team is racing to ship an agent feature.

Why transcripts cannot be your evidence of safety

The instinct, when asked “did the agent do anything it shouldn’t have,” is to pull the conversation transcript and read it. That instinct is wrong, and it is wrong in a specific way that matters for skill-marketplace risk.

A model can hallucinate compliance. It can summarize its own actions inaccurately, omit a step, or describe an outcome that does not match what actually executed. Transcripts capture what the model said it did, filtered through its own account of events. They are not a record of what the execution layer actually ran.

The fix is unglamorous: deny logs written at the execution layer, below the model, where a tool call either was permitted or was not, with no model narration in between. If a skill tries to open a network connection it was not granted, or read a credential outside its declared scope, the deny log records the attempt regardless of what the transcript says happened. This is the same principle that has always applied to firewalls and IAM policies. It has not yet been applied consistently to agent skill execution, and that is the deficit the marketplace numbers expose.

Allow-listing beats trust-by-default

The second control is more concrete: toolsDeny and skillsAllowed style allow-listing, where an agent can only invoke skills a human has explicitly vetted and approved, rather than any skill discoverable in the marketplace. This inverts the current default. Most agent setups today start permissive (any published skill is installable) and rely on the team noticing something wrong after the fact. Allow-listing starts restrictive and requires a deliberate act to add anything.

This is not a call to ban marketplaces. It is a call to treat skill installation the way a mature engineering org treats a new dependency: pinned versions, a review step, and a record of who approved what. The 20% malicious-package figure is not a reason to avoid marketplaces entirely; it is a reason to stop treating “it’s on the marketplace” as a substitute for review.

Deterministic first, agent second, human last

For any output that touches regulated data, money, or a customer-facing decision, the sequencing matters as much as the controls. Deterministic code should do the parts of the job that have one correct answer: validation, calculation, formatting, anything with a testable spec. The agent’s job is to handle the parts that need judgment or language, and its output should be verified, not trusted, before it moves downstream. A human approves the result before it ships.

This “deterministic-then-verify-then-approve” sequence is the direct answer to the marketplace risk. Even a compromised skill that makes it past allow-listing and executes something unintended cannot silently corrupt a regulated output, because nothing the agent produces reaches the customer or the ledger without a check that does not depend on the agent’s own account of itself.

Do this now

Audit every skill your agents currently have access to against a simple question: who reviewed this, and when. If the answer is nobody, remove it from the allow list until someone does. Turn on execution-layer deny logging before you need it, not after an incident forces the question. And confirm your agent gateways are bound to the interface you intend, not the one that happens to be open to the internet by default.

---

This analysis synthesizes Don’t Neglect the Operational Groundwork (O’Reilly Radar, July 2026).

Victorino Group helps teams vet the skills their agents run and enforce controls at the execution layer. Let’s talk.