OWASP Agentic Skills Top 10: A Buyer’s Test Plan

A procurement team asks an AI platform owner for proof that every skill loaded by a production agent came from an approved publisher, requests only necessary permissions, runs inside an isolated environment and can be revoked without disabling the entire product. The team can show its model provider, MCP server inventory and OAuth configuration. It cannot show who approved the skills, whether their dependencies changed after review or what happened when testers exercised prohibited actions.

This is the problem the OWASP Agentic Skills Top 10 is beginning to formalize. The current public-review framework focuses on the execution layer that sits between an agent’s reasoning and the tools, files, networks and workflows it can use. For buyers, its value is not another list of AI threats. It is a way to define scope, demand evidence and assign ownership before a reusable skill becomes an unreviewed production control path.

This guide converts the framework into a buyer’s test plan. It explains what should be assessed, which artifacts should be produced and what leadership should decide before approving skill-enabled agents.

Why Agentic Skills Change the Security Review

An agentic skill is more than a prompt template. Depending on the platform, it may contain natural-language instructions, metadata, scripts, dependencies, hooks, file paths, network destinations and persistent state. It can tell an agent when to act, which tools to combine and how to complete a multi-step workflow.

That makes skills different from the Model Context Protocol. MCP standardizes how an AI application discovers and communicates with tools and resources. A skill can sit above that connection and decide how several tools should be used together. Securing the MCP server therefore does not prove that the skill selecting, sequencing and parameterizing those tools is trustworthy.

For example, an MCP review may confirm that a ticketing tool requires authentication and exposes only approved methods. A separate skill may still instruct the agent to retrieve information from an external source, combine it with customer records and send the result through another integration. The transport can be correctly authenticated while the overall workflow remains over-privileged or insufficiently governed.

Our guide to how MCP security testing handles the tool boundary explains the identity and authorization side of that problem. Skill testing adds another layer: where the workflow came from, what it claims to do, what it actually does, what changed after approval and how its behavior is contained at runtime.

That distinction should affect the scope of an AI penetration test for a tool-enabled system. A credible scope should identify the models, agents, tools and APIs, but also every skill package, manifest, registry, publisher, dependency, external instruction source and update mechanism that can influence execution.

Buyer principle: Treat a skill as executable supply-chain content, even when much of its behavior is expressed in natural language rather than conventional source code.

What the OWASP Agentic Skills Top 10 Means for Buyers

OWASP’s current public-review model identifies ten risks. The names may evolve before the framework reaches a final release, so buyers should use the framework as a structured risk model rather than writing every current label into a permanent contract.

These risks should not be tested as ten isolated checklist items. A realistic failure usually crosses several categories. An apparently legitimate skill may depend on an external instruction source, run with unnecessary network access, escape meaningful review because the scanner only inspected the local package and remain deployed because no owner can revoke it quickly.

The buyer therefore needs evidence of the complete path from acquisition to execution, not a screenshot showing that a registry scanner returned “pass.”

Build the Assessment Around the Skill Lifecycle

The strongest scope follows the skill throughout its lifecycle. This keeps the engagement focused on business control points instead of turning it into an open-ended review of every AI component.

1. Inventory and business ownership

The assessor should begin with a reconciled inventory of production, staging and developer-installed skills. Each entry should identify the agent that loads it, its business purpose, the data it can reach, the actions it can initiate and the accountable owner.

This step often exposes the first governance gap. Platform engineering may manage the runtime, security may review packages, procurement may approve the vendor and a product team may own the workflow. Unless one role owns the final risk decision, a skill can remain deployed even when each team assumes another team approved it.

2. Acquisition, publisher and provenance controls

The scope should examine all permitted acquisition routes: public registries, private registries, repositories, uploaded archives, marketplace installations, copied files and internally generated packages.

Testing should determine whether publisher identity is verified, package integrity is checked, versions are pinned and dependencies resolve to immutable or otherwise controlled sources. It should also test whether the normal approval route can be bypassed through manual installation, a developer tool, a local configuration directory or an automated deployment process.

3. Manifest, metadata and permission validation

A manifest should not be accepted as proof that permissions are safe. The assessment should compare declared access with observed runtime behavior and the business task the skill is intended to perform.

A ticket-summarization skill may need read access to a defined ticket queue. It usually should not inherit unrestricted CRM access, broad file-system access, shell execution and open internet egress. Where a write action is necessary, the scope should verify that authorization is enforced by the underlying application or tool, not only by a natural-language instruction telling the model to behave.

