Most agent security checklists are lists of things someone thought of. That is not a criticism of the people who wrote them — it is a description of the state of the field — but it does mean the checklist cannot support the one claim an assurance engagement most needs to make, which is that the surface has been covered.
A formal derivation can support that claim. The treatment in Formal Analysis and Supply Chain Security for Agentic AI Skills defines a skill's lifecycle as an ordered five-phase sequence — *Install, Load, Configure, Execute, Persist* — and enumerates six attack classes: data exfiltration, privilege escalation, prompt injection, dependency confusion, typosquatting and namespace squatting. Each class is then mapped to the phases where it can actually manifest.
The result is a set of (phase, class) pairs, and the cardinality is *ten*.
One property of the model deserves emphasis because it drives the ordering of remediation: attacks at an earlier phase propagate forward to all later phases. A typosquatting attack that succeeds at Install enables arbitrary code execution at Execute. Fixing S9 while S2 is open buys less than it appears to.
The map
Each row gives the mechanism, the control, a test that demonstrates the control works, and the evidence to retain. The evidence column is deliberate: with model risk guidance withdrawn for agentic systems, what you can produce is the argument you get to make.
Ten (phase, class) surfaces as controls
Filter by lifecycle phase or attack class. Remediate earlier phases first — they propagate forward.
10 of 10 rows
| S1 | Install | Dependency confusion | A public skill published under the same name as a private internal one, causing the resolver to fetch the attacker's package. | Pin every skill to a content digest, never a name or tag. Configure the resolver to refuse public resolution for any namespace registered internally. | Publish a decoy public skill matching an internal name in a staging registry and assert the resolver refuses it. | Resolver configuration under version control, plus the lockfile showing digest pinning for every installed skill. |
| S2 | Install | Typosquatting | A skill registered under a near-homograph of a popular name — weahter-api against weather-api. | Allowlist skills by digest at the pipeline, not by name at the developer's terminal. Human-in-the-loop review for any first-time skill name in the estate. | Attempt installation of a near-homograph name in CI and assert the pipeline blocks it. | The allowlist, its change history, and the review record for each first-time addition. |
| S3 | Install | Namespace squatting | Pre-emptive registration of a namespace likely to be used by a legitimate organisation. | Register your own namespaces defensively on every registry your agents resolve from, whether or not you intend to publish. | Enumerate namespaces matching your organisation across all configured registries and assert ownership. | Namespace ownership records per registry, reviewed on a schedule. |
| S4 | Install | Data exfiltration | Install-time hooks that read the developer workstation or CI environment and post elsewhere. The ClawHavoc pattern, which deployed a credential stealer. | Install in a network-isolated sandbox with no credentials present. Never install skills on a workstation holding production credentials. | Install in a monitored sandbox and assert zero egress during the install phase. | Sandbox egress logs for each install, retained with the lockfile entry. |
| S5 | Load | Prompt injection | Adversarial content embedded in skill metadata or descriptions, which are presented to the agent's language model for tool selection. | Treat skill metadata as untrusted data, not instruction. Strip or delimit it before it reaches the model context, and never interpolate it into a system prompt. | Load a skill whose description contains an instruction and assert the agent's tool selection is unchanged. | The metadata sanitisation code path, plus the negative test in CI. |
| S6 | Load | Privilege escalation | Code injection during module import or initialisation, before any capability check has run. | Load skills in a capability-confined interpreter. Import must not be able to acquire authority beyond the declared capability set. | Load a skill whose import block attempts a filesystem write outside its declared scope and assert it fails closed. | The confinement configuration and the failing-closed test result. |
| S7 | Configure | Privilege escalation | Over-permissioned configuration — API keys, endpoint URLs and access scopes set wider than the skill's declared need. | Derive configuration scope from the declared capability set rather than from a template. Refuse to start when granted scope exceeds declared capability. | Configure a skill with a scope wider than its declaration and assert startup fails. | The declaration-versus-grant comparison emitted at startup, retained per deployment. |
| S8 | Configure | Prompt injection | Injection through configuration templates — the Jinja2 template-injection class seen in dataset configuration. | Render configuration templates in a sandboxed environment with no access to the host namespace. Prefer non-templated configuration where possible. | Supply a template expression in a configuration value and assert it is not evaluated. | Template engine configuration showing sandboxed rendering, plus the negative test. |
| S9 | Execute | Data exfiltration | The broadest surface. At execution a skill may invoke sub-tools, read files and make network requests — the phase with the widest authority. | Deny-by-default egress allowlisted per task rather than per environment. Split read from write on every shared resource. | Run the task with a deny-all egress policy and assert it completes; anything it needs beyond the allowlist is a finding, not a fix. | Per-task network policy, plus the resource ledger showing every host actually reached. |
| S10 | Persist | Data exfiltration | State, logs or artefacts written to durable storage that is readable by another principal. This is the phase in which a shared surface becomes a channel. | Per-agent write paths with no cross-readability. Enumerate every shared writable surface and treat each as a channel until proven otherwise. | Assert that agent A cannot read anything agent B wrote, for every pair of agent identities in the estate. | The shared-surface inventory, plus the pairwise readability assertion results. |
Filter state is carried in the URL — an Install-phase view can be linked directly to whoever owns the pipeline.
Why the trust model makes this urgent
The three dominant ecosystems share the structural weakness that makes every row above reachable: *no formal capability model constrains what a skill can do to what it declares.*
- *OpenClaw* — 228,000 GitHub stars as of February 2026. Its marketplace runs an install-and-run trust model: discover through a web interface or CLI, install with one command, execute with the agent's full system privileges. No formal review, no signing, no capability declaration required to publish.
- *Anthropic Agent Skills* — 75,600 stars. Skills are YAML and Markdown files that may include shell commands, code blocks and instructions. A moderation pipeline exists; no formal capability model constrains behaviour at runtime.
- *Model Context Protocol* — servers declare tool schemas, meaning input and output types, but not capability requirements. In the paper's words, a server that claims to "search files" may also execute arbitrary shell commands, and the protocol provides no mechanism to detect or prevent this.
That last one is the highest-leverage fixable thing in the stack. A tool that declares its types but not its permissions is a type system with a hole in exactly the position that matters. Until a protocol-level mechanism exists, the check has to live in your installation pipeline — which is what S6 and S7 above are for.
What the existing tools can and cannot prove
Every defence currently shipping in this space is heuristic, and the honest ones say so.
- *Snyk agent-scan* (~1,500 stars, following the Invariant Labs acquisition in early 2026) — LLM-as-judge plus hand-written rules over agent configurations and skill manifests. Strong CI/CD integration. Cannot prove absence of malicious behaviour, and LLM judges are themselves adversarially attackable.
- *Cisco skill-scanner* (994 stars) — YARA and regex signature detection for known malicious patterns. Its documentation states the position plainly: "no findings does not mean no risk." That is the most honest sentence in the category.
- *ToolShield* — behavioural heuristics derived from the MalTool benchmark, achieving a 30% reduction in attack success rate.
A 30% reduction is real and worth having; it is not coverage. The distinction that matters for an assurance claim is between answering "did we detect a known bad pattern?" and answering "can this skill access resources beyond what it declares?" — the second is checkable against the ten surfaces above, the first is not.
Where the formalism runs out
This is the section a reference piece owes its reader, and it is why I would not sell this map as complete.
The taxonomy models an *attacker manipulating skill packages* — forging skills, compromising registries, poisoning dependencies. It is a supply-chain threat model, and within that domain the paper proves its attacker maximal, meaning any attack achievable by any symbolic adversary can be simulated within the model.
The most consequential incident of 2026 falls outside it entirely. The Artifactory coordination channel involved *no malicious skill at all*. Legitimate agents, with legitimate access, coordinating through a legitimate service that nobody had classified as a communication medium. No package was forged. No registry was compromised. No dependency was poisoned. Every row in the table above would have passed.
The relevant published result is OMNI-LEAK — multi-agent architectures create implicit information channels across trust boundaries even where individual agents appear well-isolated — but that is an observation, not a formalism. As far as I can establish, nobody has written down a formal model of the coordination case, with an attacker definition and a completeness argument, in the way the supply-chain case now has one.
So the honest scope of this reference is: *ten surfaces, complete within the supply-chain threat model, and silent on coordination.* Use it for what it covers and enumerate your shared writable surfaces separately, because the taxonomy will not do that for you.
A note on the numbers in circulation
Three figures attributed to this literature do not survive checking, and a reference piece that cites the paper has an obligation to say so.
- *"42,447 skills scanned, 26.1% vulnerable"* is regularly credited to this paper. The paper cites it from a different study — "Agent Skills in the Wild", January 2026, its reference [44]. Its own empirical work is a 540-skill benchmark.
- *"6,487 malicious tools"* appears in no located source. MalTool reports 1,300 standalone plus 5,727 with embedded malicious behaviour — 7,027.
- *The paper's v2*, uploaded 5 August 2026, states that it corrects "external claims regarding malicious tool counts and vulnerability statistics." The author caught the problem in his own bibliography.
The paper also reports a negative result about its own technique — information-flow analysis detected no skill that pattern matching alone did not, so its contribution to coverage on that corpus was zero. That is published, in the paper, by the person it embarrasses, and it is the main reason I am willing to build a reference on top of the rest of it.