How to Vet an AI Agent Skill Before You Install It

Agent skills have become the easiest way to teach a coding or operations agent a new procedure. A skill is a folder with a SKILL.md file and, optionally, scripts, reference documents, and templates. Drop it into the right directory and your agent will load it when a task matches its description.

That convenience is also the risk. A skill tells an agent what to do, and the agent does it with the access you have already given it: your files, your terminal, your connected services. Vetting a skill before installing it takes a few minutes. Skipping that step means trusting a stranger's instructions with your permissions.

01 // Know what a skill can actually do

The Agent Skills specification defines a skill as a directory containing, at minimum, a SKILL.md file with YAML frontmatter and Markdown instructions. Two frontmatter fields are required: a name and a description that tells the agent when to use it. Optional directories can hold executable scripts/, references/, and assets/.

Agents load skills progressively. The name and description are read up front so the agent can decide whether a skill applies. The full instructions, and any files they reference, are read only when the skill is used. That design keeps context small, but it means the parts you need to review are often not the parts you see first.

Anthropic's documentation is direct about the trust model: use skills only from trusted sources, and audit every bundled file before using one from an unknown source, because a malicious skill can direct the agent to use tools in ways that do not match its stated purpose.

02 // Read the description as a trigger

The description field decides when the skill runs. A broad description such as "use for any coding task" means the instructions will be loaded far more often than you expect, including in sessions that have nothing to do with the skill's stated purpose.

Check that the description:

• names a specific task and the situations that should trigger it;
• does not claim authority over unrelated work or tell the agent to always load it; and
• matches what the body actually does.

A mismatch between the description and the instructions is the first thing to treat as a warning.

03 // Read every instruction the agent will follow

Read the full SKILL.md body and every file it references. You are looking for instructions that extend what the agent does beyond the stated task. Common problems include:

• telling the agent to ignore or override your existing rules or safety instructions;
• fetching and following remote content at run time, which lets someone change the skill's behaviour after you reviewed it;
• sending files, environment variables, or conversation content to an external URL;
• installing packages, editing shell profiles, or adding persistent configuration; and
• hidden text, encoded strings, or instructions buried in reference files.

The OWASP Agentic Security Initiative documents why these patterns matter: agents that act with real tool access can be steered by the content they read. A skill is content the agent has been told to trust, which makes it a privileged place for a bad instruction to sit.

04 // Inspect bundled scripts like any other code

If the skill ships scripts, review them as you would a dependency pull request. Check what each script reads, writes, and sends over the network. Prefer scripts that are short enough to read in full and that use the standard library or well-known packages. Be wary of minified code, binaries, or scripts that download and run something else.

Also check the experimental allowed-tools field if it is present. It lists tools the skill expects to use without asking. Pre-approving shell or network access for a skill you have not read is the same as pre-approving whatever the skill says to do.

05 // Test on safe inputs, then pin the version

Run a new skill first in a disposable workspace with sample data and no production credentials. Watch which files it reads, which commands it runs, and whether it tries to reach the network. Give it an input containing an instruction aimed at the agent and confirm the skill treats it as data.

Once a skill passes review, pin it. Record the source repository and commit so an upstream change cannot silently replace what you approved. Re-review on every update, the same way you would for a dependency. Approval belongs to the exact version you read, not to the repository name.

06 // Keep skills small and inspectable

The safest skills do one job and can be read in a couple of minutes. They state their boundaries, say what they will not do, and leave consequential actions to the person running them. That is how we write ours. The Vertical Labs skills library publishes each skill in full before you download it, with inputs, a worked example, checks, and limitations. The evidence check and agent handoff skills are both short enough to vet in one sitting.

For teams running several agents, the Agent OS guide covers how we handle shared instructions, authorization boundaries, and recovery. If you want help setting up a reviewed skill library and usage rules for your team, that is part of our AI enablement work.

Install a skill the way you would merge code: after someone has read it.