4. Runtime isolation and egress

The test should establish the maximum blast radius if the skill is malicious, compromised or manipulated by untrusted content. Relevant controls include process isolation, container or sandbox boundaries, file-system restrictions, secret separation, destination allowlists, DNS and network policy, time and resource limits, and separation between user, service and administrative identities.

The objective is not to prove that the skill can never behave unexpectedly. It is to prove that unexpected behavior cannot automatically become unrestricted host, data or network access.

5. External instructions and dependency changes

Buyers should ask for a map of every source that can change skill behavior after installation. This includes remotely hosted instructions, documentation pages, repositories, packages, downloaded scripts, APIs, memory files and shared configuration.

A package hash is incomplete evidence when the local package tells the agent to retrieve mutable operational instructions from somewhere else. The assessment should therefore record both packaged content and externally resolved behavior.

6. Runtime behavior and prohibited-path testing

Scanning should be complemented by controlled execution. Testers should observe file access, network calls, tool selection, identity use, sensitive actions, memory changes and failure behavior while exercising allowed and prohibited workflows.

The goal is not to generate a list of unusual model responses. The goal is to determine whether a manipulated or compromised skill can cross a meaningful business boundary: another tenant, a restricted data class, an unauthorized tool, an unapproved destination or a write action the current user cannot perform directly.

The broader guide to what an AI penetration test should cover explains how this skill layer fits with prompt, RAG, API, identity and infrastructure testing.

7. Updating, revocation and retirement

The assessment should test what happens when a publisher releases a new version, a dependency changes, a signing key is revoked or a registry removes the skill. Security teams should be able to identify affected agents, block a version, roll back safely, rotate exposed credentials and preserve enough evidence for investigation.

A skill that can be installed in minutes but cannot be located and disabled quickly represents an operational-control gap even when no vulnerability has yet been exploited.

Evidence Buyers Should Require

A useful assessment produces more than findings. It should give leadership and procurement a durable evidence package that can support launch approval, customer reviews and future reassessment.

A buyer reviewing an assessment proposal should ask whether these artifacts will be delivered explicitly. A report that contains only vulnerability names and screenshots may help engineers, but it will not answer the procurement or governance question: “Which exact skill versions are approved to perform which actions, and what evidence supports that decision?”

Pentest Testing Corp’s sample penetration-testing report structure shows the broader reporting pattern buyers should expect: an executive summary, technical evidence, prioritized remediation and framework mapping. A skill-focused report should preserve that structure while adding lifecycle, provenance, permission and revocation artifacts.

A Sanitized Illustrative Scenario

The following scenario is hypothetical and does not describe a Pentest Testing Corp client.

A SaaS company deploys a support agent that reads incoming tickets, searches a knowledge base and updates cases in its customer-service platform. To accelerate deployment, the team installs a third-party triage skill from a public registry.

The skill passed the registry’s automated scan when installed. Procurement recorded the agent platform as an approved vendor, and the MCP server connecting the agent to the ticketing system had already been reviewed. Leadership therefore assumes the workflow is covered.

A skill-focused assessment finds four gaps:

1. The skill’s package references a remotely hosted instruction document that was not included in the original review.
2. The runtime service identity can read tickets across more customer groups than the product workflow requires.
3. The agent process has unrestricted outbound network access because other integrations use the same environment.
4. No central inventory connects the installed skill version to the agents that currently load it.

None of those facts alone proves that customer information will be stolen. Together, however, they create a credible path in which changed external instructions could influence an over-privileged agent and communicate with an unapproved destination. The eventual impact would depend on the application’s authorization controls, runtime egress policy and the data available to the service identity.

The remediation is therefore shared:

• Platform engineering pins or internalizes the external instructions and records the complete skill package.
• IAM and application teams reduce ticket access to the requesting customer and role.
• Cloud security applies destination allowlists and separates the runtime from unrelated integrations.
• Security governance creates an approval, inventory and revocation process.
• The product owner decides whether the residual business benefit justifies any remaining exception.

This is why agent-skill security cannot be assigned exclusively to the model team or the application-security team. The failure path crosses supply chain, identity, application authorization, runtime infrastructure and operational governance.

Map AST10 to Existing AI Governance

