A mysterious silhouette with red binary code projected over the face, set against a dark, moody background.
News

SkillCloak: The AI Agent Skill Packer That Passes Every Scanner and What Security Teams Can Do About It

SkillCloak packs malicious AI agent skills into .git/ to slip past scanners 90%+ of the time. What it means for Claude Code, Codex, and AI tool security.
Sami Malik
Copywriter

You run a security scanner on a skill before installing it into your AI coding agent. The scanner returns clean. You install the skill. In the background, the skill creates a hidden decoder inside a directory the scanner never reads, unpacks the malicious payload when the agent runs it, and begins exfiltrating source code to a remote server. The scanner was not wrong, exactly. It read what it could see. What it could not see was the whole point.

That is the core finding of a paper called Cloak and Detonate, published in July 2026 by researchers at the Hong Kong University of Science and Technology. The paper tested eight skill scanners against 1,613 real malicious skills pulled from ClawHub, a public marketplace, using a tool called SKILLCLOAK. The tool's heaviest technique, self-extracting packing, slipped past each of the eight scanners more than 90 per cent of the time. On most scanners, the bypass rate exceeded 99 per cent. The cloaked skills worked just as effectively on Claude Code and OpenAI Codex as the originals. The same researchers built a defence, SKILLDETONATE, that catches most of what the scanners miss. But the defence requires a different approach entirely.

What AI Agent Skills Are and Why They Run With Your Access

Skills are small packages that extend what an AI coding agent can do. The standard format is a Markdown instruction file paired with a handful of scripts. An agent like Claude Code, OpenAI Codex, or OpenClaw loads a skill and gains a new capability: reading a database schema, running a specific build tool, calling an internal API. The skill runs with the agent's own access level, which on a developer's machine typically includes the terminal, the file system, and whatever credentials are stored in configuration files or environment variables.

The appeal is obvious. A developer who needs the agent to interact with, say, their company's deployment pipeline can install a skill that knows how to do that, rather than writing the integration themselves. Public marketplaces like ClawHub allow skills to be shared across organisations and teams. The problem is that most of what a public marketplace lists has been uploaded by individuals with little vetting. A skill that looks like a useful Kubernetes helper might contain code that copies source files to an external server the moment the agent processes a task involving infrastructure.

Before installation, the main check is the skill scanner: a tool that reads the skill's files and blocks anything that matches known malicious patterns. SKILLCLOAK's purpose is to test whether that check is sufficient. It is not.

The Lighter Technique: Character Substitution and Line Splitting

SKILLCLOAK offers two methods for disguising a malicious skill. The lighter one modifies the give-away bytes that scanners pattern-match against. Rather than changing what the code does, it changes how it looks.

Character substitution replaces specific characters with visually identical equivalents from other Unicode ranges. A lowercase "a" from Latin is not the same byte as a visually identical glyph from Cyrillic or Greek, but when rendered in a text editor or terminal they are indistinguishable. A scanner that pattern-matches on the ASCII representation of a dangerous command misses it when the command is written with substitute characters. The command still executes correctly at runtime because the runtime decodes Unicode before processing the text.

Line splitting takes a flagged command and distributes it across a newline or comment break in a way that still executes as intended but breaks the scanner's regex. The scanner sees two lines, neither of which matches its pattern. The shell sees a continuation and executes the full command.

These are not new ideas. The same principles appear in malware obfuscation for traditional executables. What the paper demonstrates is their systematic application to AI agent skills at scale, with results measured across eight different scanning implementations. The lighter technique cleared more than 80 per cent of attempts on most scanners and reached 96 per cent on one.

The Heavier Technique: Self-Extracting Packing and the .git Blind Spot

The more effective technique exploits a specific decision that skill scanners make to keep their operation fast and reduce false positives: they skip certain directories. The .git/ directory is the most common skip target, because in a typical repository it contains version control metadata that has no bearing on the skill's runtime behaviour. Scanning it produces noise without adding signal. Every scanner tested made this tradeoff.

SKILLCLOAK's self-extracting packer moves the malicious payload into exactly that directory. The payload is stored in an encoded form inside a path the scanner never visits. Alongside it, the packer places a small decoder module in the portion of the skill that the scanner does read. The decoder looks harmless: a few lines that appear to handle a benign initialisation step. When the agent runs the skill, the decoder activates, reads the encoded payload from the skipped directory, reconstructs the original malicious code, and executes it.

From the scanner's perspective, nothing in the visible portion of the skill matches any dangerous pattern. The payload never appears in a location the scanner reads. The bypass is not a bug in any individual scanner; it is a consequence of a design decision that every scanner tested had made independently, for the same reasonable operational reasons.

The results across 1,613 skills were consistent: packing cleared more than 90 per cent of attempts on all eight scanners and exceeded 99 per cent on most of them. On Claude Code and OpenAI Codex, the cloaked skills performed identically to the originals. The malicious behaviour survived the disguise intact.

