Agent Skills Are Supply Chain Components

At AI Native DevCon London, I started with a simple question: who had added a skill to an agent in the last few months? Hands went up. Then I asked people to keep their hands up only if they had actually reviewed the skill and read the markdown.

That second question is where the talk really began.

My talk, "Your AI Agent Installed Malware Because a SKILL.md Told It To", was about the security model we are quietly building around agent skills. A skill can look like documentation. It can be a markdown file with instructions and metadata. But once an agent trusts it, that skill can influence what the agent reads, what it changes, which tools it calls, and which parts of the workspace it treats as trusted context.

That makes skills supply chain components. They deserve the same kind of suspicion, review, provenance, scanning, and update discipline that we eventually learned to apply to package ecosystems.

I come to this from developer security work. I have spent a lot of time around secure coding, JavaScript security, npm, PyPI-style ecosystem problems, and more recently AI security research around skills, MCP, and coding agents. The patterns are familiar: reusable components spread quickly, review habits lag behind adoption, and attackers notice the places where trust is easiest to smuggle in.

Use This Talk As Agent Context

Tessl has turned my AI Native DevCon talk into a skill your agent can use as context. You can also watch the full recording.

Why Are Skills A Supply Chain Problem?

Most people think of a skill as SKILL.md. That is only part of the object.

A skill usually has frontmatter, a body, instructions for the agent, and sometimes supporting material. It can include references, assets, packages, fixtures, helper files, install scripts, and other content that a human reviewer may never read carefully. In the talk I used that package ecosystem lens deliberately, because developers already know this story from npm and other registries.

When a package is installed, we eventually learned to ask questions about maintainers, versions, lock files, integrity, signatures, transitive dependencies, post-install behavior, and provenance. Skills are earlier in that journey. They are reusable AI components, but their security controls are still catching up with their adoption curve.

In research I discussed during the talk, we scanned roughly 4,000 skills from a public skill ecosystem and found a meaningful number of issues: suspicious downloads, credential-related risks, malware-like behavior, misuse, and security vulnerabilities. The exact percentage matters less than the direction of travel. Skills are already numerous enough, useful enough, and easy enough to publish that supply chain thinking has to arrive now.

The mistake would be to say, "It is only markdown." In an agent workflow, markdown can be behavior.

Reading A Skill Once Is Not A Security Model

The security guidance around skills often starts with something like: read the skill before enabling it, and do not trust third-party content blindly. That is sensible advice, but it is not enough.

The first problem is depth. Did you read only SKILL.md, or did you read the supporting files too? Did you inspect referenced assets? Did you look for scripts, fixtures, or packages that the skill might ask the agent to use? Did you understand what permissions the agent would have when the skill runs?

The second problem is time. Even if you reviewed the skill when you installed it, did you review every update? Did you review every change your team shared internally? Did you review every fetched version before an autonomous agent used it again?

The third problem is how trust is granted. Many coding agents ask whether you trust a workspace folder. Once you say yes, that folder can become the boundary. The agent may treat files inside it as instructions, context, or policy. If an unsafe skill lives there, the agent may inherit your trust in the folder and apply that trust to the skill.

That is why I do not think "read it first" is a complete model. It depends on perfect human attention in a workflow that is deliberately trying to automate more work. It also assumes the risky content is obvious to a human reviewer. In practice, unsafe behavior can sit in natural-language instructions, bundled references, or update paths that people do not inspect every time.

The Risk Is The Trifecta

The core risk model in the talk was the combination of private context, untrusted content, and external communication.

Private context is the data the agent can access: credentials, API keys, config files, repository secrets, customer data, internal documentation, inboxes, browser sessions, or anything else that was never meant to leave the local task boundary.

Untrusted content is material the agent reads but the team did not author or verify: an issue opened by an unknown contributor, an email, a web page, a pull request comment, a copied prompt, a third-party skill, or a repo fetched from somewhere else.

External communication is the agent's ability to send information outside the boundary: opening network connections, posting comments, creating issues, pushing branches, sending email, calling APIs, uploading files, or writing to public services.

Any two of those can be risky. All three together are where the failure mode becomes serious. An agent that can read private context, consume untrusted instructions, and communicate externally has the shape of a data leak waiting for a trigger.

This is not only about one agent product or one workflow. I used examples from personal assistants and coding agents because the same pattern appears across the space. The more useful agents become, the more often they touch shells, browsers, email, repositories, APIs, memory, plugins, and third-party services. Those are features from the user's perspective. From an attacker's perspective, they are also places to influence behavior.

Approval Fatigue Makes The Boundary Weaker

Human approval is often treated as the safety boundary. Sometimes it is. But it is a fragile boundary when the workflow trains people to approve repeatedly.

