Data Exfiltration via Skills: Attack Paths and Defenses

The Consent Gap: Why One Click Grants Attackers Everything

One click. That's the entire security review most agent skills will ever receive — and the numbers behind that click are alarming. A large-scale academic analysis of 31,132 skills found that 26.1% carry at least one vulnerability, with data exfiltration the most prevalent category at 13.3%.

The mechanism researchers call the "consent gap" explains why this matters so much. Once a user approves a skill, it gains persistent permissions to read files, write files, download code, and open network connections — all without further prompts. That single approval converts a stranger's Markdown file into a long-lived, privileged resident on your machine.

Cato CTRL's researchers put it bluntly: users approve what they see, but hidden helpers can still perform sensitive actions behind the scenes. In their demonstration, a modified GIF Creator skill executed live ransomware with no secondary prompts. Visibility stops at the surface; the consequences do not.

What makes skills uniquely dangerous is their very nature. As AISA researchers note, every line in a skill file is an instruction, which makes prompt injection trivial. Detection techniques that flag "instructions hiding in data" simply don't apply — there is no data, only instructions. Traditional defenses collapse:

• WAFs inspect syntax, not intent, so obfuscated commands slip through
• Keyword blocklists fail against rephrasing and base64/Unicode encoding
• System-prompt reminders buckle under adversarial phrasing
• LLMs process instructions and data identically, so they cannot enforce trust boundaries alone

The exfiltration paths that exploit this gap are already documented in the wild. A malicious "backup" instruction in a public presentation-editing skill uploaded users' slide decks to an external server, with no additional authorization requested. In the Claude web interface, the agent even embedded a password into a link in its final summary — one click on that link and the data leaked.

Snyk's audit reinforces the scale of the problem: 13.4% of 3,984 scanned skills contain at least one CRITICAL issue, and 91% of confirmed malicious skills pair malicious code with prompt injection, priming agents to accept payloads safety mechanisms would otherwise reject.

This is the structural vacuum SkillzBench is being built to fill — pinning every skill version to a commit SHA, security-scanning before an agent ever loads it, and ensuring each agent only sees the skills and tools explicitly toggled for it. Until capability-based permission systems and mandatory vetting exist, the consent gap remains the single most exploitable weakness in the skills ecosystem.

Anatomy of the Attack Paths: Six Documented Ways Skills Steal Your Data

What makes skill-based exfiltration so dangerous is that it rarely requires breaking anything. The agent already has file access, network access, and your trust — the skill just redirects them. And the techniques are documented, reproducible, and in active use.

Consider the range of attack paths researchers have confirmed:

• Obfuscated credential theft. Snyk's audit of 3,984 skills found payloads like base64-encoded curl commands that quietly pipe ~/.aws/credentials to attacker-controlled servers — encoding that defeats keyword-based detection.
• Hidden code execution. Cato CTRL added a legitimate-looking post_save helper to Anthropic's official GIF Creator skill that silently fetched and ran an external script — and executed a live MedusaLocker ransomware attack with no secondary prompts.
• The malicious "backup." AISA researchers documented a public presentation-editing skill whose "backup" instruction uploaded slide decks to an external server. In the Claude web interface, the agent even embedded a password into a link in its final summary — clicking it leaks the data.
• Remote instruction loading. Skills that fetch instructions at runtime (think curl instructions.md | source) can change behavior after anyone reviews them.
• Automated injection. The SkillJect framework hides payloads in auxiliary .py and .sh scripts while injecting a short inducement prompt into SKILL.md, leading to leaked API keys and documents.

The scale is sobering. A large-scale academic analysis of 31,132 skills found data exfiltration is the single most prevalent vulnerability category, affecting 13.3% of skills. Snyk separately confirmed 76 malicious payloads, 91% of which pair malicious code with prompt injection designed to prime agents into accepting what safety mechanisms would reject.

Multi-agent environments widen the blast radius further. In research covering 17 state-of-the-art LLMs, 82.4% executed malicious commands from peer agents that they would have refused if the same commands came directly from a user. A compromised skill on one agent can become the launchpad for an entire fleet.

The common thread across all six paths is what researchers call the consent gap: one approval grants persistent permissions with no further checkpoints. This is precisely the problem SkillzBench is building against — version pinning to commit SHAs, security scanning, and per-agent loadouts so an agent only ever sees the skills and tools you explicitly toggled on. Until verification becomes standard, every install is an act of trust in an ecosystem that hasn't earned it.

Why Traditional Defenses Fail — and What Actually Works

