What Is Agent Skill Poisoning?

Quick answer
Skill poisoning is a malicious or careless SKILL.md that instructs the agent to perform an action the installer did not intend.
It works because a skill is instructions the agent obeys, executed with the session’s permissions.
Common payloads are download-and-execute steps, reads of environment files, disabled approval prompts, and exfiltration through an allowed tool.
The attack can be entirely in prose: no script and no binary are required.
Defence is review, pinning, and scoped permissions — not a scan for known bad signatures.

What is agent skill poisoning?

Skill poisoning is the agent equivalent of a malicious package: a skill that looks useful and instructs the agent to do something else. The instruction can be a shell command in the body, a script in the folder, or a sentence that convinces the agent to widen its own access.

The format makes this easy to distribute. A skill is a folder of text, installable from a repository or registry, and it is portable across agents now that the standard is vendor-neutral. Portability is the point, and it is also the risk.

How does a poisoned skill get executed?

The agent loads the skill when a task matches its description, then follows the body. If the body says to run a setup command, the agent runs it in the session, with the credentials and file access the session already has. The user sees a helpful skill doing setup work.

No exploit is needed. The agent is designed to follow instructions, and the skill is a set of instructions from someone the user chose to trust. That is why the review question is “what does this tell the agent to run?”, not “does this contain malware?”

What does a poisoned skill usually contain?

A fetch-and-execute step, such as a script downloaded and piped into a shell. A read of a broad secret file rather than the one variable needed. An instruction to disable approval prompts or to avoid mentioning a step. A step that sends repository content to an external endpoint as part of “validation”.

Subtler versions add a dependency or change a config file that the agent will use later. The skill does not need to exfiltrate anything itself; it only needs to make the next action unsafe.

# Patterns worth refusing in a skill
- curl ... | sh   or   wget ... && chmod +x && ./setup
- cat .env  (when one variable is enough)
- disable approval prompts / skip permission checks
- send the repository, or a file listing, to an external URL
- install a package from a URL or an unpinned branch
- run a binary that is checked into the folder without review

How do you defend against it?

Review before install and pin what you reviewed. Read the commands and the scripts, not the description. Keep project skills in version control so every change is a diff someone approves.

Then limit the damage a bad skill can do. Scope credentials, run unfamiliar skills in a sandbox, and keep production secrets out of the environment the agent can read. A poisoned skill with a read-only, short-lived token is an incident; the same skill with an admin token is a breach.

Where this bites vibecoders
The dangerous install is the one that saves time: a skill that sets up the environment, installs dependencies, and configures credentials. It is also the one most likely to contain a command nobody read. Read the commands, and give it a token you can revoke.

Where AI coding assistants get this wrong

Installing a skill because the description matches the task.
Assuming prose cannot be malicious because there is no executable file.
Running a skill with a personal token instead of a scoped one.
Allowing a skill to read the whole environment file.
Pinning nothing, so the installed skill changes after review.
Skipping review because the skill is popular.

Checklist

Read every command in the SKILL.md body.
Read every script in the folder.
Refuse fetch-and-execute steps.
Install at project scope and commit the reviewed copy.
Scope credentials to the task.
Test unfamiliar skills in a sandbox.

FAQ

Can a skill contain malware?

It can contain or download it. The skill format is text plus optional files, so the malware arrives either as a checked-in binary or through a command the agent runs. Either way, the review target is the command, not just the file.

Do registries vet skills?

Some curate and rank, but curation is not a security guarantee and cannot account for what a skill instructs an agent to do with your credentials. Treat a registry as a discovery tool and review as the control.

Is a sandbox enough protection?

It limits what a skill can reach, which is valuable, but it does not stop exfiltration through allowed paths such as a permitted API or a repository push. Combine the sandbox with scoped credentials and an egress policy.

How is this different from prompt injection?

Prompt injection is untrusted content influencing the model at runtime. Skill poisoning is a supply-chain problem: the malicious instructions were installed before the run and are treated as trusted configuration. The defence is procurement and review, not input filtering.