Claude Code skills are a great productivity unlock. They're also a fast way to hand code execution to people who have never heard of your change management policy.

In many organizations this scenario is playing out: someone builds a useful skill, shares it in Slack, and suddenly there's pressure to "enable skills for everyone." What follows is the threat model in a single sentence, the risks and controls in NIST CSF 2.0 language your CISO already speaks, and a worked example: a skill run through an intake pipeline you can apply to your own org.

Read on if you're a GRC analyst, a security lead, or the person who just got asked "can we turn this on?"

Most of what a risk assessment handles is bounded. A misconfiguration exposes one setting. A leaked field exposes one dataset. A phishing email still needs a person to click. You can draw the blast radius, and the right control usually follows from the shape of it.

Executable code erases the shape. Code is arbitrary by definition, so the moment a skill can run it with someone's credentials, "what could go wrong" stops being a list you can finish and becomes "anything that account can reach." You have stopped assessing a vector and started assessing a capability, and capabilities don't enumerate.

That is the move that takes this into the deep end. A static document, a data feed, a config file all sit in the shallow end where you can see the bottom. Hand something the ability to execute, and the floor drops out. Every risk in this post is a downstream consequence of that one shift.

A skill is a folder. Inside it sits a SKILL.md file with instructions written in plain language, plus (optionally) scripts and supporting files. When Claude Code sees a task that matches the skill's description, it loads those instructions and follows them. Skills can bundle executable code, and Claude runs that code.

That's the whole mechanism. Nothing gets compiled or signed, and nobody reviews it before it lands in your environment. A skill is a text file that programs your AI agent.

It's there if you want to go deeper on the mechanics. And the mechanics are worth knowing: understanding the underlying technology and how your team actually uses it will protect you more than any amount of framework alphabet soup. The CSF references later in this post are for communicating your program, not a substitute for knowing how the thing works.

Here it is:

Everything else in this post is a consequence of that sentence. When you enable Claude Code skills across a team, you extend your agent's trust boundary to every skill author. The junior analyst who wrote that handy report-formatting skill? When your admin runs it, it executes with the admin's credentials and everything the admin's account can reach.

If that framing sounds familiar, it should. This is a software supply chain problem applied to knowledge worker productivity.

CISA's Secure by Design guidance already covers this ground. Claude Code skills are just the newest dependency it applies to.

Six distinct risks fall out of the trust boundary shift that Claude Code skills introduce. Know all six, because they need different controls.

And the base rate says this is worth your time. A January 2026 analysis of more than 42,000 skills across two public marketplaces, written up by Jason Rebholz in The Weekend Byte, put numbers on it: 26.1% carried at least one security issue, and 5.2% were rated likely malicious. Credential harvesting from environment variables, file-system sweeps for SSH keys, hidden instructions in doc strings. Install a hundred skills from public sources and the expected number of actively malicious ones is five, not zero.

The headline risk. Skills can bundle scripts, and Claude runs them. A malicious skill, or just a buggy one, means code executing in the runner's environment with their credentials. You already govern this risk in every other dependency your team pulls in. Skills need the same treatment. 

The SKILL.md instructions load into the model's context and get treated as instructions. A crafted skill can redirect the agent to exfiltrate data, take unauthorized actions, or override guardrails with zero code in the folder. And because skills auto-activate when a task matches their description, a poisoned skill can fire when nobody deliberately invoked it.

The attack payload is grammatically correct English. There is no signature for a scanner to match. That is why prompt injection sits at number one on the OWASP Top 10 for LLM Applications as LLM01: of every risk on that list, it has the least reliable defense.

Author identity and runner privilege are different things. A skill written by an intern but run by someone with production access inherits the production access. Every connected integration your power users have (email, cloud storage, internal APIs, MCP connectors) is now reachable by any skill they run.

Skills arrive from gists, blog posts, and colleagues. No signing, no integrity checking, transitive trust all the way down. Worse: a skill vetted once can be edited after approval. That's a classic time-of-check to time-of-use gap. Yesterday's clean review says nothing about today's file.

People hardcode API keys and internal URLs into skills, then share them. Without a registry there's no inventory, and you cannot audit or run incident response on assets you can't see.