Every skill file is 100% instructions — which is exactly why the defenses most teams rely on collapse the moment an agent loads one. As AISA researchers put it, "every line in these skill files is an instruction, which makes prompt injections trivial."

Nightfall's analysis frames the problem precisely: an agent becomes exploitable when it simultaneously has access to private data, exposure to untrusted content, and the ability to communicate externally. No software vulnerability is required. Skills are dangerous precisely because they hand an agent all three legs at once — and once a user approves a skill, it gains persistent permissions to read files, download code, and open network connections without further prompts.

Meta formalized this as the "Agents Rule of Two": agents should satisfy no more than two of the three properties. If all three are needed, a human must be in the loop.

The standard security stack was built for a world where data and instructions are distinguishable. LLMs break that assumption — they process both identically. WAFs look for syntax, not intent. Keyword blocklists fall to base64 encoding and Unicode obfuscation, like the confirmed payload that exfiltrated AWS credentials via a single curl command. And system-prompt reminders collapse under adversarial phrasing. Nightfall's verdict is blunt: no known technique reliably prevents prompt injection in a general-purpose agent.

The consent gap makes it worse. Cato CTRL demonstrated that even in strict mode, users see only the visible layer of a skill — a legitimate-looking helper function executed live MedusaLocker ransomware with no secondary prompts.

Expert consensus is converging on a structural answer. If the model can't enforce trust boundaries, security must live in deterministic code around it:

• Break the trifecta — sandbox execution and restrict external communication so no agent holds all three properties at once
• Apply least privilege and treat skills as executables, with the same controls you'd apply to a downloaded binary
• Require human-in-the-loop approval for consequential actions, and monitor tool invocations and outbound connections
• Source only verified skills — pinned to a commit SHA, security-scanned, and continuously re-checked as upstream changes land

The research data backs the scoping question too: executable-bearing skills are 2.12× more likely to contain vulnerabilities than instruction-only ones, which is why SkillzBench fully verifies instruction-only skills at launch and lists script-bearing skills link-out only. The point isn't that any single control is sufficient — it's that defense-in-architecture is the only layer an attacker can't rephrase their way past.

Building a Verified Skill Supply Chain: Practical Controls for Teams

Given that roughly one in four agent skills carries at least one vulnerability, teams need a concrete verification workflow — not just awareness. The good news: the research points to a small set of controls that map cleanly onto how a verified skill supply chain should work.

The foundation is treating skills like any other executable dependency. Cato CTRL's researchers, who demonstrated a live MedusaLocker attack through a modified skill, recommend applying the same controls to skills as to downloaded scripts and binaries (Cato CTRL). In practice, that means a checklist like this:

• Pin every skill to a commit SHA. A version tag alone doesn't guarantee the code you reviewed is the code you run. Commit-level pinning closes the gap where upstream changes silently alter behavior.
• Security-scan before enablement. Snyk's audit found 13.4% of skills carry at least one CRITICAL issue, and 91% of confirmed malicious skills pair malicious code with prompt injection designed to prime the agent into accepting it (Snyk). Scanning must look for both.
• Apply per-agent least privilege. Agents should only see the skills and tools explicitly toggled for them — no default omniscience. This directly shrinks the "consent gap," where one approval grants persistent file, network, and code-download permissions.
• Benchmark in a sandbox. Test skills in isolation with the same model, with and without the skill, before they touch real data.
• Re-scan on upstream changes. A skill that was safe last week may not be this week — 17.7% of skills fetch untrusted third-party content, so risk can arrive through dependencies, not just the skill itself.

This is the workflow SkillzBench is building, structured around five pillars: Discover (continuously crawling and deduplicating skills from GitHub), Verify (commit-SHA pinning, validation, license checks, and security scanning), Benchmark (sandboxed testing that publishes the Lift in percentage points), Equip (one MCP server with per-agent loadouts), and Stay current (tracking upstream changes and re-scanning).

One scoping decision stands out as empirically grounded. The large-scale study of 31,132 skills found that script-bearing skills are 2.12× more likely to be vulnerable than instruction-only skills (arXiv). That's why SkillzBench's launch scope fully verifies instruction-only skills — SKILL.md packages plus text references — and lists script-bearing skills as link-out entries only. Starting where the risk is lowest isn't caution; it's following the data.

No single control eliminates the threat. But layered together — pinned versions, scanned code, scoped loadouts, sandboxed benchmarks, and continuous re-verification — they turn an unvetted supply chain into a managed one.