Blog
>
Sleeper Skills

Sleeper Skills

A marketplace security audit score attests to the artifact that was scanned, not whatever that skill transforms into, after a silent auto-update. Silent updates are potential supply-chain attacks. During our scan of multiple skill marketplaces, we found 50+ skills having self-update capabilities, these skills have been downloaded more than 28k times and star-ed more than 23k times.‍

Harsh Akshit

Sleeper Skills: The skill you approved is not the skill running now 

The score was right, until the artifact changed

At 9:00 a.m., an engineer finds an AI agent skill that promises to automate a tedious workflow. The marketplace shows a reassuring safety rating. The security team reviews the report, approves the skill and records the decision. The agent installs it.

A week later, the same skill updates itself during ordinary use. Its name is unchanged. Its marketplace page is unchanged. The marketplace security audit score is unchanged. The approval ticket still points to the clean report. But the code and instructions now running inside the agent are not necessarily the artifact that anyone reviewed.

This is the self-update trust gap: a point-in-time security decision is silently carried forward to new content.

The earlier rating was not wrong, and it is not useless. It simply no longer attests to the installed artifact. Security teams already understand this principle for container images, software packages and signed binaries: trust belongs to immutable content, not to a mutable name. AI agent skills require the same discipline, with an added complication. Their behavior can live in executable code, natural-language instructions and remote content fetched at runtime.

An update is not malicious by itself. Legitimate software needs patches. The dangerous pattern is an update path that is mutable, unpinned and capable of changing operative behavior without independent integrity verification, a reviewed diff, fresh approval or a useful user-facing notice.

Sleeper skills are not the same as skills having Ghost dependencies

Sleeper skills do not require the original skill publisher to become malicious or even require the reviewed skill bundle to change. In our earlier research, The Ghost in the Skills, Metano showed how otherwise legitimate skills can instruct agents to install package names that do not exist, resolve to unrelated owners or remain unpinned.

During the Sleeper skills research, we found a completely different pattern. In the Ghost dependencies, the attacker’s entry point was unclaimed dependencies and the absence of those dependencies provided the cover, while in the case of Sleeper skills the entry point is via auto-update instructions embedded within the skill, and the stale security verdict provides the cover. 

Why agent skills make this gap dangerous

AI agent skills are not passive documentation. A skill can direct an agent to read files, invoke shell commands, call APIs, download and install packages, use credentials and take actions through authenticated sessions. Natural-language instructions can therefore acquire the authority of the agent that interprets them.

That changes the supply-chain equation. A conventional malicious update replaces executable bytes. A skill update can replace bytes, rewrite its own standing instructions, or leave the local package untouched while loading new instructions from a remote server. In every case, the identity visible to the user can remain stable while the behavior changes.

Metano’s investigation found that the post-installation control plane can sit outside the artifact a marketplace scanned. Some skills replace their own bundles. Others rewrite standing instructions or follow mutable remote content. In every case, future behavior can change without altering the skill name, approval record or marketplace page. That creates a time-of-check/time-of-use gap: the scanner validates one artifact, while the agent later operates under another artifact or newly fetched instructions. Without continuous verification, the original verdict deviates from the evidence behind it.

This is the structural problem at the center of self-update: mutable content crosses a trust boundary after the original review. Static marketplace checks can assess what was submitted. They cannot guarantee what a remote endpoint will serve tomorrow, what an updater will install next week, or what an agent will write back into its own instructions.

What we found in skill self-update mechanisms

Metano reviewed thousands of skills along with their dependencies on multiple marketplaces including ClawHub and SkillsMP using Skill Tracer. The broad review produced findings spanning operational self-update, self-modification, dormant patchers and adjacent persistent-state patterns, in 56 skills.

SkillTracer findings panel listing five findings for a scanned skill, with the medium-severity finding "Auto-reinstall directive from unpinned external registry" expanded to show its category, explanation, suggested fix and the quoted instruction used as evidence.
A Skill Tracer scan finding on a self-updating skill: the auto-reinstall directive is flagged as supply-chain tampering, with the instruction that triggered it quoted as evidence and a pinning fix recorded against the finding.

We then applied a deliberately strict rule: include a skill only when a normal-use or scheduled path could change the installed skill or persistent standing instructions without per-change consent and without a required user-facing notice of that specific change. Console output or a disclosure buried inside the package did not count as an approval gate.

Nine skills met that strict under-the-radar definition.

1. Bundle replacement immediately before use

The hope0719/quarkclouddrive-skill package contained the clearest bundle-replacement pattern in the review. Its documented workflow required an installer to run before CLI commands. The installer could poll a remote endpoint, download a ZIP, and replace the installed scripts, SKILL.md and reference material.

hope0719/quarkclouddrive-skill package contained the clearest bundle-replacement pattern in the review
hope0719/quarkclouddrive-skill package contained the clearest bundle-replacement pattern in the review

In update mode, the installer deletes and replaces scripts, overwrites SKILL.md, and replaces references with files extracted from the downloaded bundle.