The sleeper risk for GRC teams specifically. A benign but wrong skill standardizes the error. If your team's output is risk guidance and compliance decisions, a confidently wrong shared skill does more day-to-day damage than malware. Quality review is a security control here.

Before you design any controls, scope the surface, because blast radius swings materially depending on the answer.

Claude Code skills running on developer laptops get a real shell, real credentials, and whatever the developer can reach. Claude Code skills running in a managed enterprise environment with a sandboxed interpreter and admin-controlled connectors are a much smaller problem. Decide which rollout you're actually governing. The controls below assume the scarier one.

The instinct is right and the control is real, but as your only control it fails twice.

First, scanning can't catch the worst risk. Secret scanning and static analysis work on files and patterns. Prompt injection is semantic natural language. A scanner gives you confident assurance on exactly the vector that deserves the least confidence.

Second, central review of everything becomes the bottleneck that kills the unlock. You'll recreate shadow IT, except now it's shadow skills passed around in DMs, invisible to your inventory.

Treat this table as a starting point you can lift straight into your framework mapping. 

NdaReview is a skill I published that triages the click-through NDAs gating vendor trust centers. Let's scan it with Anthropic's claude-code-security-review, a GitHub Action that also ships inside Claude Code as the /security-review slash command.

Gate 1: Intake and provenance (ID.AM-02). Source, internal owner, claimed purpose, and what it's derived from. NdaReview is adapted from the check_agreement pattern in Daniel Miessler's Fabric project. Disclosed derivation is the good case. Undisclosed is the bad case, and you only catch it if provenance is a required form field.

Gate 2: Capability inventory (GV.SC-04). What the skill can do, not what it says it does. Five files: SKILL.md, README.md, pattern/system.md, LICENSE, .gitignore. No scripts, no egress, no declared tool access, no secrets. A pure-prompt skill, low code-risk tier. Two things still stand out: it installs by git clone with no pinned commit, and it reads untrusted external content.

Gate 3: Automated scan (DE.CM-09). Run /security-review, or wire the Action into your skills registry repo so future changes arrive as reviewable diffs. Result: zero findings. Not a surprise, and not a pass. 

Scope: all 5 files, all 2 commits, full history. Findings at confidence ≥8: 0.

Attack surface inventory:

The repo is 273 lines of Markdown: a skill definition, the same prompt as a standalone Fabric pattern, a README, MIT LICENSE, and a one-line .gitignore. There is no data flow, no privilege boundary, and no input reaching an operation. Every category in the tool's prompt — injection, authn/authz, crypto, RCE, XSS, data exposure — has nothing to bind to.

Below-threshold observation (excluded by the tool's own rules — reporting it anyway)

The one thing worth naming: this skill ingests attacker-adjacent text (an NDA from a vendor portal) directly into a prompt, and its output drives a sign/escalate decision. 

Gate 4: Semantic review. Read SKILL.md as what it is, an instruction set your agent will load and follow.

Untrusted ingest. 

The risk here lives at runtime.

Gate 5: Runtime scoping (PR.AA-05 / PR.PS-05). The actual boundary, and here it's short: document read, nothing else. No writes, no egress, no connectors. Scope it to nothing and a poisoned NDA gets you a poisoned NDA review. Scope it to a laptop shell with live cloud credentials and you have a different day.

Gate 6: Registry entry (ID.AM-08, ID.RA-09, RS.MA-01). None of this counts until it's somewhere your incident responder can find at 2am.

Yes. With a registry, a capability tier, an automated gate, a human read, and a runtime scope.

Claude Code skills are already on somewhere in your organization, installed by git clone from a link in a Slack thread, and the choice in front of you is whether they run inside a process or outside one. A pipeline that takes twenty minutes and produces a registry entry will get used. A review board that takes three weeks will get routed around, and you'll find out about it during an incident.

Start with the inventory. Add the runtime scoping. Everything after that is tuning.

What you'll notice the first time you run this is that the gate that earns its keep isn't the scanner. It's the human read in Gate 4, where someone finally asks what the skill is allowed to believe. That question doesn't have a tool behind it yet, and until it does, it's the part you can't skip.

Claude Code skills mechanics

Tooling used in this walkthrough

Frameworks and guidance

Related reading on this blog