I’ve been watching the AI and Agentic AI ecosystem and the various security implications evolve over the last several years.
“Skills” were among one of the most notable examples that caught my attention quickly. For those unfamiliar, skills are essentially modular reusable artifacts that can help extend, or improve the performance of agents. They can be instructions, code, resources or operational insights related to the user, organization etc. Agents can discover, load and execute them, as well as being directly fed them by a user to help improve the agents capabilities and usefulness.
Like agents themselves, it is these very capabilities that make them problematic from the security perspective. I often refer to this as the “Security vs. Utility Tradeoff”, where users/organizations are often trying to balance the two, and the more capabilities an agent is given, the more utility it has for the business, but also the more potential risks and challenges it introduces.
Similar to open source, Skills can be quickly created, distributed and shared widely with the broader community. This has led to the proliferation of Skill hubs and marketplaces. Some of them attempt to vet or score the Skills for security implications and some don’t. Skills were originally introduced by Anthropic but now have become widely adopted.
Some examples include AgentSkillsHub, skillsmp and MCP Market. These marketplaces have thousands and even millions of Skills available for download and use.
It is easy to see why it is helpful to provide information and context to agents to make them more productive and helpful. That said, if you’ve been following my writing, you can also guess that Skills can easily serve as an attack vector to maliciously steer agents behavior, inject harmful context and carry out other nefarious activities.
It didn’t take long for academics and vendors alike to begin to investigate this, and quickly find thousands of examples of malicious Skills in the wild. One of my favorite examples was titled just that, “Agent Skills in thew Wild: An Empirical Study of Vulnerabilities at Scale”.
The team used open source tools and scanned tens of thousands of publicly available skills from the marketplaces and found many examples of malicious skills attempting to exfiltrate data, escalate privileges, execute malicious scripts and other harmful activities. They also provided a useful threat model in the paper, which they walked through and is worth a read.
The risk of skills has become widely known and discussed now, including talks at Black Hat recently by OWASP, Open AI and others and culminated in the publication of OWASP’s v1.0 of the Agentic Skills Top 10, which will be the focus of this article. My friend Ken Huang who helped champion the effort also recently had a great article on it.
I’ll briefly walkthrough the Top 10 risks and their associated mitigations.
AST01 - Malicious Skills
Much like they sound, malicious skills are intentionally malicious skills published to the public, often via the marketplaces I discussed above or by other methods. They are intended to seem legit but often look to steal credentials, establish backdoors or even social engineer users and agents.
The publication points out the problem that agents often utilize excessive permissions, or permissions tied to a user and a malicious skill can lead to exposing credentials such as API keys and SSH credentials.
The team points to real-world incidents such as ClawHavoc, which involved 1,000+ malicious skills, tens of publisher accounts and targeted crypto wallets, SSH keys and browser credentials.
Attack scenarios include examples such as typosquatting, instruction override, memory poisoning and persistence among others.
To prevent impacts from malicious skills, the OWASP team recommended mitigations such as cryptographic signatures of skills, layered scanning at both public and install time, isolated skill execution and auditing skill actions as well as behavior sandboxing, to observe how a skill influences an agents behavior.
AST02 - Supply Chain Compromise
Next up we have supply chain compromise. It’s easy to see how this is a risk given how Skills by their very nature are shared and distributed across the community directly, through repositories and via the marketplaces.
OWASP rightly points out that many of these ecosystems are immature compared to the broader open source ecosystem with platforms such as npm, PyPI and Cargo (which have their own never-ending slew of incidents still).
To capitalize on this, attackers mass upload malicious skills, take advantage of dependency confusion and go after accounts of developers and contributors to poison the registries.
As OWASP points out, all you need to publish a skill on marketplaces/repos such as ClawHub is a SKILL.md file and a GitHub account. Essentially anyone can do it and there’s no security rigor such as code signing, security review, or sandbox by default. These are the sort controls popular OSS platforms have implemented due to a variety of attacks, compromises and social engineering efforts targeting open source users and maintainers in supply chain attacks.
Some of the attack scenarios they point out include flooding registries with malicious skills, poisoning nested dependencies under top-level skills to bypass scanners, hijacking configuration files with malicious execution instructions and the tried and true takeover of a maintainers account to then inject a backdoored version of a trusted skill.
To mitigate some of these attacks, OWASP recommends mitigations such as skill provenance tracking, transparency logs for registry operations, pinning all nested dependencies and applying trust gates to repo config files.
AST03 - Over-Privileged Skills
Least-permissive, not even once.
Everyone’s favorite security challenge enters the fold, as skills are often granted broad permissions beyond what is necessary for their functionality. OWASP points out this is due to there often being no permission manifest system, or users just accepting all permissions without a review.
These overly-permissive skills can be abused to take malicious actions against organizational systems and data.
What makes this problematic to Skills in particular is their natural language format, that uses intent on top of tradition system permissions and methods such as prompt injection which can take advantage of the fact that permission checks occur at the tool call level.
The industry is still widely grappling with “Intent Analysis” when it comes to Agentic AI, and it is a topic I have written about several times. OWASP cites several real-world examples, such as Snyk’s ToxicSkills where hundreds of publicly available skills expose credentials and data beyond the skills declared functions.
They lay out attack scenarios such as data exfiltration, wiping databases, establishing persistent behavioral backdoors and opportunities for low-privilege skills to invoke higher privileged skills, essentially privilege escalation via Skills.
To prevent this, OWASP recommends mitigations such as require skills to declare permission manifests, per-skill scoped credentials, runtime permission enforcement and requiring explicit operator consent for persistent state changes.
It’s easy to see how this would be difficult to do at scale in enterprise environments with thousands of developers leveraging skills and agents at machine speed and scale.
AST04 - Insecure Metadata
Skills come with metadata such as name, description, author, permissions, requires and the native YAML/JSON/Markdown formats they are written in. Attackers can take advantage of this and put attacker-controlled inputs into the metadata which then gets read or executed with no security rigor.
OWASP explains how this can lead to manipulating the metadata to downplay or misinform users on the skills true motives, as well as embed executable payloads that trigger on load before a user takes any action.
What makes it challenging for skills is that malicious definitions can mislead the installer and also execute malicious code before the skill is run due to the fact that the metadata is deserialized during the skill-loading lifecycle as part of initialization.
Some of the attack scenarios OWASP mention include brand impersonation, permission understating, risk tier spoofing and YAML code execution among others. To prevent it, they recommend using safe parsers by default and disabling dangerous tags, validating metadata against a schema prior to deserialization, applying static analysis to all metadata fields as well as validating declared permissions against actual runtime behavior.
AST05 - Untrusted External Instructions
This one reminds me of the core problem of AI and Agents themselves. As we know, consuming untrusted content can lead to models and agents being manipulated and potential impacts for the organizations leveraging them. The best paper on this was Google DeepMind’s “AI Agent Traps”, which described essentially the entire open Internet as a field of potential landmines Agents can consume into the context window and boom, negative things can happen.
In this example for skills, OWASP explains how skills routinely reference external documentation such as API references, SDK guides, schemas and other content that leads agents to URL’s or reading remote files at runtime. That consumed content now becomes part of the agents instructions acted on with the host agent’s full instructions.
OWASP explains how unlike traditional software with versioning, hashing, pinning, lockfiles and signed packages, skills have no pinning to a documents hash, no lockfile, and the fact that signing skills doesn’t mitigate the risks that the URL’s return when executed at runtime.
When I read this, a lot of the risk comes from the fact that agents take action and have autonomy. Those actions and autonomous come with risks and potential for abuse, and embedding malicious instructed externally that get consumed and acted upon is a perfect example of this.
Some of the attack scenarios they cite include author rug pulls, reviewer bait-and-switch, transitive reference chaining and DoS via malicious skills. To mitigate these attacks OWASP recommends techniques such as pinning and verifying referenced content, performing final verifications before model ingestion, preferring inlining over fetching and allow-list specific domains only.
AST06 - Weak Isolation
Every installed skill is a potential full-system compromise due to the fact that sandboxing is often not available, optional or even disabled by default. This limits the ability for containment guarantees per OWASP.
Agents and sandboxes have been a hot topic throughout 2026, and are topics I have discussed with industry leaders such as Alex Zenla and Luke Hinds:
Some of the attack scenarios OWASP lists include host escape, network pivot, skill shadowing, and cross-agent workspace contamination. To prevent these sort of attacks the OWASP authors argue for mitigations such as container isolation for skill execution, binding agent control interfaces to localhost with authentication, applying seccomp/AppArmor profiles and implementing per-skill process isolation.
AST07 - Update Drift
Much like other aspects of cybersecurity, where things are set it and forget it (e.g. permissions), skills are installed and forgotten. OWASP points to a lack of immutable pinning and automated update verification leading to skills drifting from known-good versions due a lack of patches being applied or auto-updates leading to malicious versions.
Unlike traditional software, OWASP points out that skills are often installed by users with no sort of remedy such as traditional patch management and even then, if users did update skills to new versions, the new version itself could be malicious due to unverifiable cryptographic pinning when it comes to skills.
OWASP cites real-world examples such as ClawJacked, which demonstrated patch lag leaving agent gateways vulnerable.
The attack scenarios include malicious updates, rollback attacks and hot-reload abuse. To mitigate these attacks, OWASP recommends mitigations such as pinning installed skills to immutable content hashes not version ranges, freezing production deployments and subscribing to registry security advisories or auto-alerts for CVE matches on installed skills.
AST08 - Poor Scanning
Unlike traditional software, agent skills utilize executable content and metadata but also natural-language instructions. This can make it difficult to match patterns, regex filters or use signature-based detection. While marketplaces and organizations have begun to use static skill scanners and open source tools, the natural-language aspect of agent skills proves problematic and easy to bypass.
As they say in the publication:
”The enemy of AI security is the infinite variability of language”
OWASP cites a robust set of real-world evidence from security vendors and researchers showing how simple pattern matching and static scans are insufficient for detecting malicious skills and instead requires behavioral analysis as well.
Some of the attack scenarios OWASP calls out include natural-language bypass, obfuscated instructions, scanner impersonation and scanner-target evasion. To mitigate these attacks they recommend mitigations such as deploying behavioral analysis scanners to evaluate intent not just signatures, scanning both the code and natural language instruction layers independently and treating scanner skill results as advisory only, not authoritative from a risk perspective.
AST09 - No Governance
This one reads to me a bit odd, as it isn’t necessarily a specific technical risk but more so reflects the reality that the adoption curve of AI and Agents has often outpaced the organization and security teams ability to govern it.
OWASP cites organizational lack of inventories, policies, review processes and audit trails to manage skills at enterprise scale. These skills are often installed with no visibility from security teams, no governance or review process or revocation pathway.
OWASP points to the fact that typical software asset management (SAM) tools have no ability to govern agent skills, and skills can be quickly installed by anyone with access. This is often done with no logs going to the SOC, no CMDB entry and no integration with existing IAM. They cite several research efforts finding hundreds of malicious skills installed across corporate environments by developers and users with no oversight or governance.
Some of the attack scenarios include undetected compromise, unapproved malicious skills, orphaned skills, regulatory exposure and cascading agent compromise. To mitigate these attacks OWASP recommends organizations establish a centralized skill inventory, approval workflow for skill installations requiring security reviews, audit logging for skill actions and establishing skill revocation processes to offboard or shut down skills.
AST10 - Cross-Platform Reuse
Speaking to the diverse nature of the Agentic AI ecosystem, OWASP rounds out the list discussing the reality that skills are ported across platforms (e.g. OpenClaw, Claude Code, Cursor, Codex etc.) without the security properties of the source format translating.
Specific examples they use include permission manifests on one platform not transferring to another with the skill itself, creating increased risks for skills shared across platforms.
A lack of a universal skill format and normalization of security metadata across ported skills is problematic.
Some attack examples OWASP cites include security property loss in translation, cross-registry arbitrage, multi-platform campaigns and implicit privilege escalation. To mitigate these attacks, OWASP recommends techniques such as adopting a universal skill format, requiring full security metadata re-validation for ported skills, establishing cross registry threat intel among the major registries and building platform-agnostic skill scanners to identify issues at runtime.
Many of these read to me as systemic ecosystem issues rather than problems to be solved by any specific organization or user.
Closing Thoughts
Well, that was our brief tour of the new v1.0 of the OWASP Agentic Skills Top 10. I wanted to dig into it to understand the most prevalent risks and mitigations associated with Agentic Skills, what parallels exist to broader software and what aspects are novel.
Several of the risks are systemic in nature and tied to the immature nature of agents in a broader sense, and the ecosystems early days as it evolves to painfully re-learn many of the lessons we know from examples such as software and supply chain security.
I hope you found this helpful and I will be keeping an eye on how this aspect of Agentic AI security evolves!
AST09 is the one I'd push hardest on in a diligence call. Ask a vendor for a skill inventory reconciled against an approval log, not just their scanner's detection rate, and most can't produce one because skills got installed the way browser extensions did a decade ago, no CMDB entry, no SOC visibility. The scanning problem is real but the governance gap is what actually gets exploited first.
Great post! Thanks for your insights, Chris!