The Agent-Skill Security Review: A Checklist Your Sec Team Will Sign

Over one weekend, an autonomous agent inside Hugging Face infrastructure logged more than 17,000 attacker actions before anyone noticed, then harvested cloud and cluster credentials and moved laterally into several internal clusters (primary disclosure, 2026-07-17; our breakdown). The entry point was a malicious dataset carrying a remote-code loader and a template injection in its config. A developer can already scan a skill file for that class of defect in one command. What most teams do not have is the layer above the scan: the policy that says which finding blocks an install, which one gets logged, and which artifact the security reviewer files. The scan is a terminal command. The signature you need is a governance decision.

The 12-point review

Run this against every skill file before it reaches an agent that holds real credentials. Each row names the org risk that gets escalated, not the scanner flag that catches it. The mapping tracks the SkillSpector category set, 68 vulnerability patterns across 17 scan categories, which answers the developer-side question of whether a skill is safe to install for Claude, Codex CLI, Gemini CLI, and other agent systems. If you also need to run the scan itself, start with the AI Agent Skill Security guide.

Check	What the auditor looks for	Pass or flag
Data exfiltration	No skill reads env vars, tokens, or .aws/.ssh files and sends them to an off-host endpoint.	Flag on any egress of credential material.
Prompt injection	No skill overrides the agent's safety constraints or redirects its context toward attacker instructions.	Flag on any constraint override.
Supply chain	No skill script fetches then executes remote code (curl | bash, wget, dynamic install from a URL).	Flag on any remote-fetch-then-run.
Tool poisoning	No zero-width or homoglyph characters hide in tool names or descriptions, confirmed by an automated character scan.	Flag on any non-visible character; visual review does not satisfy this.
Privilege escalation	No skill requests broader file, shell, or role permissions than its stated function needs.	Flag on scope beyond the documented task.
Excessive agency	High-impact tool access (delete, deploy, pay, send) is documented and gated behind a human-approval step.	Flag on any unbounded high-impact action.
System prompt leakage	No skill instructs the agent to reveal its system prompt, tool schema, or internal config.	Flag on any request to disclose internals.
Memory poisoning	No skill writes unverified instructions into persistent memory that later runs re-read as trusted.	Flag on any untrusted write to durable memory.
MCP least privilege	Each connected MCP server is scoped to the tools the skill uses, not the full server surface.	Flag on a broad grant where a narrow one works.
Output handling	Skill output routed to a shell, browser, or downstream tool is escaped, not executed as code.	Flag on any unescaped sink.
Incident response	An on-prem or open-weight model is designated and vetted for forensic log analysis before it is needed.	Flag on the absence of a self-hosted forensic model.
Retention	Scan results are retained as audit evidence for a minimum of 90 days.	Flag on retention under 90 days.

What breaks first

The scan passes on Tuesday and the risk register says done. Then a dependency update pulls a new skill bundle on Thursday, or an engineer installs an MCP server that ships three skills nobody reviewed, and the agent runs them under the same credentials as everything else. Your onboarding scan covered the files that existed at onboarding. Skill files keep arriving after it.

The fix is the one that already worked for dependency scanning: move the check into the merge path and make it a gate. Put SkillSpector in the CI merge check so every pull request that adds or changes a skill file runs the two-stage scan (fast static pattern match, then the optional LLM semantic pass) and goes red on a blocking finding. A one-time checklist is a snapshot. A CI gate is a control an auditor can rely on, because it runs on code that did not exist when the checklist was signed.

Mapping to audit frameworks

This is the block you forward internally. Each row turns a checklist item into evidence a named control asks for.

Framework	Specific control	Evidence the checklist generates
SOC 2 Type II	Trust Services Criteria CC7.1: detection and monitoring procedures identify config changes that introduce new vulnerabilities and susceptibility to newly discovered ones.	Scan-on-merge logs plus retained findings for every skill-file change.
ISO/IEC 27001:2022	Annex A 8.8, management of technical vulnerabilities: obtain information on exposure, evaluate it, and act.	The skill-file vulnerability scan and its remediation record.
NIST AI RMF	GOVERN function, specifically GOVERN 6.1 on risks from third-party AI entities and software.	The documented gating policy plus the retained scan artifact showing third-party skills are gated.

The item no scanner gives you

The Hugging Face team ran into a problem their own scanner could never have flagged. When they tried to analyze the exploit log through commercial model APIs, the providers' safety guardrails blocked the requests: the real attack commands, exploit payloads, and C2 artifacts in the log trip the same filters that stop a user from asking for malware. They pivoted to an open-weight model, GLM 5.2, running on their own infrastructure, and their stated recommendation is to keep such a model vetted and ready before an incident, both to dodge the guardrail lockout and to keep attacker data and stolen credentials from leaving your environment during the response (disclosure, 2026-07-17). That is the one line on this list that no skill scanner will produce for you. Designate your forensic model now, while the only cost is an afternoon of evaluation.