Why Prior Incidents Matter Here

The SKILLCLOAK research is not the first time malicious skills have been demonstrated at scale. The Hacker News previously reported on a separate research effort in which a fake skill was pushed past every scanner it faced and reached tens of thousands of agents. That earlier work established that distribution is a real problem. SKILLCLOAK adds a systematic method for bypassing the detection layer that was supposed to prevent distribution of known-bad skills.

Together, the two findings describe a situation where both novel malicious skills and known-bad skills can pass current scanning-based defences. New skills can be crafted to avoid detection from the start. Known-bad skills can be automatically disguised after the fact. The scanning paradigm is not broken in the sense of a specific coding error; it is architecturally unable to handle obfuscation that costs the attacker almost nothing to apply.

SKILLDETONATE: Watching Behaviour Instead of Appearance

The defence the researchers propose, SKILLDETONATE, abandons appearance-based checking entirely and focuses on what the skill does when it runs. It operates in a sandbox and monitors the skill's behaviour at the operating-system level: which files are read, which are written, which network connections are opened, where data flows.

Two ideas make SKILLDETONATE work specifically for AI agents rather than for generic malware sandboxing. The first is taint tracking: the tool labels sensitive data, such as credential files, private keys, and source code, and follows where that data moves. If it flows toward a network connection, that is a signal regardless of how the skill is obfuscated. The appearance of the code never enters the analysis. The second is that the sandbox is adapted to simulate the specific execution environment of AI coding agents, so the skill behaves as it would on a real installation rather than detecting the analysis environment and staying dormant.

SKILLDETONATE catches most of what SKILLCLOAK produces. But it adds latency to the installation process, and it requires a sand-boxed execution environment that not every marketplace or enterprise has the infrastructure to run. It is a stronger defence than what exists today, but it is not a zero-cost addition to the current workflow.

What the Marketplace Model Gets Wrong

The root condition that makes this attack class viable is the combination of minimal vetting, automatic execution permissions, and a user population that is likely to grant trust quickly because productivity gains are visible and immediate. A developer who installs a skill and finds it makes their daily work measurably faster is not inclined to treat future skill installations with suspicion. The one that stole their credentials looked and behaved exactly like the one that made them productive.

Most public skill marketplaces currently operate on a model where skills are uploaded by individual contributors, scanned automatically, and made available for download without human review at the individual skill level. Some apply reputation systems based on download counts or contributor history. Neither mechanism catches a well-crafted submission or a SKILLCLOAK-disguised variant of a previously flagged skill.

The history of software package ecosystems suggests this gap closes slowly. npm, PyPI, and RubyGems each went through extended periods where malicious packages were a known problem before meaningful security review infrastructure was built. AI agent skill marketplaces are at an earlier stage of that arc.

What Enterprises Running AI Coding Agents Should Do Now

The practical question for security teams managing environments where AI coding agents are deployed is how to evaluate skills before they reach developer machines. The paper does not suggest that skill scanners should be abandoned, but it does establish that they cannot be the only control.

A defence-in-depth approach for the current state of skill security includes several components. First, maintain a curated internal registry of approved skills rather than allowing developers to install directly from public marketplaces. This does not eliminate the risk from malicious skills that passed the initial review, but it reduces the attack surface to skills that at least went through a deliberate approval process.

Second, monitor agent activity at the operating-system level on developer endpoints. SKILLDETONATE's approach, watching what files are accessed and where data flows, can be approximated using endpoint detection and response tools already deployed in most enterprise environments. A skill that reads from a .ssh/ directory and then initiates a connection to an unknown external IP is detectable even without a dedicated agent skill sandbox.

Third, treat credential files accessible from developer machines as high-sensitivity assets. SSH private keys, API tokens stored in dotfiles, and environment variables containing service credentials should not be accessible to processes that do not need them. Agent processes can be run in restricted environments where they hold only the credentials required for the specific task, reducing the value of any credential-stealing payload that does land.

Fourth, keep skill installations auditable. A developer who installed something from an external marketplace last Thursday and noticed an unexpected outbound connection on Friday should be able to identify the skill, remove it, and report the hash to the relevant security team. Most current implementations do not make this audit trail easy to access.

The attack SKILLCLOAK enables is sophisticated in its bypass mechanics but conventional in its goals: steal credentials, copy source code, install a backdoor. The novelty is the delivery channel. AI agent skills, because they are new, occupy a trust category that enterprise security programmes have not yet fully evaluated. That evaluation is overdue.

The Economics of Skill Marketplace Trust

The architectural problem with public AI agent skill marketplaces is not technical. It is economic. Marketplace operators compete on breadth of catalogue: more skills, more use cases, more productivity gains for users. A skill that takes ten minutes to write can be published in under an hour. The incentive to grow the catalogue rapidly favours quantity over quality. Vetting every skill submission at a depth that would catch SKILLCLOAK-level obfuscation is expensive and slow. Static scanning is cheap and fast, which is why it became the default.

