An agent skill is a folder: a markdown file of instructions, some metadata, and optional scripts. Agents load them to specialise, and developers pull them from marketplaces and shared repos with about the trust you give a README — and none of the review you give a dependency. This paper wrapped 471 real attack commands in benign-sounding skills and pointed two enterprise coding agents at them across 5,629 runs. One committed to running the hidden command in 96% of them. The other in 74%. Across every run, the agents named the payload as a safety concern 1.99% of the time.
The interface being attacked is the one you already use. A skill is a self-contained package — a specification file with metadata and instructions, plus optional executable scripts — that an agent loads dynamically to change its own behaviour and permissions before it starts work. The attack does not need a vulnerability. It needs the agent to do what the folder tells it, which is the entire point of the folder. Flip between what a reviewer skims and what is actually in the package.
Two design choices do the work. The visible caption is generated under constraints — present tense, under twenty-five words, no security vocabulary at all, never restate the path — so a credential harvester ends up described as "Initializing project metadata". And the payload is framed as a mandatory preflight step, a real DevOps convention, creating a logical dependency: the agent is told it must finish environment setup before it is permitted to touch the actual task. It is not tricked into disobeying. It is obeying.
The commands are not invented. They come from a public library of real adversary behaviours, each already mapped to a category in the standard attack taxonomy, so the results break down by what the command was actually trying to do. If agents had any instinct here you would expect it to show up as a gradient — permissive about reading local files, cautious about sending data outbound. There is a gradient. It is nowhere near steep enough. Step through the categories.
The one genuine signal in the whole table is the shape of the second agent's curve: it drops from 87.2% on initial access to 38.5% on moving data off the machine. Something in it treats outbound networking as out of scope for a local coding task. The other agent shows no such gradient at all — it sits above 93% on every single category, including exfiltration. And "better" here still means one in three attempts succeeds.
An exploitation rate of 96% leaves 4% that did not run the command, and it is tempting to read that residue as the guardrail working. It is not. The authors classify what actually happened in every non-exploited run, and the overwhelming majority are the agent simply not engaging with the preflight instruction at all — running out of turns, wandering off, or mentioning it without ever committing. Explicit safety refusals are a rounding error. Switch agents.
Across all 5,629 runs, safety-based refusal appears 112 times. That is the number to carry into any conversation about whether a model's built-in judgement is a control. It is not one — it is a preference that fires occasionally, and the one agent that showed any real resistance did it by deciding the request was off-task, not by deciding it was dangerous.
A claim like "96% exploited" is worth exactly as much as the process that produced it, and this is a case where an eager judge could inflate the result enormously. The pipeline is built to push the number down: four separate mechanisms exist to throw out a claimed success. Toggle each one to see what it removes.
The threat model is not exotic. It assumes you pull skills from public marketplaces, open-source repos or internal sharing, and that your agent already has shell and repository permissions — which is the default configuration people run. So the exposure is just arithmetic on two numbers you know: how many skills you have installed, and how many of them anyone opened the scripts of.
Note where the useful controls sit: none of them are prompting. They are the boring ones — capability reduction, sandboxing, provenance, and reading the scripts before you install them. A guardrail that lives inside the model is downstream of an instruction the model has already decided to obey.