On this page
  1. What makes an agent skill risky?
  2. What should you look for in the SKILL.md body?
  3. How do you check the scripts?
  4. How do you install a skill safely?
  5. Where AI coding assistants get this wrong
  6. Checklist
  7. FAQ
    1. Are skills from a registry safe?
    2. Can a skill exfiltrate data without a script?
    3. Should I run skills in a sandbox?
    4. How do I review a skill change later?
  8. Related topics
  9. Sources
tutorial

How to Audit an Agent Skill Before You Install It

Read what the skill tells the agent to run: download-and-execute steps, broad file reads, permission changes, and hidden network calls.

Quick answer

  • A skill is instructions your agent obeys with your credentials, so audit it as executable content rather than documentation.
  • Read the SKILL.md body first, looking for commands that download and execute code, disable permission prompts, or read whole secret files.
  • Then read every script in the folder and check what it writes, deletes, and sends over the network.
  • Check the frontmatter and folder name for a mismatch, which is a sign the folder was renamed after the content was written.
  • Install into a project directory, run it once on a scratch branch, and keep it in version control so changes are reviewable.

What makes an agent skill risky?

The agent will follow the instructions in a SKILL.md. If the file says to run a shell command, the agent runs it, with access to your working tree, your environment variables, and anything your credentials can reach. A skill is therefore code execution with a friendly filename.

The risk is not hypothetical for skills that wrap installers or setup steps. A one-line instruction to fetch and pipe a script into a shell is enough, and it is easy to miss in a file that mostly discusses formatting conventions.

What should you look for in the SKILL.md body?

Start with commands that fetch and execute: curl piped into sh, wget followed by chmod, npm install from a URL, or a request to run an unpinned tool. Then look for instructions to broaden access: disabling approval prompts, adding credentials to the environment, or granting a tool the skill does not need.

Next, look for data access that is wider than the task. Reading an entire .env file when one variable would do, listing a home directory, or copying a whole repository to a temporary location are all patterns that turn a formatting skill into an exfiltration path.

# Review what a skill contains before installing it
find ./skill-folder -type f -maxdepth 3 | sort
sed -n '1,120p' ./skill-folder/SKILL.md
# Look for the patterns that matter
grep -RInE 'curl|wget|bash -c|sh -c|eval|chmod|sudo|.env|AWS_|TOKEN|SECRET|rm -rf' ./skill-folder

How do you check the scripts?

Read them. Look for outbound requests, writes outside the working directory, credential reads, and anything that runs at import rather than on an explicit command. A script that is only called by a step in the SKILL.md is easier to reason about than one that runs on load.

If the scripts are minified or binary, treat that as a refusal. A skill needs to be readable by the person approving it; obfuscation is incompatible with review.

How do you install a skill safely?

Put it in a project directory, commit it, and run it once on a scratch branch with a token that can be revoked. Watch what it touches. If the skill needs credentials, give it a scoped token rather than a personal one, and rotate after testing.

Then keep it pinned. Skills change, and a registry entry that silently updates is a supply chain you did not review. Copy the reviewed version into the repository rather than referencing a moving target.

Where this bites vibecoders

The most common inherited risk is a skill that was generated to “set up the environment” and includes a download-and-execute step nobody read, because the file is 90 percent markdown explanation. Read the commands, not the prose, and assume the agent will run every one of them.

Where AI coding assistants get this wrong

  • Approving a skill because the description sounds useful.
  • Missing a curl-to-shell step buried in a setup section.
  • Installing a skill that tells the agent to skip permission prompts.
  • Letting a skill read the whole environment file instead of one variable.
  • Referencing a registry entry that updates without review.
  • Testing a new skill against a production credential instead of a scoped one.

Checklist

  • List every file in the skill folder.
  • Read the SKILL.md body end to end, not just the description.
  • Grep for download, execute, credential, and delete patterns.
  • Read every script, and refuse obfuscated ones.
  • Test on a scratch branch with a revocable token.
  • Commit the reviewed copy and pin it.

FAQ

Are skills from a registry safe?

A registry can curate and rank, but it cannot take responsibility for what a skill tells your agent to run with your credentials. Treat installation as a code review, regardless of source. Popularity measures attention, not safety.

Can a skill exfiltrate data without a script?

Yes. The instructions can tell the agent to send data through a tool it already has, such as posting a file to an external service or including content in a message. That is why the body needs reading, not just the files in the folder.

Should I run skills in a sandbox?

Ideally yes, especially for unfamiliar skills. A container or disposable workspace limits what a surprise command can reach. Sandboxing does not replace reading the skill, because the agent can still leak data through allowed network paths.

How do I review a skill change later?

Keep the skill in version control and review diffs like code. Pay attention to new commands, new file reads, and changes to the description that broaden when the skill loads. A widened trigger is a functional change even if the steps look the same.

Sources

Share: