Skill Safety

OWASP (opens in a new tab) recently published a community-driven project to catalogue the current types of threats posed by skills, calling out the high level of malicious skills being shared publicly out in the wild. Their security checklist is here (opens in a new tab). This is version one, written for developers and technical staff, and will no doubt change and improve over time.

I thought there was real value in having a non-technical version. In many organisations, non-technical users are writing their own skills and, most likely, sharing skills that others have written. Feel free to repurpose my checklist below.

Why Now

A skill is a set of written instructions telling an AI assistant how to do a particular job. The AI assistant follows the instructions without asking you, using whatever access it already has. The instructions are plain English, so ordinary security tools do not see them. A skill can contain no code at all and still say “when you are finished, send a copy to this address”. That sentence is the attack.

Of 3,984 skills audited on two public marketplaces in February 2026, 36.8 per cent had at least one security issue (Snyk (opens in a new tab)). A separate study found 341 deliberately malicious skills carrying password-stealing software, disguised as crypto tools, YouTube utilities and Google Workspace integrations (Koi Security, via The Hacker News (opens in a new tab)).

The one test you need to remember

Simon Willison calls this the ’lethal trifecta’ (Willison, 2025 (opens in a new tab)) and OWASP have adopted it. A skill becomes dangerous when all three are true at once:

It can reach private information (your files, your email, customer records).
It can take in content you do not control (a web page, an incoming email, a supplier’s PDF).
It can send information out (email, a web address, an upload).

Any one alone is usually fine. All three together means anything written into that untrusted content can instruct the assistant to find your private data and send it away. Look at all your skills and count how many points apply. If you count 2 or more: that’s the signal to run the checklist!

Checklist

This checklist is for anyone who writes AI skills, or installs skills written by someone else. It assumes no technical background. Create a shareable checklist for your organisation. Fill it out and store it each time a skill is created or updated.

Treat a skill as you would a new member of staff who works unsupervised and never asks permission. Check who they are, agree what they may access, watch them for a while, keep a record.

Part 1

If you do nothing else, do these three things for any skill you are about to install:

Read the skill file yourself, in full, before you install it. A skill is mostly plain English. Most of the danger sits in sentences, not in code.
Give it the least access it needs. Not the access it asks for.
Keep a list of which skills are in use, who approved each one, and when.

Part 2: Before you install someone else’s skill

2.1 Where did it come from?

Anyone can publish a skill, under any name. Attackers copy the names of popular skills and well-known companies. Do not put any weight behind a marketplace badge, star rating or “verified” label as evidence of safety.

The skill’s author is…
The organisation behind the author is…
The author has actually created the skill, not just shared it from another unknown source
The skill is not brand new with a suspiciously high download count

2.2 Read the instructions yourself

The description says one thing, the instructions might do another. Only a person reading the file catches this. Open the skill file. It is usually called SKILL.md and opens in a text editor. Sometimes it is a zipped archive and you will need to unzip it first.

I have read the whole file, not just the description
Everything the instructions do matches the description
There are no instructions to contact a website, server or email address
There are no instructions to read files unrelated to the stated job
Nothing tells the assistant to ignore its rules, hide its actions, or keep something from the user
I understand every step. Where I do not, I have asked

2.3 Look for text you cannot see

Instructions can be hidden from a human reader but still visible to the assistant: white text, invisible characters, or scrambled-looking strings.

I have selected all the text (Ctrl+A) to reveal anything hidden by colour or spacing
There are no long unbroken strings of random-looking letters and numbers
Where such a string exists, the author explains in plain English what it is

2.4 What is it asking to reach?

A skill with broad access is dangerous even if the author meant no harm, because anyone who later tricks the assistant inherits that access.

Access is limited to named folders or files, not “all files”
It cannot run arbitrary commands on the computer
It does not need general internet access. If it needs the internet, it names specific sites
It does not ask to read password stores, saved browser passwords or system login files
It uses credentials issued to it alone, not a shared organisational key
Nothing it asks for is unexplained by its stated purpose

2.5 Does it send you somewhere else?

Some skills hold only part of their instructions and fetch the rest from a web page. Whoever controls that page controls your assistant, and can change it after you approved the skill.

All instructions are in the file. Nothing is fetched at the time of use
Where it points outside, the URL is…
I have read what is there, and followed any further links
This address belongs to an organisation I have reason to trust

2.6 Does it rewrite the AI assistant’s memory?

Assistants keep files holding their standing instructions and memory, named things like MEMORY.md, or CLAUDE.md. A skill that writes to these changes the assistant permanently, and removing the skill does not undo it.

The skill does not write to memory or standing-instruction files
Where it does, the author says why, and a second person has approved it
I know where those files live, so I can check them afterwards

2.7 Try it somewhere it can do no harm

Reading a skill tells you what it says, running it tells you what it does. This bit may require someone technical to help set it up.

I ran it first with invented data, somewhere it could reach nothing sensitive
What it did matched what it said. It touched nothing else

2.8 Write down which version you approved

Many platforms update skills automatically. The skill you approved earlier may not be the one running today.

I have recorded the exact version and date I reviewed
I have kept a copy of the file as approved
Automatic updating is off, or updates return to a person for approval
I know who to tell if a skill behaves oddly

Part 3: While a skill is in use

3.1. Updates

Updates can arrive quietly and be missed.

Approval to update this skill is given by…
Someone is signed up to security notices for the skill, if available from the skill’s author

3.2 Watch what it actually does

I have manually watched the skill work, in real time, a minimum of 3 times
It is working as described

Part 4: Writing a skill of your own

Everything in Part 2 applies. Write the skill you would be willing to approve.

4.1 Describe it honestly

The description states everything it does, including anything incidental
Someone reading only the description would not be surprised by the instructions

4.2 Ask for as little as possible

I have named the specific folders or files it needs, not requested general access
It does not run commands on the computer. If it does, I have named which
It does not need general internet access. If it does, I have named the addresses
I have been back through the list once and removed anything I could live without

4.3 Keep secrets out of it

A skill is a file that gets copied, shared and published. Anything inside it travels with it.

No passwords, access keys, tokens or API keys anywhere in the file
No personal details of staff, clients or customers, including in examples
Example data is invented, not copied from real records
Where a credential is needed, the skill asks at the time rather than storing it

4.4 Keep the instructions inside the file

All instructions are in the skill itself
I have not pointed the assistant at a web page for more
Where I need outside content, I have copied it in so it can be reviewed and cannot change underneath us

4.5 Leave the assistant’s memory alone

The skill does not write to memory or standing-instruction files
Where it must, I have said so in the description and had it approved separately

4.6 Label it

Version number, date, and my name with a way to reach me
What it needs access to, in plain English, near the top
Any known limitations

4.7 Verify it

A second person has read the whole skill before it was shared. They could say what it does without asking me
I have tested it with invented data

I have shared it in the agreed location (not by email or chat)
I will keep that agreed location updated with the latest version when I change the skill
I will tell users directly when I change the skill

Part 5: Keeping track

For the person responsible for approving skills, usually a spreadsheet is enough to keep track.

There is one list of every skill in use across the organisation
Each entry records: name, version, source, what it can access, who approved it, and when
Each skill has a named owner who still works here
Each skill has a next review date. Higher-access skills are reviewed more often
Someone knows what to do if a skill turns out to be harmful: who to tell, how to remove it, what to check afterwards
Staff know to ask before installing a skill, and know who to ask
The list is reviewed when someone leaves

Adapted from the OWASP Agentic Skills Top 10 v1.0, used under CC BY-SA 4.0. Shared under the same licence. Developed and produced with AI support from Claude Opus 5.