Vetting and Approving AI Agent Skills: An Enterprise Playbook
- Agent skills are reusable capability packages (markdown instructions plus code) that load into an AI agent and execute with the agent's full permissions, so an unvetted skill is arbitrary code running as your agent.
- Vetting must cover BOTH the code layer AND the markdown instruction layer, because natural-language injection hides in prose where code scanners never look (OWASP AST05 and AST08).
- Dependency-chain analysis is non-negotiable: an abandoned or transferred dependency can be taken over later in a skilljacking-style attack, turning a once-clean skill malicious (OWASP AST02).
- Permission and metadata review catches over-privilege and unsafe config before a skill inherits everything the agent can do (OWASP AST03 and AST04).
- One-time approval is insufficient. Skills change after approval and dependencies get hijacked, so continuous re-vetting and update-drift detection are the core of the program (OWASP AST07 and AST09).
- Every approval, rejection, and post-approval change must be logged so you can answer what was approved, by whom, and what has drifted since.
An agent skill looks harmless. It is often a folder with a markdown file describing what the skill does and a bit of code to do it. But that package loads into an AI agent and runs with the agent's full permissions, which means approving a skill is not like approving a document. It is like approving a third-party binary to run inside your most privileged automation. Treated casually, a single unvetted skill is arbitrary code executing as your agent, reading whatever the agent can read and calling whatever tools the agent can call.
This guide is a concrete playbook for vetting and approving skills before they touch the fleet, and for keeping that approval honest over time. It is organized around the failures the December 2025 OWASP Top 10 for Agentic Skills names directly: AST02 Supply Chain Compromise, AST08 Poor Scanning, and AST09 No Governance, with supporting references to over-privilege, insecure metadata, untrusted instructions, and update drift. If you want the framework in full first, start with the OWASP Agentic Skills Top 10 guide.
Why skills need the third-party software treatment
The mistake most teams make is filing skills under content rather than under code. A skill is distributed like a package, it pulls dependencies like a package, and it executes like a package. It should therefore inherit the entire discipline your organization already applies to third-party software: intake, review, allowlisting, and ongoing monitoring. The difference is that a skill has a second attack surface a normal package does not, the natural-language instruction layer, and that surface is where most skill-specific attacks live.
AST09 No Governance is the umbrella failure here: skills get adopted bottom-up by developers who want a capability now, with no approval step, no owner, and no record. That is the same shadow-adoption pattern we describe in AI agents are the new shadow IT. The playbook below turns that ad hoc adoption into a governed process.
The vetting workflow, stage by stage
Vetting is a pipeline, not a single check. Each stage is designed to catch a different class of failure, and a skill only reaches the fleet after it clears all of them. Here is the workflow at a glance before we walk each stage.
| Vetting stage | What to check | Red flag |
|---|---|---|
| 1. Request / intake | Who wants it, what capability it provides, which agent and platform it targets, named owner | No owner, no stated purpose, or a skill pulled from an unknown source |
| 2. Static review - code layer | Hidden payloads, obfuscation, network egress, shell or exec calls, file access outside scope | Encoded or minified blobs, calls to external endpoints, dynamic code execution |
| 3. Static review - instruction layer | Markdown prose for injected directives, tool-invocation coercion, data-exfiltration instructions | Instructions telling the agent to ignore prior rules, send data out, or run extra tools |
| 4. Dependency-chain analysis | Every transitive dependency, its maintainer, its activity, whether names resolve to real packages | Abandoned or recently transferred dependency, or a hallucinated package name |
| 5. Permission and metadata review | Declared scopes vs. actual need, config files, unsafe deserialization, execution-enabling metadata | Broad or wildcard scopes, metadata that can trigger code execution on load |
| 6. Allowlist / registry entry | Pin the exact reviewed version and hash, record the approval decision and owner | Approving a floating version or a range instead of a pinned artifact |
| 7. Continuous re-vetting | Version changes, dependency updates, maintainer transfers, drift from the approved artifact | A running skill whose hash no longer matches what was approved |
Stage 1 - Request and intake
Nothing gets vetted until it is requested through a defined channel. Intake captures the essentials: who is asking, what capability the skill provides, which agent and platform it will run on (OpenClaw, Claude Code, Cursor, VS Code, and so on), and a named owner who is accountable for it. A skill with no owner and no stated purpose is rejected at the door. Intake is also where you record the source, because a skill pulled from an unknown or unofficial location carries more supply-chain risk before anyone has read a line of it.
Stage 2 - Static review of the code layer
This is the review most teams already know how to do. Read the code for hidden payloads, obfuscation, encoded blobs, dynamic code execution, unexpected network egress, shell or exec invocation, and file access reaching outside the skill's stated scope. Automated scanners help, but they are necessary and not sufficient, which is the entire point of AST08 Poor Scanning: a scan that only understands code will pass a skill whose malice lives in prose. Treat a clean code scan as one gate cleared, not as approval.
Stage 3 - Static review of the instruction layer
This is the stage that separates skill vetting from ordinary package review, and the one teams skip. The markdown instruction layer is executable in the sense that the agent follows it. An attacker can plant directives in that prose that steer the agent to ignore prior rules, invoke additional tools, or send data to a destination the reviewer never approved. Because these instructions are natural language, no code scanner flags them. This is AST05 Untrusted External Instructions, and it demands a human (or an LLM-assisted reviewer specifically prompted to hunt for injected directives) reading the prose adversarially. Ask of every instruction: if the agent obeys this literally, what is the worst it does? For the mechanics of how injected prose hijacks an agent, see indirect prompt injection explained.
Stage 4 - Dependency-chain analysis
A skill is rarely self-contained. It pulls dependencies, and those dependencies pull their own. AST02 Supply Chain Compromise lives in that transitive graph. Two failure modes matter most. First, an abandoned or recently transferred dependency can be taken over by an attacker who then ships malicious code into everything downstream, the skilljacking pattern covered in skilljacking and abandoned skill dependency takeover. Second, a dependency name that does not resolve to a real, established package may be a hallucinated or squatted name an attacker has registered, the slopsquatting risk in slopsquatting and hallucinated package installs. Enumerate the full dependency tree, check each maintainer's activity, and flag anything abandoned, recently transferred, or suspiciously new. This is also where the broader AI supply chain attacks defenders guide applies.
Stage 5 - Permission and metadata review
Because a skill inherits the agent's permissions, an over-scoped skill is a liability even if its code is clean today. Compare the scopes the skill declares (or implicitly requires) against what its function actually needs, and reject anything reaching for broad or wildcard access, the AST03 Over-Privileged Skills failure. Then read the metadata and config files themselves. AST04 Insecure Metadata is the trap where a skill's configuration format enables code execution on load, for example through unsafe deserialization, so the config file is itself an execution vector. A skill whose metadata can run code the moment it is parsed never reaches the allowlist. The full treatment of scoping and metadata hygiene is in least privilege for agent skills.
Stage 6 - Allowlist and internal registry
A skill that clears the previous stages earns a place on the allowlist, recorded in an internal registry that is the single source of truth for what is approved to run. The registry entry pins the exact reviewed version and a hash of the approved artifact, names the owner, and records the approval decision. Pinning is what makes drift detectable: if the running skill no longer matches the pinned hash, you know it changed. Approving a floating version or a range quietly forfeits that guarantee. The registry pattern mirrors the one in how to build an MCP server registry and rides on the inventory work in how to build an AI agent inventory.
Stage 7 - Continuous re-vetting
This is the stage the whole playbook builds toward, and the one that most distinguishes a real program from a checkbox. A skill can change after you approve it, and a dependency can be hijacked long after your review. AST07 Update Drift is the name for approved-then-changed, and skilljacking is the name for the dependency going bad later. Both mean your one-time approval is a snapshot that decays. Continuous re-vetting watches for version changes, dependency updates, maintainer transfers, and any divergence from the approved artifact, and it re-runs the relevant stages when something moves. Without this stage, every other stage is describing a moment that has already passed.
One-time approval is a photograph. The fleet is a movie. Vetting has to run at the frame rate of change, not once at the premiere.Anomity Research
Audit logging: what was approved, by whom, and what has drifted
Every decision in the pipeline is a record. Log the approval and the rejection, who made it, which version and hash were reviewed, what scopes were granted, and every post-approval change to a skill or its dependencies. Two questions justify the effort. The first is accountability: after an incident, you need to know what was approved, by whom, and on what basis. The second is drift: without a log of what a skill looked like at approval, you cannot prove that today's running skill still matches it. Audit logging is not paperwork here; it is the substrate that makes continuous re-vetting and AST09 governance possible. For the wider discipline, see the AI agent audit trail and logging guide.
Where continuous visibility fits
Every stage above assumes you can see what is actually installed. You cannot vet a skill you never knew was pulled onto a developer's machine, and you cannot detect drift on a skill your registry claims is one version while the endpoint runs another. A paper registry describes what should be true; it does not observe what is true. That gap between intent and reality is where unvetted and drifted skills live.
This is where Anomity sits. Its lightweight, unprivileged Endpoint Sensor runs on every managed endpoint (Windows, macOS, Linux) and discovers skills as one of the eight AI artifact types it inventories, alongside agents, MCP servers, extensions, plugins, secrets, hooks, and CLIs. It sends metadata only over HTTPS, never source code and never prompts, with secrets redacted on the endpoint. Continuous policy evaluation flags every added, removed, or modified skill, which is the drift signal that turns a one-time approval into ongoing re-vetting, and violations route to your SIEM, Slack, email, and Jira. On agents that expose a hook, Anomity can allow, deny, or log a skill-triggered tool call before it runs. Every change lands in a queryable 90-day audit trail. As the principle goes: you can't govern what you can't see. See the features overview and runtime governance for how it fits alongside your existing EDR, DLP, and GRC stack.
The bottom line
Vetting an agent skill means treating it as third-party code that runs with your agent's full authority, and reviewing both the layers it attacks through: the code and the instructions. Walk every skill through intake, dual-layer static review, dependency-chain analysis, and permission and metadata review before it reaches an allowlist, and pin exactly what you approved. Then accept the hard truth that the approval is a snapshot. Skills drift and dependencies get hijacked, so re-vet continuously and log every decision and every change. A one-time gate protects you for exactly one moment. A continuous program protects the fleet, and it starts with seeing every skill that is actually running.
Frequently asked questions
What is an agent skill and why does it need vetting?
An agent skill is a reusable capability package, typically markdown instructions bundled with code, that loads into an AI agent on platforms like OpenClaw, Claude Code, Cursor, and VS Code. It runs with the agent's full permissions, so installing an unvetted skill is functionally the same as running arbitrary third-party code as your agent. That is why it belongs in the same trust process you would apply to any third-party software dependency. See our security primer on agent skills for the fundamentals.
Why isn't a code scan enough to approve a skill?
A skill has two attack surfaces. The code layer can carry a hidden payload, but the markdown instruction layer can carry natural-language injection that steers the agent to exfiltrate data or invoke dangerous tools, and that prose is invisible to a code scanner. OWASP AST05 (Untrusted External Instructions) and AST08 (Poor Scanning) both exist because teams scan the code and ignore the instructions. Effective vetting reviews both layers.
What is skilljacking and how does vetting address it?
Skilljacking is the takeover of an abandoned or transferred skill or one of its dependencies, so that a skill you already approved starts shipping malicious code after the fact. Vetting addresses it through dependency-chain analysis at intake and, critically, through continuous re-vetting, because the risk materializes after initial approval. We cover the attack in depth in skilljacking and abandoned skill dependency takeover.
Why is one-time approval insufficient for agent skills?
A skill can update itself or pull a new version of a dependency after you approved it, and a maintainer account can be transferred to an attacker. The version you vetted is not necessarily the version running next week. This is OWASP AST07 (Update Drift), and it is the single most common reason a clean vetting decision goes stale. Approval has to be a continuous process with re-vetting on every change, not a one-time gate.
What belongs in a skill allowlist or internal registry?
Only skills that have passed intake, dual-layer static review, dependency analysis, and permission review, pinned to the exact reviewed version. The registry is the single source of truth for what is approved to run, and anything not on it should be blocked or flagged. Pinning by version and hash is what lets you detect drift when a running skill no longer matches the approved artifact.
How does Anomity help with vetting and approving skills?
Anomity's lightweight Endpoint Sensor discovers and inventories skills as one of eight AI artifact types across every managed endpoint, sending metadata only, so you can see which skills are actually installed and where instead of trusting a paper registry. It continuously evaluates each skill against policy, flags added, removed, or modified artifacts, and on agents that expose a hook it can allow, deny, or log a skill-triggered tool call before it runs. Every change lands in a queryable 90-day audit trail, which is exactly the continuous re-vetting signal a one-time approval process lacks.
Who should own the skill approval process?
Ownership usually sits with the security or platform team that already runs third-party software review, with skill authors and requesting teams feeding intake. The important thing is that approval is a named, accountable decision recorded in an audit trail, not an informal Slack thumbs-up. OWASP AST09 (No Governance) is precisely the failure of leaving skill adoption ungoverned.
Does vetting skills replace runtime controls?
No. Vetting reduces the odds a malicious or over-privileged skill ever reaches the fleet, but a vetted skill can still be steered by untrusted input at runtime, and drift can outpace re-vetting. You want vetting at intake and runtime governance in production. Pair this playbook with least privilege for agent skills so an approved skill still cannot do more than its function requires.
