Read the SKILL.md before it reads your .env

June 29, 20264 min read

If you installed a Claude Code skill in the last month, there is roughly a one-in-eight chance it carries a critical security flaw. That is not a scare stat I made up. Snyk scanned 3,984 agent skills in February 2026 and found 13.4% had a critical-level issue and 36.8% had at least one security flaw of some kind. The skill you grabbed to save twenty minutes can read your files, your environment variables, and your credentials, because it runs with your agent's full permissions. Most people never look. Here is how to look, in about five minutes, and what certification checks so you don't have to do it every time.

What a skill can touch once you install it

A skill is not a sandboxed plugin. It is a set of instructions your agent follows with the agent's own access. That means shell commands on your machine, read and write to your files, whatever is in your environment variables and config, the ability to send messages, and memory that persists across sessions. Snyk's writeup put it plainly: the bar to publish a skill on a public hub is a SKILL.md file and a week-old account. No code signing, no review, no sandbox by default.

So "it's just a markdown file" is exactly the problem. The markdown is the payload.

The dangerous part is usually the words, not the code

Traditional malware hides in compiled binaries. Skill attacks hide in plain English. The most common pattern Snyk documented is an instruction buried in the SKILL.md that fires under a normal-sounding condition, then does something you did not agree to. A real decoded example from their study: a "setup" step that base64-decodes to a command that reads your AWS credentials and sends them to an attacker's server. Your agent reads it as a legitimate instruction and runs it.

Snyk found that 91% of confirmed malicious skills paired a prompt injection with the actual payload, because the injection primes the agent to ignore its own safety checks first. The text talks your agent into running the code. Regex scanners and "does this look like malware" tools miss it, because nothing looks like malware. It looks like documentation.

The five-minute audit you can run on any skill

Before you install a skill from somewhere you don't fully trust, open the SKILL.md and actually read it. Look for:

Hidden or obfuscated instructions. Base64 blobs, eval, anything decoded at runtime, and invisible Unicode. If a setup step is encoded instead of written out, that is a choice, and it is not a good one.
Outbound network calls. curl, wget, anything piping to bash, any request to a domain you don't recognize. A skill that phones home on install is a skill that can send your data out.
Secret handling. Any instruction that echoes, prints, or "includes" an API key, or asks you to paste credentials into a command. Real skills never need your keys in the clear.
Who wrote it and when. A one-week-old account with one skill is not the same as a maintained project. Snyk found whole campaigns of throwaway accounts publishing the same malware under new names.
What it fetches at runtime. A skill that pulls instructions from a remote URL can be clean today and malicious next week, because the behavior lives on someone else's server, not in the file you reviewed.

That list is not exhaustive, but it catches most of what the studies are finding. If a skill trips two or more of these, skip it.

The honest problem: this does not scale

Reading one SKILL.md is five minutes. Vetting every skill, every update, across your whole team, at 1am, is not a thing anyone actually does. And even a perfectly clean skill can be a problem: Snyk found 17.7% of skills fetch third-party content, which means a skill that does nothing wrong can still pull in a poisoned web page and hand those instructions to your agent. You cannot eyeball your way out of a supply chain.

This is the same movie the npm and PyPI ecosystems already sat through. The fix was never "everyone manually reviews everything." It was "someone checks it systematically before it ships."

What "certified" means here

That is the part we do at ClearPoint Nexus, so it is worth saying exactly what it covers instead of waving at the word "certified." Every skill in the catalog clears 96 certification checks across three layers, structure, platform fit, and quality, plus a separate 7-dimension security scan, on all four platforms (Claude Code, Codex, OpenClaw, and Google Antigravity), before it lists. No partial passes.

The security scan looks at the same risk classes the studies keep surfacing: prompt injection including hidden-Unicode tricks, hardcoded secrets, shell and command injection, an outbound-URL allowlist, tool-use safety, output schema, and supply-chain provenance. A serious finding blocks the skill from the catalog. We describe what we check, and we keep checking as the catalog grows, which is 200+ certified skills and counting.

That does not make the broader ecosystem less messy. It just means the skills you install from us already went through the audit you would otherwise be doing yourself at 1am.

Takeaways

A skill runs with your agent's full access, so "just a markdown file" is the risk, not the reassurance.
The attack is usually a prompt injection in the SKILL.md, not code, which is why ordinary scanners miss it.
You can vet a single skill in five minutes: check for hidden instructions, outbound calls, secret handling, the author, and runtime fetches.
Manual review does not scale, which is the entire reason certified catalogs exist.

If you would rather install skills that already cleared the audit, browse the certified catalog and read the certification page to see exactly what each one passed.

Source: Snyk, "ToxicSkills" study, February 2026.