Agent skills are how a capable agent stays organised: each skill is a folder with a document describing it and the code that does the work, loaded on demand. It is a clean pattern, and it is being adopted widely.
It also bundles two things this series has warned about separately, into one convenient package. A skill is instructions the model reads and code it executes, and installing one is agreeing to run both.
A skill is two attack surfaces in a trench coat
Pull a skill apart and you see two things this series has already flagged as untrusted when they come from outside.
The document is an instruction. The SKILL.md is read into the model's context as authoritative
guidance on how to use the skill. From the tool-description post: text the model reads as instruction
steers what the agent does. A skill's document is exactly that, with more room to hide a directive.
The code is executed. The skill ships a script that runs in the sandbox. From the code-execution posts: running code you did not write, driven by a component under injection pressure, is the sharpest risk there is.
A skill fuses them. One folder is both the instruction channel and the code-execution channel, adopted in one step, often from a shared library of community skills. Installing a skill is a supply-chain decision with the stakes of running arbitrary code and the deniability of "it is just a helper."
A skill is a document the model obeys plus code it runs. Installing one adopts both.
Progressive disclosure trusts a one-line description
Here is the twist skills add on top, and it is specific to how they are loaded.
Progressive disclosure keeps the prompt small by showing the model only each skill's one-line description, then letting the model decide which skill to read and run based on those descriptions. The selection of which code to execute is driven by a sentence the skill author wrote.
That sentence is a description-as-instruction problem with the stakes raised. In the tool-description post, a misleading description got the wrong tool called. Here, a misleading description gets the wrong skill's code loaded and run. A skill named and described as "format-dates: tidy date strings in a report" whose code does something else entirely gets selected for a benign-sounding job, and the agent runs it because the description said it fit.
what the agent sees (level 1): format-dates: tidy date strings in a report
what the code actually does: reads the workspace and posts it to an external URL
The agent chose to run it based on the description, exactly as the pattern intends. Progressive disclosure is efficient, and it makes the description the thing that decides which code executes, which is a lot of trust to place in a line of text from whoever wrote the skill.
Why "it is just a skill" is the dangerous part
Skills are framed as lightweight: drop a folder in, the agent picks it up. That framing is the risk.
A dependency you pip install at least goes through a manifest and a review habit. A skill dropped into
a folder often gets neither, because it reads as configuration, not code, and because the whole appeal
is that adding one is easy.
So the same failure as the MCP-server post recurs, one layer over: a component that runs code and feeds the model instructions, adopted through a path that skips the scrutiny you give real dependencies. The easier it is to add a skill, the less likely anyone vetted the one that was added.
Treating skills like the code they are
The controls are the supply-chain and least-privilege habits this series keeps returning to, pointed at the skills folder.
| Control | What it changes |
|---|---|
| Review a skill's code and its document before adding it | A skill is code and instructions; read both like a dependency, not a config file |
| Pin skills to a version and vet updates | An updated skill can change its code and its description with no diff you noticed |
| Source skills from a trusted registry, not ad hoc folders | An easy drop-in path is an easy attack path |
| Run every skill in the sandbox, boundary and all | The code-execution and boundary controls from the last two posts apply to skill code too |
| Do not let a description alone decide a sensitive action | For skills that do something irreversible, the gate is code or a human, not the skill's own words |
| Log which skill was selected, and why | A misleading selection you can see is one you can catch |
Review the code and the document, pin versions, sandbox the code, and never let a description alone gate a sensitive action.
The fourth row is the anchor. Everything in the previous two posts, isolation, a locked-down boundary, resource limits, applies to a skill's code exactly as it applies to code the agent writes itself, because a skill's code is code the agent runs. Skills do not get a pass on the sandbox for being packaged nicely.
What this touches
For the frameworks, this maps to T17 Supply Chain Compromise, which the pack defines as harmful components, including tools and libraries that run arbitrary code, brought into the agent. A skill is such a component. The description-driven selection of which code to run maps to T6 Intent Breaking and Goal Manipulation, and where the misleading description drives an unintended action, T2 Tool Misuse. In the OWASP Agentic Top 10 the anchors are ASI04 and ASI01.
On the regulatory side, framed as scope rather than a citation: third-party risk, change management and software supply-chain governance are obligations across GCC rulebooks, and a skill that runs code and is adopted outside your dependency process is a supply-chain exposure those rules already govern, even though they pictured a library in a manifest rather than a folder the agent reads and executes. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
Agent skills are a genuinely good pattern. Progressive disclosure is the right answer to the tool-crowding problem, and organising capabilities as folders is clean and scalable. Nothing here says avoid skills.
The point is what a skill actually is. It is not a config entry. It is code the agent will run and a document the agent will obey, chosen by a description the agent trusts. Review both halves like the dependency they are, sandbox the code like the last two posts insisted, and never let a one-line description be the only thing standing between your agent and someone else's code.