The Agentic Skills Top 10 should supplement existing AI and software-security frameworks rather than replace them.

OWASP Top 10 for Agentic Applications

Three Agentic Applications categories are especially relevant:

• ASI04: Agentic Supply Chain Vulnerabilities aligns with malicious skills, compromised publishers, dependency changes and weak provenance.
• ASI05: Unexpected Code Execution becomes relevant where a skill, hook, package or instruction path can cause code or commands to run outside the intended workflow.
• ASI06: Memory and Context Poisoning applies when skill behavior or persistent state can be altered through untrusted content and continue influencing later sessions.

AST10 provides a more specific lifecycle lens for the reusable skill itself. The broader Agentic Applications framework describes the resulting system-level failure.

OWASP LLM Top 10 (2025)

LLM03:2025 Supply Chain is the clearest LLM-level mapping. It addresses risks in third-party models, data, packages and deployment components. Agentic skills extend that supply chain to natural-language instructions, manifests, scripts and external sources that influence execution.

LLM06:2025 Excessive Agency applies when an agent or skill has unnecessary functionality, permissions or autonomy. A trustworthy publisher does not make broad permissions safe. Least privilege and underlying authorization remain necessary.

LLM01:2025 Prompt Injection can also intersect with AST05 and ASI06 when untrusted content changes how a skill or agent behaves. The important security question is not whether the model produced an unusual response. It is whether the manipulated instruction crossed a protected data or action boundary.

The discussion of business consequences of AI agent hijacking provides additional context on how excessive agency can convert an instruction-control failure into operational, financial or data exposure.

NIST AI Risk Management Framework

The NIST AI RMF is voluntary and organizes AI risk management around four interconnected functions:

Our guide to AI pentest evidence mapped to the NIST AI RMF explains this relationship in greater detail. AST10 gives the organization a focused risk vocabulary; the AI RMF provides the management structure around the assessment.

What Leadership Should Decide

Leadership does not need to approve every line of a skill manifest. It does need to set the conditions under which a skill may enter and remain in production.

Decision 1: Is a skill governed as software?

The organization should decide whether skills are included in its software inventory, change-management process, third-party review and incident-response plan. Calling a skill “configuration” or “content” should not exempt it when it can influence execution.

Decision 2: Which sources are permitted?

Define whether production agents may load skills from public registries, verified publishers, private registries, approved repositories or only internally packaged sources. Document how exceptions are approved.

Decision 3: What risk tiers require independent testing?

A read-only formatting skill does not warrant the same depth as a skill with customer-data access, shell execution, financial actions or administrative tools. Risk tiers should consider data sensitivity, write capability, identity privilege, external instructions, network access and autonomy.

Decision 4: What evidence is required before launch?

At minimum, high-impact skills should have provenance evidence, a permission matrix, runtime isolation results, allowed and prohibited-path testing, logging validation, a rollback procedure and a named remediation owner.

Decision 5: Who can accept residual risk?

Engineering can explain feasibility and security can explain exposure, but the accountable product or business owner should formally accept any residual risk that affects customers, regulated data or material operations.

Decision 6: What changes trigger reassessment?

Reassessment should be triggered by material changes to the skill version, publisher, dependency graph, permission set, external instruction source, runtime, agent identity, connected tools, data access or cross-platform packaging.

Decision 7: What is the launch outcome?

The final decision should be one of three outcomes:

1. Approve with evidence: Required controls are implemented and prohibited paths were independently tested.
2. Approve with time-bound conditions: Residual gaps have compensating controls, accountable owners and deadlines.
3. Delay deployment: A material provenance, permission, isolation or revocation weakness makes the current blast radius unacceptable.

Procurement teams evaluating an assessor can use these questions for an AI penetration-testing provider to confirm that the proposed work covers agent behavior and evidence, rather than repackaging a conventional web scan.

The OWASP Agentic Skills Top 10 gives buyers a useful vocabulary for an emerging control surface. Its real value appears when those categories are converted into system boundaries, test cases, evidence requirements and accountable remediation.

A registry approval, signature or package scan can contribute to assurance, but none proves that the deployed skill operates with appropriate authority, remains unchanged, is isolated from unrelated assets or can be revoked during an incident. Those questions require assessment of the production workflow.

To define the skills, registries, agents, identities, tools, environments and evidence that should be included, request an agentic AI security assessment from Pentest Testing Corp or book a 30-minute scoping call.