SkillCloak Bypasses AI Agent Skill Scanners 90% of the Time

Can a static scanner actually stop a malicious AI agent skill before it runs? New research out of Hong Kong University of Science and Technology says no, and the gap is not small.

The team built an evasion tool called SkillCloak and threw it at eight scanners, using 1,613 real malicious skills pulled from ClawHub, a public skill marketplace. According to the researchers, the heaviest packing variant exceeded 90% evasion across every scanner tested, and surpassed 99% on most of them.

AI agent skills are small packages, typically a Markdown instruction file plus scripts, that extend the capabilities of agents like Claude Code, OpenAI Codex, and OpenClaw. The research frames SkillCloak's results as more than a lab curiosity: a reproducible, scalable attack pipeline rather than an isolated edge case.

For teams deciding whether to let a marketplace skill into a shared environment, the practical question is not whether obfuscation is possible. It clearly is. The question is whether the scanner sitting in the approval pipeline can see through it — and HKUST's numbers suggest most cannot, today, without an additional layer of defense.

Two ways in, both already proven

SkillCloak does not rely on a single trick. The write-up describes two separate evasion paths, and the researchers say both work independently of each other.

Lightweight obfuscation: swap characters, break the pattern

The simpler technique needs no repackaging. It substitutes flagged characters with Unicode homoglyphs pulled from other alphabets, and it splits flagged shell commands across newlines to break the pattern matching scanners rely on. The result, per the study: 80–96% evasion, depending on which scanner is doing the checking.

Self-extracting packing: hide the payload in .git/

The heavier technique relocates the entire malicious payload into a directory that scanners routinely skip, most notably .git/, to keep false positives and processing overhead down. A benign-looking decoder stub stays behind in the visible skill directory, so a manual glance at the package finds nothing alarming. An illustrative version of that layout looks like this:

skill/
├── README.md         (visible, looks benign)
├── setup.sh          (visible entry point, calls decoder stub)
└── .git/
    └── payload.sh     (actual malicious code, outside scanner scope)

Either mechanism on its own, the researchers report, pushed evasion above 90% across all eight tested scanners — character-substitution obfuscation or self-extracting packing into scanner-ignored directories like .git/. Just as important for an attacker: the write-up confirms the cloaked skills executed with identical effectiveness to the originals on both Claude Code and OpenAI Codex. Obfuscation cost nothing in functionality.

Why a hidden skill is worse than a hidden file

A skill is not a sandboxed script. Skills execute with the agent's inherited permissions: filesystem access, terminal privileges, and stored credentials. A malicious one can exfiltrate source code, steal passwords, or plant a persistent backdoor.

The stakes scale with where the agent runs. In enterprise environments where agents operate on shared infrastructure or CI/CD pipelines, a single malicious skill could produce broad credential compromise or intellectual property theft. And because one skill package can often run unmodified across multiple agent platforms, the exposure from a single cloaked skill is not confined to whichever tool first installed it.

The defense built to replace scanning

The same research team built a defensive counterpart named SKILLDETONATE. Rather than inspecting a skill's text for suspicious patterns, it shifts to runtime behavioral inspection, addressing what the researchers call the root cause of static analysis failure. It runs skills inside an OS-level sandbox and monitors file reads and writes, network egress, and sensitive data flows, tracking where data travels rather than what the code looks like at rest.

Static scanning vs. runtime sandboxing

Weighing the two models against what the research describes, the tradeoffs come down to what each approach inspects and what it costs to run:

Dimension	Static scanner	Runtime sandbox (SkillDetonate approach)
What it inspects	Code and text at rest, before execution	Behavior during actual execution
Known blind spot	Homoglyphs, split commands, hidden directories like .git/	None reported in the study; inspects data flow directly
Evasion shown in testing	Above 90% across all eight scanners tested	Not evasion-tested in the write-up; designed to close the pattern-matching gap
Operational cost	Lower; runs at install time or in CI as a quick check	Higher; needs sandbox infrastructure and monitoring per skill run

That last row is analysis, not a number from the study: sandboxing every skill execution is heavier than a pre-install text scan, and teams should budget for it accordingly.

Until a runtime sandbox is in place, security teams can still narrow exposure with manual review habits: diff every skill against its last approved version, treat any unfamiliar hidden directory as a review blocker, and require a second reviewer for skills that request filesystem or network access beyond what their stated function needs. None of this replaces behavioral monitoring, but it raises the cost of the exact techniques SkillCloak automates.

Which one should you actually trust

The recommendation in the write-up is unambiguous: don't rely on static scanners alone, since this research confirms they are insufficient. Prioritize runtime behavioral analysis tools equivalent to SKILLDETONATE, and restrict where skills are allowed to come from in the first place.

For teams that cannot deploy a full runtime sandbox immediately, the mitigation checklist from the research narrows to four items:

• Treat hidden directories as untrusted. Agent runtimes should flag or refuse execution of code originating from .git/ or similar scanner-blind paths.
• Apply least-privilege to skill execution. Don't grant a skill the agent's full permission set — filesystem access, terminal privileges, and stored credentials — by default.
• Restrict installation sources. The recommendation from the research: limit which sources are trusted to publish skills that get installed at all.
• Prioritize runtime behavioral analysis. The research recommends tools equivalent to SKILLDETONATE, which monitor file access, network egress, and data flow instead of matching text patterns.

If a static scanner is your only control today, put runtime monitoring first in line for any skill installed from an open marketplace or an unvetted third party — a text-based scan alone is not a meaningful gate against a technique this well documented. If skills only ever come from an internal, reviewed catalog with no marketplace intake, a scanner plus least-privilege execution may be an acceptable interim layer, but treat it as a stopgap, not a control you can point to in an audit.

Before your next skill install, check one thing directly with your scanner vendor: does it inspect .git/ and other hidden directories, or does it stop at the visible file tree? If the answer is the latter, every marketplace skill in your pipeline should be treated as unscanned code until behavioral monitoring is in place.