The agent-skill attack surface spans the whole lifecycle, not just runtime
A July 2026 study maps agent-skill risk across five stages — admission, retrieval, planner selection, execution, evolution — and shows most defenses only guard one of them.
What is this?
“Agent skills” are reusable capability packages — a SKILL.md file of natural-language instructions plus optional scripts — that an LLM agent retrieves and runs to accomplish a task. Most security work on them has concentrated on two things: prompt injection inside the instructions, and what the code does when it executes. A study published on July 15, 2026 — Agent Skill Security: Threat Models, Attacks, Defenses, and Evaluation by Sanket Badhe and Priyanka Tiwari (arXiv:2607.13987) — argues that this framing is too narrow. It introduces SkillSec-Eval, a lifecycle-aware framework that decomposes the skill ecosystem into five operational boundaries — repository admission, semantic retrieval, planner selection, execution, and skill evolution — and, across an empirical evaluation of 327 real-world skills, finds that exploitable weaknesses appear at every stage, not only at runtime.
The practical takeaway is that a skill can be individually benign as source code and still cause harm because of when it is chosen and how it changes over time. Guarding only the execution step leaves four other stages unmonitored.
How it works
Walking the lifecycle makes the gaps visible. Each boundary is a place where an attacker’s control over a skill can diverge from what a scanner or reviewer last checked.
Repository admission. Public skill registries typically accept a SKILL.md and a fresh account with no signing and no review. This is the stage the existing supply-chain literature covers best, and it is where malware and typosquatted entries enter the pool.
Semantic retrieval. Agents rarely load every skill; they retrieve candidates by embedding-similarity between the user’s task and each skill’s self-description. A skill whose description is written to match a broad range of tasks can therefore be surfaced for requests it has no business serving — a retrieval-layer analogue of SEO poisoning, where the metadata, not the code, is the lever.
Planner selection. Once a shortlist is retrieved, the planner model decides which skill to actually invoke, again leaning heavily on names and descriptions. Misleading-but-plausible naming can bias that choice toward the attacker’s package over a legitimate one.
Execution. The familiar runtime stage: the selected skill runs with the agent’s full authority — shell, file system, environment variables and credential files, and outbound network. This is where a payload finally acts.
Skill evolution. Skills are updated. A package that was reviewed and trusted at version 1 can be quietly rewritten later (a “rug pull”), or it can fetch its real instructions from an attacker-controlled URL at run time, so the artifact that passed review is not the artifact that runs.
None of these require a novel exploit primitive. The point of the framework is that the trust decision made at admission or during a scan does not automatically hold at retrieval, selection, or after an update.
Why it matters
Agent skills now sit inside coding assistants and personal agents used by large developer populations, and the tooling reflects the runtime-first assumption: sandboxes constrain what a skill does when it runs, and static scanners inspect SKILL.md at install time. Both are worth having, and both are blind to selection and evolution. A skill can pass an install-time scan, then be promoted into tasks through a crafted description, or mutate after it has earned trust. Treating the problem as “is this file malicious right now?” misses “will this file be chosen, and is it still the file I approved?” — which is why a lifecycle view matters for anyone operating an agent that pulls from a shared skill pool.
Defenses
There is no single control; map defenses to each boundary.
Admission. Prefer signed skill publications and reviewed authors. The OWASP Agentic Skills Top 10, published April 27, 2026, recommends treating each publication as a cryptographically verifiable event (for example, Merkle-root signing) plus registry scanning. Reject week-old accounts, typosquatted names, and republished identifiers.
Retrieval. Vet a skill’s description and metadata separately from its code, since the description drives selection. Constrain the retrieval corpus to an allowlist of reviewed skills rather than an open marketplace.
Selection. Keep the exposed skill set minimal and least-privilege. Gate invocation of a newly selected skill behind an approval step instead of auto-running it, so a mis-selected package cannot act silently.
Execution. Sandbox skill execution, run the agent with least privilege, and constrain egress so a compromised skill cannot reach an exfiltration endpoint. Treat SKILL.md as untrusted instructions: do not obey a skill that tells the agent to disable safety checks, decode-and-run opaque blobs, or curl | bash.
Evolution. Pin versions, re-scan on every update, detect runtime instruction-fetching, and monitor for behavioral drift so a trusted skill that changes is re-evaluated rather than grandfathered.
Status
| Item | Detail |
|---|---|
| Primary source | Agent Skill Security, arXiv:2607.13987 [cs.CR], July 15, 2026 |
| Framework | SkillSec-Eval — five lifecycle boundaries; empirical eval on 327 real-world skills |
| Reference standard | OWASP Agentic Skills Top 10, April 27, 2026 |
| Related taxonomy | Towards Secure Agent Skills, arXiv:2604.02837 |
| Scope | Agent-skill ecosystems (Claude Code, Cursor, OpenClaw and similar) |
| Status | Systematization + evaluation; defense is lifecycle-wide process, not a single patch |