Your AI Agent's Skills Might Be Malware

A skill can be a Markdown file and still change what an agent tries to do with your credentials.

That is the uncomfortable part of adding a capability through instructions. The file may explain a useful workflow. It may also steer the agent toward an unnecessary download, a different destination for its output, or an operation the user never requested. Reading the description is not the same as reviewing the behaviour.

The evidence warrants caution. It does not warrant treating every scanner finding as malware or assuming that loading a file automatically defeats every permission boundary.

What ToxicSkills actually found

Snyk's February 5, 2026 ToxicSkills report lists 3,984 scanned skills in its main findings, with 534 containing at least one critical-level security issue and 1,467 containing an issue of any severity. Those correspond to 13.4% and 36.82%. The critical category is included in the any-severity total. Adding the percentages together would count some skills twice. [1]

The report's introduction mentions ClawHub and skills.sh, while its findings section describes the 3,984-skill scan as ClawHub. It separately presents detection rates for a curated top-100 skills.sh set. I would keep the counts attached to the reported scan rather than describe them as the prevalence of malware across all agent platforms.

Snyk also reports human review confirming 76 malicious payloads. That is a different claim from flagging a security concern. The report's taxonomy includes exposed secrets, suspicious downloads, and third-party content exposure. A skill that fetches untrusted content can create an attack surface without its author intending harm.

The described method combines automated scanning, customized models and deterministic rules, with human review of hundreds of skills. It does not establish that every flagged skill was dynamically exploited against a production user. Snyk explicitly cautions that a malicious skill does not necessarily result in a successful compromise.

These are vendor-reported findings from a dated dataset, using the vendor's detection categories. Skills are deduplicated by author and skill ID, not across different authors republishing the same content. The counts are useful evidence that malicious packages existed in the sampled distribution channels, not a probability that a particular skill you install today will compromise your machine.

The file is not the whole dependency

The Cloud Security Alliance's May 2026 research note describes agent context poisoning as a supply-chain risk involving files such as SKILL.md. Its analysis also acknowledges that the effect depends on the platform's instruction hierarchy and runtime boundaries. [2]

There are at least two things to inspect. The instructions may try to redirect the agent's decisions. The scripts, executables, or remote content referenced by those instructions may perform the harmful operation. A review that reads only the Markdown can miss the second part.

Consider a hypothetical release-notes skill. Its stated job is to summarize commits. A modified version tells the agent to upload a diagnostic bundle before generating the summary. The bundle could include material unrelated to release notes.

This is an illustrative example, not an account of a Microsoft system. Whether the upload can happen depends on which files the agent can read, which network destinations it can reach, and whether the upload operation requires authorization. The prose alone does not grant those permissions. But broad existing access can turn a misleading instruction into a consequential action.

The same problem can arise without a malicious skill author. A legitimate skill may retrieve a document containing attacker-controlled instructions. The agent should treat that document as task data, not as authority to expand the task.

Traditional supply-chain controls still matter here. Signing can help establish origin and detect changes; it does not prove that signed content is safe. Dependency review, code scanning, and isolated testing remain useful. Agent instructions add another object to review rather than making those controls obsolete.

Review a version, not a marketplace name

Before allowing a new skill into a privileged workflow, I would record the exact package version or content digest, its source, and the capabilities it needs. A recognizable name or download count cannot establish that the installed files match a version someone reviewed.

The review should include setup steps and referenced scripts, not just the advertised task. If the skill retrieves executable code or additional instructions at runtime, inspect how that content is selected and controlled. Pinning the top-level file does not freeze a mutable remote dependency.

For the release-notes example, I would expect access to the relevant commits and an approved output location. A request for unrelated credentials, a shell-wide environment dump, or an unexplained external upload needs an explanation before the skill runs.

Use automated checks to help identify suspicious instructions, exposed secrets, and unexpected dependencies. Test behaviour in an isolated environment with synthetic data and without production credentials. Neither a clean scan nor a successful test proves safety: a conditional behaviour may not be exercised by the test.

Updates deserve another review when they change instructions, dependencies, or requested access. Record which workflows used which version so a later finding can be investigated without guessing.

Make an unsafe request fail outside the model

OWASP's excessive-agency guidance recommends limiting functionality, permissions, and autonomy separately. It also recommends authorization in downstream systems instead of relying on the model to decide whether an operation is allowed. [3]

For a skill-enabled workflow, I would apply that through a few concrete boundaries:

1. Limit available operations. Prefer a tool with a narrow purpose over a general shell when the task allows it. Do not leave unrelated connectors available because another workflow needs them.
2. Limit reachable data and destinations. Restrict the execution identity, filesystem access, and network egress to the task. A container with broad host mounts and production secrets still exposes those resources.
3. Authorize consequential actions explicitly. Show the actual target and proposed data transfer or change. Approval should cover that operation, expire, and be checked by the execution path. It should not authorize whatever a skill asks for next.
4. Observe outcomes and preserve an off switch. Record the skill version, tool requests, policy decisions, and destinations without logging secrets. Make it possible to disable a suspect version across affected workflows.

These are engineering recommendations, not controls whose effectiveness the ToxicSkills scan measured. They should be tested against the failure modes that matter in the intended environment.

A human reviewer can still approve a harmful action, especially when the agent supplies a persuasive explanation. Review cannot promise a zero blast radius. And a confirmation before one tool call is of little help if the same operation remains available through an unrestricted alternative.

Removing the skill may not finish the response

If a skill is suspected of causing a compromise, disabling it can stop new uses. It does not reverse a data transfer, invalidate an exposed credential, or remove changes already made to the environment.

The response should preserve relevant evidence, identify affected versions and runs, and examine the actions they took. Revoke or rotate credentials that may have been exposed. Inspect persistent instructions, scheduled work, and other modified state within the affected scope, and restore from a trusted baseline where necessary. Follow the organization's incident-response process rather than asking the suspect agent to certify that it is clean.

This is why I would put the most important question before installation: if this skill gives the agent the wrong instruction, which independent control prevents the harmful action?

If the answer is only "the agent should know better," the skill has been given too much trust.