Before Your Team Installs an AI Agent Skill: What the OWASP Agentic Skills Top 10 Means for Organisations

A New Kind of Install

Many people first met AI assistants by typing a question and reading the answer. Increasingly, teams work with AI agents: tools that read files, run commands, call services, and complete tasks on their own. To make those agents better at specific work, people add skills.

A skill is a small package of know-how for an agent. In its common form it is a folder with a SKILL.md file: a short description, followed by plain-language instructions telling the agent how to do a particular job. Many skills also carry scripts or reference files. The format was introduced by Anthropic and has since been adopted by several agent platforms. Skills are easy to write, easy to share, and easy to install, often with a single command.

That convenience is the point, and it is also the risk. A skill runs with the permissions of the agent that loads it. If the agent can read your files, use your credentials, or run commands on your machine, so can every skill it has been given. Installing a skill is closer to installing software than to bookmarking a web page, but it rarely gets the same scrutiny.

This is not only a developer concern. Anyone who uses an agent to draft documents, process data, or automate routine work can install a skill, usually without asking anyone. If your organisation uses AI agents, it is worth finding out whether that has already happened. In an earlier article we looked at applications built with AI and what they need before they can grow. This one looks at the tools that build and run them.

What OWASP Published

OWASP, the open community best known for the OWASP Top 10 of web application risks, has a project dedicated to this layer: the OWASP Agentic Skills Top 10. It names ten risks specific to agent skills, from AST01 to AST10, with mitigations for each.

It is worth being precise about its status. At the time of writing the project describes itself as version 1.0, 2026 edition, in public review, with the final 1.0 release planned for the fourth quarter of 2026. Details may still change. The overall shape is already useful, though, because it gives organisations a shared vocabulary for a risk most of them have not yet named.

The ten risks fall into four areas:

• Where skills come from: whether the skill and the place you got it from can be trusted.
• What skills can do once running: the permissions and boundaries around them.
• How skills are managed over time: updates, scanning, and oversight.
• How skills move between tools: what is lost when a skill is reused on another platform.

The Ten Risks in Plain Language

The OWASP document is written for security specialists and marketplace operators. Below is our reading of each risk for an organisation that uses agents rather than builds them, with one step you can take for each.

Where Skills Come From

AST01, Malicious Skills. Some skills are published with harmful intent: they look useful but hide instructions or code that steal credentials or open a way into the machine. What makes skills different from ordinary malicious software is that the harmful part can be written in plain language, as an instruction to the agent, not only as code. Step: install skills only from sources you can identify, and read the instructions, not just the description.

AST02, Supply Chain Compromise. Skill marketplaces are young, and many lack the checks that mature package ecosystems have built up over years. Attackers can upload look-alike skills, take over a publisher's account, or slip changes into a skill that people already trust. Step: prefer skills from publishers with a verifiable identity, and treat a newly published skill with a popular-sounding name with suspicion.

AST04, Insecure Metadata. A skill's description, author, and declared permissions are written by whoever published it. They can claim to come from a well-known brand, or understate what the skill actually does. Step: do not rely on what a skill says about itself. Check what it contains.

What Skills Can Do Once Running

AST03, Over-Privileged Skills. Skills are often given far more access than their job needs, either because the platform has no way to limit it or because users accept every permission prompt. A skill that only needs to read a report should not be able to delete a database. Step: give agents the least access that still lets them work, and keep production credentials out of reach.

AST05, Untrusted External Instructions. Many skills tell the agent to read documentation from a web address at run time. That content effectively becomes part of the skill, but unlike the skill itself it can change at any moment, after anyone has reviewed it. Step: notice when a skill points to outside content, and ask who controls that content.

AST06, Weak Isolation. In many setups, skills run with the same access as the agent: the whole file system, the shell, and the network. Nothing contains a skill that misbehaves. Step: where your tools support it, run agents in a restricted environment or sandbox, especially for experiments with new skills.

How Skills Are Managed Over Time

AST07, Update Drift. Skills are installed and then forgotten. Either fixes are never applied, or updates are applied automatically without anyone checking what changed. Both are risky, because the version that was reviewed is no longer the version that runs. Step: fix skills to a known version and review changes before accepting an update.

