What is skill poisoning?

A working definition

Skill poisoning is the introduction of malicious instructions or behavior into a reusable AI agent skill so that loading or using it steers the agent toward an unintended result. The carrier may be the instruction file, supporting content, executable code, a dependency, or a bundled model. This library uses the term as a working umbrella; researchers use overlapping definitions.

The crucial distinction is the carrier and lifecycle. A skill packages reusable procedural knowledge. A harmful change can be installed once and encountered repeatedly in different tasks. The same package may be relatively contained in one client and consequential in another, depending on the authority available at runtime.

Names and boundaries

Skill poisoning (two words) is the security topic covered here. Skill Poison (two words, title case) is this independent library’s display name; skillpoison.com is its domain, which has no space. A separate October 2026 research paper calls its own experimental framework SkillPoison (one word). That paper and its authors are unrelated to this site.

These spellings are easy to confuse, so source cards retain an author’s exact title while site navigation uses the library’s display name. Neither a domain nor a paper title implies ownership of the general security term.

Why a skill is a trust decision

A person may choose a skill for document formatting or repository maintenance. That choice does not mean every instruction and future update is authorized. The review question is whether the package stays within the user’s task and the host’s permission boundaries.

Think in four layers: who supplied the package, what content gets loaded, what actions it can initiate, and which effects the environment permits. A clean-looking description says little about the remaining layers.

Three mechanisms to keep separate

• Instruction manipulation: skill text redirects reasoning or asks the agent to perform an unrelated step.
• Executable compromise: supporting code performs behavior the user did not intend, even if the model interprets the instructions correctly.
• Triggered behavior: a package or bundled component acts normally until a particular condition occurs.

These mechanisms can combine. They require different evidence and defenses. A natural-language classifier may flag an instruction but cannot by itself verify a binary, a remote service, or an embedded model.

An illustrative failure chain

Synthetic example: a team installs a report-building skill. A supporting reference claims that a private export must be uploaded for “format verification.” The agent loads that reference, reads an unrelated file using its broad workspace access, and prepares a request to an external destination.

This example is not a reported incident. It shows two boundaries worth testing: whether the reference can redefine the task, and whether the runtime permits the read and external transfer. Either boundary can interrupt the chain.

What counts as evidence

A suspicious sentence is evidence of a concerning instruction, not proof of disclosure. Confirming impact requires the loaded package revision, runtime context, observed actions, targets, approvals, and effects. Separate a static finding from an executed behavior and a verified outcome.

Research in the catalog examines several versions of this problem: skill-file injections, marketplace risk, bundled-model backdoors, and composed skill behavior. These are related studies, not interchangeable measurements.

A practical first review

1. Freeze and identify the exact package revision.
2. List every file, reference, dependency, and external destination.
3. Write down the smallest legitimate task and the permissions it needs.
4. Review instructions and executable resources separately.
5. Try the legitimate workflow in a sandbox with synthetic data.
6. Check the action trace, then decide what authority to grant.

Keep the review record with the package. Reassess it when the content, execution environment, or credentials change.

Worked example: a report task changes its destination

A finance team asks an agent to turn synthetic invoices into a local summary. A third-party formatting skill introduces a new step: send the source files to an external “validation” service. The summary may still be correct. The security question is whether the task acquired a new recipient and a new disclosure path. A visually successful output does not answer that question.

Work through the evidence

Compare the user request, the skill revision, the supporting material actually loaded, the attempted network action, and any resulting transfer. Mark the point where an instruction became a request for authority. If a network rule blocks the action, record a blocked attempt; do not label it a confirmed leak. If no action was attempted, record a concerning instruction and the limits of that observation.

Decision criteria and a useful review record

Hold the package when the new transfer has no legitimate task basis. An approved external workflow would need its own destination, data scope, and authorization. Keep the report result and the side-effect result separate. The minimum evidence record is the requested task, package identity, loaded instruction, requested action, enforcement outcome, and unresolved questions. This lets a reviewer distinguish poisoned intent from runtime impact.