OWASP Goes Agentic: Securing the Skills Your AI Agents Run

I install skills into my AI agents the way I used to install npm packages: find one that does the job, skim it, add it. A skill looks harmless. It is usually a folder with a markdown file and maybe a few scripts. But that markdown is read by an agent that can touch my filesystem, my shell, and my AWS credentials, which makes it closer to executable code than to documentation. OWASP has now put a proper risk framework around exactly this, and it deserves more attention than it is getting.

The OWASP GenAI Security Project#

Most people know OWASP for the classic web application Top 10. The OWASP GenAI Security Project is the same idea applied to AI: a community-driven project producing free guidance for securing LLM applications. Its core deliverable is the LLM Top 10 for 2025, covering risks like prompt injection, sensitive information disclosure, and excessive agency.¹ I keep working notes on all ten and refer back to them often in client conversations, because they give security teams and AI teams a shared vocabulary that was missing two years ago.

From chatbots to agents#

The interesting shift is that the project no longer stops at the model. Its Agentic App Security Initiative now maintains a Top 10 for Agentic Applications and a yearly report on the state of agentic AI security.² The reasoning is simple. A chatbot that generates a bad answer is a quality problem. An agent that acts on a bad instruction can delete files, exfiltrate credentials, or commit code. Once the model has hands, the blast radius changes.

The Agentic Skills Top 10#

The newest piece is the OWASP Agentic Skills Top 10, the first framework I have seen that treats agent skills as their own attack surface.³ It is young and still community-driven; it grew out of the OWASP Project Summit in Oslo, and Ken Huang, who leads OWASP’s AIVSS work, has written a good first-hand account of why the skill layer needed its own framework.⁴ Its central argument: a skill is a bundle of executable code, natural-language instructions, metadata, dependencies, remote content, and runtime permissions. A conventional code scanner sees only part of that. The prose layer can carry an attack just as well as the code layer, because the agent reads the prose and does what it says.

The ten risks (AST-01 through AST-10) map a full lifecycle. Threats enter through malicious skills or a compromised supply chain, expand through excessive permissions and weak isolation, persist through mutable instructions and unverified updates, evade shallow scanners, and spread when a skill moves between platforms and silently loses its security metadata along the way. Malicious skills are not hypothetical either; public skill registries have already dealt with campaigns of them.

I found a solid walkthrough of the whole framework in this 37-minute tutorial from Agentic AI Signal.⁵ It goes risk by risk with concrete mitigations for each, and it is worth the time if you run any agent that loads third-party skills.

The three that changed my behavior#

Over-privileged skills (AST-03). Least privilege has a second question in agent systems: not just what the software can do, but what the model can be persuaded to do with that access. A skill that only needs to format markdown has no business inheriting an agent that can run shell commands against my whole home directory.

Untrusted external instructions (AST-05). A skill you reviewed today can fetch a remote doc, schema, or runbook tomorrow, and that content lands straight in the agent’s instruction stream. The remote file can change after your review, or return different content to a scanner than to a live agent. Mutable prose is a supply-chain dependency and should be pinned like one.

Weak isolation (AST-06). When a skill runs in the host agent’s security context, it inherits filesystem access, network egress, and every credential the agent holds. Sandboxed execution should be the default, and host access the documented exception.

What I actually do now#

Nothing exotic, just discipline. Before installing a skill I read the markdown, not only the code, because the markdown is what the agent executes. I check where it phones home and whether it pulls remote instructions at runtime. I keep credentials scoped, so a skill working in one project cannot see keys from another. And anything that wants to write to agent memory, identity files, or persistent config gets treated as a privileged operation that needs my explicit approval.

We have been through this exact curve before. On npm it was event-stream, a package with millions of downloads that changed maintainers and shipped a backdoor aimed at a bitcoin wallet, undetected for over two months.⁶ On PyPI it was torchtriton, a dependency-confusion attack that compromised PyTorch nightly installs over the 2022 holidays.⁷ In the Chrome Web Store it was The Great Suspender, a beloved extension sold to a new owner who pushed tracking and remote code execution to millions of users through an automatic update, until Google removed it as malware.⁸ Each time, an open ecosystem grew faster than its security model, and a wave of supply-chain incidents forced the tooling to catch up. Skills are earlier on that curve, but agents are far more privileged than a build script or a browser tab ever was. The same protocols that make agents interoperable also make skills portable between platforms, and AST-10 is the warning that security guarantees do not automatically travel with them. Worth getting the habits right now, while the ecosystem is still small enough to change.

References#