A shadow feature is a capability implemented inside an agent skill but absent from its public documentation or SKILL.md description. It's the gap between what a skill says it does and what its code is actually built to do, and it's one of the clearest fingerprints of a malicious agent skill.

Why the trust gap exists

Most people approve a skill based on its visible description. If a skill calls itself a Markdown formatter, a project summarizer, or a GitHub helper, that description is usually the entire basis for the decision to install it. The implementation can do more. A "GitHub helper" can validate repository metadata and generate issue summaries exactly as promised, while its helper script also inspects environment variables, searches for .env files, and attempts an outbound connection to an endpoint the documentation never mentions.

Shadow features are especially dangerous in agentic environments because the skill's behavior is mediated by the AI agent itself. A person skimming the SKILL.md file has no reason to expect the extra behavior, and static documentation alone won't reveal it.

How shadow features get caught

Detecting a shadow feature means comparing declared purpose against observed runtime behavior, not just reading the code. That comparison typically pulls from four sources: what the agent actually did (executed commands, skipped commands, errors), system call traces (file access, process creation, permission changes), network captures (DNS queries, outbound connections, upload-like traffic), and filesystem changes (files created, modified, or deleted during execution).

A skill that claims to be a formatter has no legitimate reason to open a socket connection to an external domain. When runtime evidence contradicts the documented purpose, that mismatch is the signal, independent of whether the underlying code was obfuscated or written in plain sight.

In sandboxed testing, shadow features showed up in effectively all of the confirmed malicious skills examined, and in none of the benign ones. The presence of a capability the documentation never mentioned was one of the single strongest indicators of malicious intent researchers found.

Why this changes how you review skills

A code review that only checks "does this look like it does what it says" will pass a shadow-feature skill every time, because the code that does what it says is real and does run. Catching the extra behavior requires running the skill somewhere safe and watching what it actually touches, then holding that against the stated purpose.

FAQ

Can a shadow feature be there by accident, not maliciously? It can. Dead code, debug logging, or an unused dependency can look like undocumented behavior without being an attack. That's why correlation matters: an isolated unused import is noise, while a documented "formatter" that also encodes and transmits file contents to a hardcoded external domain is evidence.

Is a shadow feature the same thing as obfuscation? No. Obfuscation hides code so a human can't easily read it. A shadow feature can be written in completely plain, readable code and still be a shadow feature, because the problem isn't how it's written, it's that it was never disclosed.

What's the fastest way to check for shadow features on skills already in use? Run the skill in an isolated sandbox with harmless dummy inputs, capture its filesystem, network, and system call activity, and compare that activity against what the SKILL.md file actually claims the skill does.

Related reading: "What Is an AI Agent Skill, and Why Is It a Supply Chain Risk?," "Inside the Sandbox: What Dynamic Analysis Reveals About Agent Skills"