The honest answer
Agent skills are as safe as what you choose to install. A skill is instructions and files that become part of how your agent behaves, so installing one is a trust decision much like adding a dependency to your project. The good news is that, unlike a compiled binary, a skill is plain text you can read in full before you commit to it. That transparency is your strongest protection — if you use it.
Where the risk comes from
Most of the risk in a skill clusters around three areas, and they are worth naming clearly.
The first is scripts. A skill may ship helper code that the agent runs. Code can do anything the agent's environment permits — read files, delete them, make requests. A script you cannot read or understand is a risk you cannot assess.
The second is network access. A skill might instruct the agent to send data to an external endpoint or pull instructions from one. Where does that data go, and what comes back? Outbound calls deserve a clear explanation.
The third is credentials. Any skill that asks for, reads, or passes along tokens, keys, or passwords is handling your most sensitive material. Treat that with care.
The one habit that matters most
Read the source before you install. This single habit prevents the large majority of problems. Open the SKILL.md and any supporting files on GitHub and walk through them. Ask:
- Do I understand every step this skill tells the agent to take?
- Does it run any script, and can I read that script?
- Does it make network calls, and to where?
- Does it touch any credentials?
If you cannot answer those questions, or the skill does something you do not understand, do not install it. "I'll figure it out later" is how unsafe code gets in. A skill you cannot follow is a skill you cannot trust.
Sensible precautions
Beyond reading the source, a few habits keep you safe:
- Prefer focused skills. A skill that does one clear thing is easier to vet than a sprawling one.
- Favor skills you can trace to a reputable source and an open repository.
- Try a new skill on a small, low-stakes task first and watch what it actually does.
- Keep skills in version control so any change is visible and reversible.
- Re-read a skill after editing it, so your mental model stays accurate.
These are the same instincts you would apply to any dependency, and they map directly onto the risk dimension in how to evaluate agent skills.
Curation helps, but does not replace judgment
A maintained directory can make sources and compatibility easier to compare. Browsing the Skills directory or a category is a sensible starting point. But a listing is not a safety guarantee. The final check is always yours: read the SKILL.md, understand it, then decide.
The blunt rule worth remembering
If there is one line to carry away, it is this: do not install a skill you do not understand. The convenience of a one-line install command can tempt you to skip the read, especially for a skill that promises to save time. Resist that. The minute you save by skipping the source is nothing against the cost of giving an agent instructions you never inspected. When in doubt, leave it out.
Why transparency is your advantage
It is worth appreciating how much the format works in your favor. Many software supply-chain risks come from code you cannot easily see. Skills are the opposite: the entire payload is human-readable text and files. There is no compilation step hiding behavior, no binary to reverse-engineer. Everything the skill will tell your agent to do is right there for you to read. This does not make skills automatically safe — but it does mean that, unlike most dependencies, you have the full picture available before you commit. Safety with skills is mostly a matter of using the visibility you already have.