Originally published at https://www.pentesttesting.com/owasp-agentic-skills-top-10/
The core review principle
An agent-skill manifest is a declaration, not proof. A reliable review compares declared behavior with the exact package, its dependencies, externally resolved instructions, runtime access, and observed actions.
This is the practical distinction between the skill layer and MCP. MCP defines how an AI application communicates with tools and resources. A skill may sit above those connections and decide which tools are selected, in what sequence, with which parameters, and under which identity. Securing the transport does not automatically secure the workflow.
Review the full lifecycle, not ten isolated labels
1. Inventory and ownership
Build a reconciled inventory across production, staging, and developer environments. Record the exact skill version and hash, source, publisher, agent, environment, owner, business purpose, data classes, tools, and write capabilities.
The operational question is simple: can you identify every agent that loads a specific skill version and disable that version quickly? If not, update drift and incident containment will be difficult even when package review is strong.
2. Acquisition and provenance
Test every allowed installation path: public and private registries, repositories, uploaded archives, copied files, local configuration directories, and automated deployment pipelines.
Verify publisher identity, package integrity, immutable versioning, dependency state, and approval records. A legitimate publisher name is not enough when a publisher account, repository, package, or transitive dependency can change.
3. Metadata, permissions, and identity
Compare the manifest with runtime behavior and the skill’s actual business task. Map file access, tools, network destinations, data classes, user roles, service identities, and sensitive actions to enforcement points outside the model.
A prompt instruction such as “do not modify production” is guidance. The tool, API, cloud policy, or application authorization layer must reject the action when it is not permitted.
4. External instructions and dependencies
Record every remote document, repository, package, script, API, memory file, or shared configuration source that can change behavior after installation.
A package hash cannot prove the complete effective behavior when the local package retrieves mutable instructions at runtime. Pin, internalize, monitor, or explicitly govern those sources, then include them in reassessment triggers.
5. Isolation and egress
Determine the maximum blast radius of a malicious, compromised, or manipulated skill. Review process or container boundaries, file restrictions, secret separation, network policy, destination allowlists, DNS controls, resource limits, and identity separation.
The goal is not to guarantee perfect model behavior. It is to stop unexpected behavior from becoming unrestricted access to customer data, credentials, hosts, networks, or external destinations.
6. Runtime and prohibited-path testing
Exercise approved workflows and defined prohibited paths while observing file access, tool selection, network calls, identity use, parameters, memory changes, outputs, and failure behavior.
Tie each test to a protected business boundary: another tenant, a restricted data class, an unauthorized tool, an unapproved destination, or a write action the current user cannot perform directly. Avoid scoring success by the number of unusual model responses.
7. Update, revocation, and recovery
Test version blocking, rollback, reload prevention, credential rotation, affected-agent identification, and evidence preservation. Verify that logs connect the originating actor, skill version, tool call, material parameters, result, data classification, and correlation ID.
A feature flag or documented playbook is not the same as a tested containment path.
Minimal evidence package
At minimum, a review should produce:
Skill inventory with exact versions, hashes, owners, and environments.
Approval and provenance records.
Permission and identity matrix with enforcement points.
External-source and dependency inventory.
Runtime isolation and egress evidence.
Allowed and prohibited-path test results.
Behavioral logging validation.
Revocation and rollback results.
Remediation owners, deadlines, exceptions, and retest criteria.
Business impact and remediation ownership
The most important findings usually cross team boundaries. Platform engineering may own packaging and runtime controls. IAM and application teams enforce user, role, and tenant authorization. Cloud or endpoint security handles isolation and egress. Procurement and vendor risk govern third parties. Product leadership accepts residual business risk.
That shared ownership affects cost and timeline. Reducing a manifest permission may be quick. Replacing a shared privileged identity, adding tenant-context propagation, separating runtimes, or building correlated telemetry may require architectural work. Scope the assessment early enough that these changes can be made before customers and production operations depend on the workflow.
Framework mapping
AST10 complements the broader OWASP Top 10 for Agentic Applications and the OWASP LLM Top 10 (2025). Supply-chain concerns align with LLM03, excessive permissions and autonomy with LLM06, and untrusted instructions with LLM01 when they cross a protected data or action boundary.
The NIST AI RMF can organize the evidence: GOVERN for ownership and approved sources, MAP for system context and impact, MEASURE for technical testing, and MANAGE for remediation, exceptions, revocation, and retesting.
A safe launch gate
For high-impact skills, the release decision should be explicit: approve with evidence, approve with time-bound conditions, or delay because provenance, permission, isolation, or revocation gaps make the blast radius unacceptable.
Read the complete buyer-focused version and evidence matrix in the canonical article: https://www.pentesttesting.com/owasp-agentic-skills-top-10/
Top comments (0)