This exact dynamic played out in the npm ecosystem starting around 2018. The shift from a community-driven package registry to a security-critical supply chain happened gradually, and the realisation that malicious packages could reach millions of developers through a trusted channel came after a series of high-profile incidents rather than from proactive security investment. The response, better tooling, mandatory 2FA for high-download packages, and automated malicious package detection, took years to develop and still does not catch every case.

AI agent skill marketplaces are at an earlier point in that arc. ClawHub, the marketplace used in the SKILLCLOAK research, is a public platform with minimal barriers to contribution. The same openness that makes it useful as a research dataset makes it an accessible distribution channel for malicious skills. SKILLCLOAK demonstrated that the static scanning layer that provides the main safety signal is systematically bypassable. The question is not whether malicious skills will be distributed through these channels. It is how long before a widely-used skill in a popular marketplace is identified as having been malicious for an extended period, and how many developer credentials were stolen in the interim.

Taint Tracking in SKILLDETONATE: How It Works in Practice

The SKILLDETONATE defence the paper proposes is worth examining in operational detail, because the gap between a research prototype and a production-grade deployment tool is where most academic security work stalls. The core mechanism, taint tracking, assigns labels to sensitive data objects at the point where they enter the execution environment and follows those labels as data is copied, transformed, and transmitted. When a labelled value reaches a network send call or a file write outside the sanctioned output locations, the tracker raises an alert.

For AI agent skills, the researchers adapted taint tracking in two ways that matter for practical deployment. First, they defined sensitivity labels based on the agent's execution context rather than generic file categories. Private keys, credential files in standard locations, environment variables containing API tokens, and source code files under version control all receive sensitivity labels at the start of the sandbox run. Second, they built the sandbox to simulate the agent's actual execution environment rather than a generic Linux process, because a malicious skill might detect sandboxing through the absence of expected agent-specific environment variables and stay dormant.

On the 1,613-skill dataset, SKILLDETONATE caught the majority of skills that SKILLCLOAK successfully disguised from static scanners. The false positive rate, skills flagged as malicious that were actually benign, was low enough that the researchers considered it operationally viable. This does not mean SKILLDETONATE is ready for enterprise deployment without further work. The research prototype runs significantly slower than a static scanner, which adds latency to the skill installation flow. And taint tracking is only as effective as its initial labelling: a creative malicious skill that reads sensitive data through an unlabelled path can still evade it.

Governance for Enterprise AI Tool Deployments

The SKILLCLOAK research is a prompt for security teams to formalize AI tool governance in a way that most have not yet done. AI coding agents are now common enough in enterprise environments that they represent a real attack surface, but the governance frameworks that apply to traditional software procurement, vendor security assessments, software composition analysis, and change management processes, do not map cleanly onto tools that extend themselves dynamically through skill installation.

A minimal governance framework for AI coding agents includes several elements that most current enterprise deployments lack. First, an inventory of which agents are deployed and which skills are installed on each, including version history. This is the baseline for any incident investigation: knowing what was installed when a suspicious outbound connection was observed. Second, a clear policy distinguishing skills sourced from an approved internal registry from skills installed ad hoc from public marketplaces, with different approval requirements for each category. Third, monitoring of agent process activity at the operating-system level, specifically file access patterns that suggest credential harvesting and outbound connections to unrecognised endpoints.

The monitoring component is achievable with endpoint detection tools most enterprises already have. The gap is not capability but configuration: EDR rules that flag file access to .ssh/, .aws/, and similar credential directories by processes that are not the owning application are straightforward to write. Adding AI agent processes to that monitoring scope is a configuration change, not a new tool investment. The question is whether the security team managing the EDR knows which processes to monitor, which requires the inventory step first.

SKILLCLOAK is a demonstration of a technique, not an active threat campaign with known attribution. But the technique is now published, the tooling is documented, and the marketplace infrastructure to distribute disguised skills already exists. The window between a technique being demonstrated and it being used in active attacks is shrinking across the industry. Security teams that build AI tool governance now are ahead of the curve. Those that wait for an incident to justify the work will be building governance during the response.

How Defendis Can Help

Attackers who steal credentials, authentication tokens, or employee data do not sit on that material for long. They sell it, use it themselves, or both. Defendis monitors the underground markets, leak sites, and closed communities where that data surfaces, giving security teams advance warning before stolen access becomes a compromised account. If credentials belonging to your organisation appear after a browser-based theft, an OAuth token heist, or a phishing campaign, Defendis surfaces the exposure so your team can act before the attacker does. Learn how early detection changes incident outcomes or request a tailored briefing for your organisation.

About the author
Sami Malik is a copywriter passionate about crafting clear, engaging, and impactful content that helps brands connect with their audience through storytelling and strategy.

Related Articles

Discover simplified
Cyber Risk Management
Request access and learn how we can help you prevent cyberattacks proactively.