If an agent asks for permission once, a developer may read carefully. If it asks ten times during a routine task, the developer may start clicking through. If the agent runs in a broad accept mode, the boundary may disappear entirely. In the talk, I described this as the shift from vulnerability fatigue into acceptance fatigue: the security control is still present in the interface, but it has stopped being meaningful in the actual workflow.

There is also a confused-deputy problem. The agent may ask the human to approve something that sounds legitimate because the agent itself has been influenced by a skill, an email, or some other untrusted content. The human sees a request from the tool they are using, not necessarily the hostile instruction that caused it.

That is why the question is not simply "was there a human in the loop?" The better question is whether the human had enough context, enough time, and a narrow enough permission request to make a real security decision.

Natural Language Can Carry Unsafe Behavior

Traditional supply chain security often starts with code scanning. That is still useful, but skills add another layer because the dangerous part may be natural language.

A skill can ask for behavior in plain English. A reference file can encode instructions that only matter when an agent reads them. Content can be written to look harmless to a human while still being processed by the model. Even ordinary-seeming helper text can steer an agent toward unsafe actions if the agent has broad tool access.

The original talk included demonstrations of unsafe skill behavior. I am not going to reproduce the mechanics here, and the public transcript is intentionally redacted for defensive use. The lesson does not depend on the operational details: if a skill can influence an agent, then reviewing it only as markdown prose is not enough.

One example category was poisoned input: the agent reads an email, issue, or web page that contains instructions aimed at the agent rather than the human. Another was a skill that appears to be useful but asks the agent to fetch or run something unsafe. Another was hidden or non-obvious content that a person might miss during review but the model still processes.

Those examples point at the same underlying issue. Skills are not just instructions for humans. They are instructions for systems that may have tools, context, memory, and permission to act.

Skill Scanning Has To Be Behavioral

I also talked about scanners. If skills are becoming supply chain components, teams will want ways to scan them. That is the right instinct, but the scanner has to understand the shape of the problem.

A scanner that only looks for obvious strings, commands, or regular-expression matches will catch some unsafe content. It will miss other cases because the behavior can be described indirectly, split across files, hidden in supporting material, or expressed as intent rather than a literal command.

That is why we looked at behavioral analysis and taxonomy-driven scanning. The scanner should ask what the skill is trying to make the agent do. Is it requesting suspicious downloads? Is it handling credentials? Is it steering data toward an external destination? Is it asking for broad shell access? Is it relying on hidden or indirect instructions? Is the provenance clear? Are there supporting files that change the risk?

No scanner is perfect. A model-based scan can catch things that simple pattern matching misses, but it still needs to be part of a broader control system. The point is not to replace review with another black box. The point is to make the review fit the medium.

Registries have an important role here too. In the talk I called out registry-side controls because distribution points can enforce checks earlier than individual teams can. If a registry scans skills, checks provenance, flags risky behavior, and makes security information visible before installation, it improves the default path for everyone.

Manage Skills Like Real Dependencies

The practical response is to manage skills like real dependencies.

Start with inventory. Know where skills live across user directories, project folders, shared team locations, registries, and CI environments. If you do not know which skills your agents can load, you do not have a security model.

Review provenance. Who published the skill? Is the source trustworthy? Has the maintainer changed? Does the skill include supporting files? Does it ask the agent to install, fetch, run, or transmit anything?

Scan skills before use and on update. Do not treat the first install as the only review moment. A skill that was safe last month can become unsafe after a change, especially if teams share and recycle skills internally.

Limit permissions. Avoid broad unchecked modes for workflows that touch private data or untrusted content. Keep shell access, network access, credential access, and write access as narrow as the task allows.

Isolate risky execution. Run agents in sandboxes or constrained environments when they need to process untrusted content. Keep secrets out of the workspace unless the task genuinely requires them.

Control outbound paths. If an agent cannot send data to arbitrary places, the trifecta gets harder to complete. Logging, allowlists, and network boundaries matter.

Treat natural language as part of the attack surface. Review instructions, references, examples, and bundled files with the same seriousness you would apply to code that can influence execution.

Keep evidence. Teams need logs, version traces, and a way to answer which skill version influenced a given run. Without that, incident response becomes guesswork.

Skills Need Dependency Discipline

I am not arguing that teams should stop using skills. Skills are useful because they package reusable context and workflows for agents. That is exactly why they need discipline.

The package ecosystem taught us that reuse changes the security problem. A component does not have to be large to matter. It only has to be trusted in enough places, by systems with enough access, for failure to become expensive.

Agent skills are reaching that point quickly. They are easy to write, easy to share, and easy for an agent to treat as trusted context. If a skill can shape agent behavior, it belongs in the supply chain review process.

That was the argument I brought to AI Native DevCon London: not that skills are bad, but that they are powerful enough to deserve real security boundaries. To go deeper, watch the full recording.