A skill looks like a config file and behaves like a dependency

A product security manager at a bank gave a talk this week about scanning two thousand agent skills before letting developers use them. The framing is worth stealing. Skills look like configuration, so people review them like configuration, but they behave like supply chain dependencies. Somebody writes one, shares it, and their instructions are now shaping the code that comes out of your machine.

A skill, plainly, is a folder with a markdown file in it. Frontmatter saying when to use it, then instructions the model reads once the task matches. That is the whole artifact. Which is exactly why it slides past review. Nobody stands up a security process for a text file.

That scan turned up more than fifteen hundred risks across the two thousand skills, they say. Hardcoded token requests that end up in logs. Shell commands doing more than the description implies. Permissions wider than the task needed. Most were remediated, a few were blocked before reaching the internal marketplace. A separate talk the same week argued that skills are becoming the features of agentic products, shipped by anyone in the company who understands the workflow. Put those two together and you have a feature pipeline with no code review in it.

The vault’s own notes on skill engineering have said this for a while. Distribution turns a skill into a supply chain artifact, and the description field is itself an attack surface, since natural language is what decides whether the thing loads at all.

The detail I keep turning over is smaller than any of that. Teams write “ask for confirmation” into a skill and believe they have a human in the loop. Sometimes the model asks itself, answers itself, and continues. From the outside that looks exactly like approval.

You would not install a package off a stranger’s laptop without reading it. A skill is a package. It just does not come with a version number to make you feel like you checked.