As reported by Dark Reading, OWASP has released a new Top 10 security list focused specifically on AI skills, accompanied by a Universal Skill Format (USF) designed to bring consistency and security to the rapidly expanding ecosystem of AI agent add-ons. This is a watershed moment for AI security governance—and one that defenders should not dismiss as premature.
The industry has been racing to build agentic AI systems that can take action, not just generate text. Every major platform—from OpenAI's GPTs to enterprise copilots—now supports some form of skill, plugin, or tool integration. What OWASP correctly identifies is that these skills are effectively executable third-party code with delegated authority, yet they are being distributed and consumed with less scrutiny than mobile app stores required a decade ago.
Why This Matters Now
The core problem is one of transitive trust. When an enterprise deploys an AI assistant and a user installs a skill, that skill often inherits the assistant's permissions—access to documents, email, CRM data, code repositories, and external APIs. There is no consistent manifest describing what a skill does, what data it touches, or what network calls it makes. OWASP's Universal Skill Format is an attempt to fix that by establishing a standardized declaration layer.
This is the API security crisis of 2012 reborn—except now the API consumer is an autonomous agent that can chain calls, interpret responses, and make decisions without human review at each step.
That distinction is critical. Traditional API abuse required an attacker to directly invoke endpoints. AI skill abuse can be triggered indirectly through prompt injection, poisoned tool outputs, or manipulated context windows—meaning the attack surface is not just the skill's code but the entire semantic pathway between user intent and skill execution.
Who Is Most Exposed
The Standardization Gap
OWASP's USF proposal addresses a real void. Today, every AI platform defines skills differently—OpenAI's function calling schema, Anthropic's tool use format, LangChain tools, Microsoft Copilot plugins, and the emerging Model Context Protocol (MCP) each have their own structure. This fragmentation means security teams cannot write a single policy, run a single scanner, or enforce a single approval workflow across their AI estate. A common format, even if imperfect, gives defenders something to anchor controls to.
The risk, of course, is that a standard becomes a checkbox. A skill manifest that declares "reads: email, writes: none, network: api.example.com" is only valuable if something enforces it at runtime. Without execution-level sandboxing and policy enforcement, the USF risks becoming documentation theater.
Shield53 Recommendations
- Inventory your AI skill estate now. You cannot govern what you have not catalogued. Identify every platform, copilot, and agent framework in use and enumerate installed or available skills.
- Establish an AI skill approval workflow modeled on your existing third-party software procurement process—require vendor due diligence, data flow mapping, and security review before any skill is enabled.
- Adopt the USF as an internal standard even before vendor adoption matures. Use it as a template for your own skill intake questionnaires and risk assessments.
- Implement runtime guardrails that do not rely on skill self-attestation. Use tool-call interception, output filtering, and permission scoping to enforce least privilege regardless of what a manifest claims.
- Monitor for prompt injection vectors that could hijack legitimate skills. The skill itself may be trustworthy; the data it processes may not be.
- Track the OWASP AI skill Top 10 as a living control framework and map each item to your existing security controls, identifying gaps for remediation.
OWASP has timed this well. The AI skill ecosystem is still early enough that security standards can shape architecture rather than retrofit it. Organizations that wait for a breach-driven compliance mandate will find themselves governing thousands of unmanaged, privileged integrations—a problem that makes shadow API exposure look manageable by comparison.
