Agent Skills Are the New Software Supply Chain
(and Nobody Is Signing Them)
npm packages get signed. Docker images get signed. PyPI has Trusted Publishers. But the files that tell your AI agent what code to write, what tools to call and what patterns to follow? Those run unsigned, unverified and with full development environment permissions.
The new supply chain is invisible
When a developer installs a malicious npm package, dependency scanners catch it. When a Docker image is tampered with, image signing detects it. When a Python package is compromised, Trusted Publishers trace it to a specific GitHub workflow.
But when someone shares a .cursorrules file on GitHub with hidden instructions to weaken cryptography in every file the AI touches, no scanner catches it. No signature is checked. No tool flags it.
The AI agent reads the file, follows the instructions and generates vulnerable code. The developer sees clean output from a "helpful" rules file. The vulnerability ships to production. This is not theoretical. Security researchers have demonstrated every step of this chain.
18 file types, zero signatures
Every major AI coding assistant reads project-level configuration files that control its behavior. These files are the agent's instructions. They determine what code gets written, what patterns get followed and what tools get called. Here is the current landscape:
Cursor
.cursorrules.cursor/rules/*.mdc.cursor/mcp.json
Claude Code
CLAUDE.md.claude/settings.jsonSKILL.md
GitHub Copilot
.github/copilot-instructions.md.github/copilot-chat.yml
Others
.windsurfrules(Windsurf).clinerules(Cline).aiderules(Aider)AGENTS.md(OpenAI Codex).kiro/rules/*.md(Kiro)
How rules file attacks work
A rules file attack does not compromise a dependency. It compromises the code generation process. The malicious payload is never in your node_modules. It is generated fresh by your own AI assistant, following instructions it was told to trust.
The attack chain
Attacker publishes a rules file to GitHub, a community collection (like awesome-cursorrules) or a shared repository. The file looks helpful: coding standards, framework conventions, project setup instructions.
The file contains hidden instructions using BIDI Unicode overrides, zero-width characters or subtle wording that instructs the AI to generate vulnerable code. The developer cannot see the malicious instructions in a normal code review.
The AI agent reads the rules file and treats it as authoritative project instructions. It generates code with weak cryptography, hardcoded credentials, eval() calls or data exfiltration endpoints. The output looks like normal code.
Dependency scanners see nothing because no dependency is compromised. SAST tools see normal code. SCA tools see clean packages. The vulnerability was generated, not imported. Traditional security tooling has no signal to detect.
Real: The ClawHavoc Campaign (January 2026)
Koi Security discovered the first large-scale agent skills supply chain attack. Attackers published 341 poisoned agent skills to the ClawHub marketplace. Subsequent analysis revealed 1,184+ confirmed malicious skills. Snyk's ToxicSkills study found that 36.82% of all skills on the platform had at least one security flaw.
The attack distributed the Atomic (AMOS) macOS Stealer through poisoned skills. This was not prompt injection or subtle code weakening. It was actual malware, distributed through the agent skills supply chain, installed by AI agents that trusted the skill packages they were given.
The evolution matters: this was not an attacker tricking a human into running malware. It was an attacker tricking an AI agent into installing malware on behalf of the human.
Real: "From SKILL.md to Shell Access in Three Lines of Markdown"
Snyk published research documenting how malicious instructions hidden in SKILL.md files exploit AI agents as trusted intermediaries. Attackers insert malicious instructions into "Prerequisites" or "Setup" sections, and the AI agent presents them to users as legitimate setup requirements.
Three lines of markdown in a SKILL.md file was enough to get shell access on the developer's machine. The AI agent acted as a trusted intermediary, presenting the malicious setup steps as if they were standard project requirements.
Real: Rules File Backdoor (Pillar Security, March 2025)
Pillar Security uncovered a supply chain attack vector called "Rules File Backdoor" affecting both Cursor and GitHub Copilot. The technique uses Unicode obfuscation (zero-width joiners and bidirectional text markers) to hide malicious instructions inside .cursorrules and copilot-instructions.md files.
The poisoned rules subtly influenced the AI to produce code containing security vulnerabilities or backdoors. The attack works across different AI coding assistants because they all treat rules files as trusted input.
Real: Ransomware via a "GIF Creator" Skill
In December 2025, Cato Networks researcher Inga Cherny modified the widely-shared "GIF Creator" skill by inserting a function that downloads and executes remote code. The payload: MedusaLocker ransomware. The modified skill was not flagged by any security tool. End-to-end ransomware execution through a trusted skill, demonstrated in a controlled environment.
With Anthropic serving 300,000+ business customers, one malicious skill approved by one employee could trigger a multimillion-dollar ransomware incident. The barrier to publishing the skill: a markdown file and a week-old GitHub account.
The numbers
Real: CVE-2025-59944 in Cursor
Lakera disclosed CVE-2025-59944, a case-sensitivity bug in Cursor that allowed attackers to bypass protected file paths. A file named .CursorRules (capital C) was not treated as a rules file by Cursor's UI, but was still loaded and trusted by the AI agent.
The result: an attacker could include a malicious rules file in a repository that Cursor's security UI would not flag but the agent would still follow. A case-sensitivity bug in a file path check was enough to bypass the entire security boundary.
Why your current tools cannot catch this
Designed to detect vulnerable packages in package.json and lock files. Rules files are not dependencies. They are invisible to SCA.
Scans source code for vulnerabilities. But the vulnerability does not exist in the codebase until the AI generates it. SAST catches the output, not the cause.
Vulnerable to the same prompt injection that caused the problem. The rules file can instruct the reviewing AI to approve the vulnerable code.
BIDI characters are invisible. Zero-width characters are invisible. Subtle wording changes in a 200-line rules file are easy to miss. Human review does not scale for this threat.
Two layers that work
Layer 1: Cryptographic signing with Haldir
Haldir provides the missing layer that npm, Docker and PyPI already have: a way to cryptographically prove that a skill package or MCP server has not been tampered with since it was published.
The Agent Skill Attestation Format (ASAF) specification defines how skill packages are signed using DSSE v1.0.0 envelopes with Ed25519 signatures. The .vault/ directory in a signed package contains signatures and SHA-256 file hashes. If any file in the package changes after signing, verification fails.
Haldir also covers MCP server security. When an MCP server is signed, its tool manifests and descriptions are locked. The rug pull attack (where a tool mutates after installation) breaks the signature. Revocation support means compromised servers can be flagged even if their signatures are technically valid.
Layer 2: Deterministic scanning with CodeMarine
Signing tells you whether a file has been tampered with. Scanning tells you whether the file was malicious from the start. Both layers are necessary.
CodeMarine scans all 18+ rules file types for 43 known threat patterns across 8 categories: BIDI characters, prompt injection, credential exfiltration, weak cryptography instructions, eval/exec patterns, data exfiltration endpoints, security control bypasses and hidden instruction markers.
Scanning runs through editor hooks in Cursor, Claude Code, Windsurf, Kiro and GitHub Copilot. When a rules file is added or modified, CodeMarine scans it before the AI agent reads it. Deterministic pattern matching. No AI that can be manipulated by the content it is scanning.
Supply chain signing: then and now
| Ecosystem | Signing | Verification | Revocation |
|---|---|---|---|
| npm | ✓ Package signatures | ✓ npm audit signatures | ✓ Package unpublish |
| Docker | ✓ Content trust / Notary | ✓ Image verification | ✓ Tag revocation |
| PyPI | ✓ Trusted Publishers | ✓ Sigstore integration | ✓ Yank support |
| Agent Skills (today) | ✗ None | ✗ None | ✗ None |
| Agent Skills (Haldir) | ✓ ASAF / DSSE / Ed25519 | ✓ .vault/ verification | ✓ Registry revocation |
The window is closing
Every major software ecosystem went through the same arc: rapid adoption, a wave of supply chain incidents, then the painful retrofit of signing and verification. npm got there after the event-stream incident. Docker got there after image tampering attacks. PyPI got there after the growing tide of typosquatting.
The agent skills ecosystem is in the rapid-adoption phase right now. The incidents are happening (CVE-2025-59944 in Cursor, prompt injection in Anthropic's Git MCP server, the Supabase exfiltration). The question is not whether signing becomes standard. The question is how many incidents happen first.
Haldir is building the signing standard now, while the ecosystem is still small enough to adopt it before the next major breach. CodeMarine integrates natively with Haldir for verification and adds deterministic scanning for the attacks that signing alone cannot catch.
Scan your rules files and MCP configs
CodeMarine scans 18+ rules file types and 6 MCP config formats for 43 known threat patterns. Deterministic. Local. No AI in the loop.