AST08, Poor Scanning. Traditional security scanners look for known patterns in code. Skills mix code, metadata, and natural-language instructions, and harmful intent written in plain prose can pass a scanner that only checks code. Step: treat an automated scan as one input, not as approval. A person still needs to read the skill.

AST09, No Governance. In most organisations, skills are installed by individuals with no inventory, no approval, and no way to remove them when someone leaves. The security team cannot see them, which the OWASP project calls a "shadow AI" layer. Step: keep a list of which skills are installed, by whom, and why.

How Skills Move Between Tools

AST10, Cross-Platform Reuse. Skills are increasingly copied from one agent platform to another. Security information that one platform understands, such as declared permissions, may simply be dropped by the next. Step: when a skill is reused in a different tool, review it again as if it were new.

Questions to Ask Before Anyone Installs a Skill

Most of the ten risks can be reduced with a few questions asked at the right moment, before the install rather than after an incident.

1. Who wrote it? Is the publisher a person or organisation you can identify, and is this their real account?
2. What does it actually contain? Has someone read the SKILL.md instructions and any scripts, not only the description?
3. What did the install warning say? Many agent tools show a notice about what a skill or plugin can do when it is installed. Did anyone read it?
4. What can it reach? Which files, commands, credentials, and network access will it have through the agent?
5. Does it fetch anything from outside? If it reads instructions from a web address, who controls that address?
6. How will it be updated? Automatically, or only after someone has reviewed the change?
7. Who approved it? Is there a record that someone responsible agreed to this install?
8. How do we remove it? If the skill misbehaves, or the person who installed it leaves, can it be found and removed quickly?

If nobody can answer these, the skill should wait.

How We Handle Skills at qadrtech

We use AI agents in our own work, and skills are part of that. A few habits shape how we use them.

• We write our own skills for our recurring work. When a task repeats, such as the workflow for writing and publishing these articles, we describe it in a skill we wrote ourselves, so we know exactly what the agent has been told to do.
• Our skills live in version control. They sit in the same repositories as the code they serve, so every change is visible, reviewable, and reversible.
• We review third-party skills before installing them. We read the SKILL.md instructions and any scripts that come with it. A skill we have not read is not installed.
• We start that review with the install warning. Agent tools often show a risk notice when a skill or plugin is installed. It is easy to click past. We read it first, because it summarises what the skill will be able to do and tells us where to look hardest.
• We limit what our agents can do. Agents work with restricted permissions, risky actions need explicit approval, and production credentials are not handed to them.

None of this requires special tooling. It requires treating a skill as software that runs with real access, because that is what it is.

A Minimal Skill Policy for Small Teams

The OWASP project describes controls suited to large enterprises: signed registries, central scanning pipelines, and integration with security monitoring. A small business or a campus IT unit can get most of the protection with a policy that fits on one page.

• Keep an inventory. A shared spreadsheet is enough: skill name, source, version, who installed it, on which machine or agent, and why.
• Require approval. One named person agrees before a new skill is installed on any agent that touches company data.
• Read before installing. The install warning, the instructions, and any scripts. If it is too long to read, it is too large to trust without reading.
• Grant the least access. Agents work in a limited folder or environment, without production credentials, and ask before running risky commands.
• Pin and review updates. Stay on the reviewed version until someone has checked what changed.
• Prefer your own skills for core work. For tasks that touch sensitive data or systems, a short skill written in-house is often safer than a popular one from a marketplace.
• Remove skills at offboarding. When someone leaves, their installed skills and the access behind them are part of the handover.

Review the inventory every few months. Remove what is no longer used.

Closing

Agent skills are useful, and the ability to package know-how for an AI agent will only become more common. The OWASP Agentic Skills Top 10 is a reminder that this convenience comes with the same responsibility as any other software: know where it came from, know what it can reach, and know who approved it.

If your team is starting to use AI agents and you would like help setting sensible boundaries, from reviewing the skills you already have to writing the ones you need, get in touch. We will start with what your team is already using.