From skill metadata to production dependencies: where agent trust actually changes hands

Skills are commonly treated as prompts with optional scripts. That framing misses what happens after an agent reads a file and before a user sees a result. A skill can determine which tool is selected, which command is trusted and which hostname is copied into production software. Three current studies plus a real deployment incident reveal different boundaries; conflating them would hide the failure mode.

Air Security traced an official Render deployment skill to a domain its provider did not own. A coding agent used the skill as intended, copied the hostname into service code, and made the mistake persistent in deployment configuration. Researchers who registered the domain received real requests carrying bearer headers. This was not proof of malicious authorship, nor a hypothetical prompt jailbreak. The unsafe statement entered running software as an apparently authorized dependency. Patches to source guidance do not retrospectively rewrite deployed services.

The MetaCascade experiments test an earlier boundary. They alter skill metadata to influence retrieval and final choice in two agent systems. Their headline rates measure selection of the targeted malicious skill, not successful exploitation. An integrity gate on script code would not necessarily repair a search result or description that already redirected the agent toward the wrong capability.

The Ciphered Skill Injection study puts harmful directives behind a decoding task in an untrusted skill. Some models recover the text, and some follow it. The researchers distinguish those outcomes because understanding an instruction is not permission to execute it. The study does not show a real distributed package or victim, and the reported peak rates are setting-dependent.

A related ZTAC prototype argues that the final check should bind to the actual file, command, endpoint and grant consumed, not a name presented earlier. In its limited suite, 2 of 74 attacks succeeded and both used an allowed destination to carry secrets. This residual failure is essential: even a complete broker cannot infer that every byte crossing a permitted boundary is authorized.

These are not four parts of one attack. They are evidence of four distinct transition points: source guidance to deployed dependency, metadata to selection, decoded text to instruction, and requested name to executed object. Audit claims should therefore say which point they test and where their visibility ends. Security cannot be inferred from an official badge, a plausible response, or a successful application deployment.

Supply-chain remediation must follow the transition that created the effect. A deployment skill can require replacing generated application configuration after its upstream text is fixed. A metadata selection attack calls for checking who controls discovery and ranking. An encoded instruction requires separating parsed data from executable orders. These are different inventories and tests, even though all begin with files described as agent skills.

The Render case is an observed propagation of a mistaken dependency into live applications. MetaCascade and Ciphered Skill Injection are controlled attack evaluations, while ZTAC demonstrates a prototype enforcement boundary with documented residual escapes. That difference in evidence class matters more than a single composite "skill safety" score. A trustworthy registry cannot certify downstream effects it cannot see, and an execution broker cannot retroactively correct code generated from a flawed dependency description.