A Skill File Can Be a Supply-Chain Attack

A skill file can look like documentation: a title, instructions and a useful recipe for completing a task. When an agent reads that material as guidance for action, however, its provenance matters.

The package may also contain scripts, dependencies or references to remote content. A small, readable entry point can therefore introduce a larger chain of instructions and executable behaviour into the environment.

Treat the package as a dependency

Anthropic’s introduction to Agent Skills explicitly discusses the possibility of malicious skills introducing vulnerabilities, directing data exfiltration or causing unintended actions. The concern is not confined to one product: externally sourced instructions deserve scrutiny wherever agents use them.

A useful skill can legitimately need tools and data. The question is whether its behaviour and access fit the authorised task. A request for broad credentials or an unexplained external destination should prompt examination before adoption.

Review more than the opening file

Check the source and maintainer, the exact version and every bundled script. Follow references to supporting files. Identify dependencies, network destinations and assumptions about available credentials.

Remote references deserve particular attention because their contents can change after a review. Pin or retain reviewed material where practical and reassess updates before allowing them into a sensitive workflow. A familiar package name is not proof that the current contents are unchanged.

This is especially relevant to suppliers whose agents can access customer repositories or support records. The customer’s exposure may expand when the supplier installs a skill, even if no new model provider is introduced.

Constrain what the workflow can do

Start evaluation in an isolated environment using synthetic or otherwise appropriate test data. Restrict filesystem access, network destinations and available credentials to the task. Keep approval for consequential actions outside the untrusted instruction content.

A reviewed skill should still operate within limits that do not depend on its own good behaviour.

Logs and a clear disable mechanism help investigation and containment. Record which version was used for a material action so an incident can be traced to the relevant package rather than a changing description.

Make this part of supplier assurance

Ask whether downloaded skills, plugins and tool packages are inventoried and reviewed. Establish who authorises updates, how bundled scripts are assessed and whether customer environments remain separated.

Do not treat scanning as a guarantee. The aim is to reduce exposure through provenance, review and enforced permissions, then retain enough evidence to investigate failures.

A practical final question is: could an instruction in a downloaded package cause this agent to access or transmit information beyond the task we agreed? If the answer depends entirely on the model refusing, examine the surrounding controls again.

References

• Anthropic: Equipping agents for the real world with Agent Skills. See security considerations. The supplier review approach above is this publication’s practical application of the dependency risk.