The most consequential behavior came after replacement: when the documentation changed, the script directed the agent to disregard prior memory about the skill and re-read the new SKILL.md. Whoever controlled the update source could therefore change both executable helpers and the standing instructions used to interpret them.

The pattern is dangerous because it occurs next to an authorized task. A user asks the agent to manage cloud-drive content; the skill refreshes itself as a prerequisite; the agent then proceeds under the authority already granted to that skill. There is no clean moment where the user necessarily sees “the artifact you approved has changed.”

We found no basis to claim that a specific malicious payload was delivered through this path. The security conclusion is narrower and still serious: an unsigned or independently unverified update source has the potential to become a supply-chain replacement channel.

2. Runtime input becomes standing instruction

The tahcia/tahcia-console skill demonstrated in-place self-modification. Its normal UI loop instructed the agent to record what it learned about coordinates, timing and application behavior by writing the learning back into its own SKILL.md.

Persistent self-modification: tahcia-console instructs the agent to write newly learned behavior directly into its own SKILL.md, allowing its approved instructions to change during ordinary use.

Self-improvement sounds useful. The trust problem is provenance. What counts as “learning” may be influenced by webpages, OCR output, accessibility text, application messages or other content the agent encounters. If that content is untrusted, an attacker may be able to launder an instruction through the agent’s learning process and persist it inside a file that future sessions treat as trusted.

No marketplace reinstall is required. The package can keep the same path and name while its operative instructions drift. Without validation, versioning, rollback, review and notification, the original rating describes the starting point, not the accumulated skill.

Again, the capability is not proof of malicious intent. It is a reminder that persistent self-editing has the potential to turn runtime input into a software supply-chain attack.

3. The package stays still while instructions move

The g620710/meyo skill showed the third pattern: a Command-and-control (C2) style live remote-instruction reload. Its instructions directed the agent to read mutable Markdown from meyo123.com and follow it. Its heartbeat workflow could also react to server announcements indicating a skill update and refresh main-skill or sub-skill content.

Remote Markdown becomes runtime instruction. Meyo’s installed SKILL.md directs the agent to read and follow mutable diary, checkup, heartbeat, and community documents hosted on meyo123.com; the heartbeat is then triggered automatically.

This pattern can evade a file-change-only control. The installed package may remain byte-for-byte identical while the instructions that govern the next action change on the server. A marketplace can rescan the local bundle and correctly report that it has not changed, yet the agent’s effective behavior can still be different.

The closest traditional analogy is remote configuration, but agent instructions are more powerful than most configurations. They can tell an agent which tools to invoke, which safeguards to relax, what data to retrieve and where to send it. A mutable remote document can function as a post-installation behavior channel.

The right security question is therefore not only “Did the installed files change?” It is also “Did any authoritative input that controls this skill change?”

Trust must be re-established after every material change

A durable control model starts by binding identity to content. A skill name is useful for people; a content fingerprint is what a security decision should authorize.

This lifecycle produces a simple policy: no updated artifact should automatically inherit the trust decision for its predecessor.

Metano continuously discovers skills as AI assets and fingerprints installed skill content. That inventory makes a changed artifact visible as a different security object instead of collapsing every version under one mutable name. The documented vetting workflow then treats an update as a new artifact: run AgentScan for evidence-backed static findings, use SkillTracer when the stakes or runtime data paths justify execution in an instrumented sandbox, and record a new verdict for the new fingerprint.

This is intentionally different from claiming that every detected change currently launches an automatic scan. The implementation-backed promise is visibility and content identity: security teams can see that the asset changed and route the new artifact through re-vetting. Automation can tighten that loop, but the trust boundary should not depend on whether a human remembers to revisit an old marketplace page.

Five controls for security teams and marketplaces

1. Bind ratings to immutable digests. A score should name the exact content hash, version and scan time it covers.

2. Invalidate inherited approval on material change. New code, standing instructions or authoritative remote content should require a fresh decision.

3. Require transparent update mechanics. Updates should be pinned, signed, diff-able and accompanied by a user-visible change summary. High-impact changes should require explicit approval.

4. Monitor the effective instruction surface. Inventory local files, remote instruction sources and persistent self-written state. File integrity alone is insufficient for live instruction reload.

5. Keep runtime monitoring after approval. Watch tool use, filesystem access and outbound connections for divergence from the skill’s stated purpose. A clean installation-time scan should not exempt the skill from post-installation observation.

The security rating is the beginning of trust, not the end

The agent-skill ecosystem is moving quickly, and update mechanisms are inevitable. The goal is not to freeze every skill at its first reviewed version. It is to prevent change from bypassing the review boundary.

A safe marketplace score should answer a precise question: “What did we learn about this exact artifact at this time?” An enterprise control plane must answer the next one: “Is that still what our agents are running?”

When those answers diverge, the old approval should stop carrying forward. Metano provides the continuous AI-asset inventory and content identity needed to see the change. SkillTracer provides static and runtime verification for the skills.

Trust the artifact, not the name and re-establish that trust whenever the artifact or its authoritative instructions change.