When Agent Skills Inherit the Authority of the Agents That Run Them

A developer asks an AI coding agent to set up a project. The agent finds a reusable skill containing the procedure, loads its instructions, and follows them. One instruction directs it to run a command through a shell that the agent is already authorized to use.

The skill never needed a password, API key, or identity of its own. The authorized agent supplied the authority.

In July 2026, researchers investigating look-alike Paperclip skills found an attack chain that used agent instructions to trigger malware installation. A seemingly legitimate skill directed the agent to a secondary setup document, which led to a remote Node payload that collected credentials and transmitted them to attacker infrastructure.

The incident exposed a security problem that recent research had already begun measuring: reusable agent instructions can become part of the execution path of systems that have access to shells, files, credentials, and external services.

Agent skills package reusable procedures for AI agents. Under the open Agent Skills specification, a skill contains a SKILL.md file with metadata and instructions and may also include scripts, reference documents, assets, and other resources.

Research published since late 2025 has found malicious skills both experimentally and in public ecosystems. A February 2026 study examined 98,380 skills from two community registries and behaviorally confirmed 157 as malicious. The researchers associated those skills with 632 vulnerability instances across the taxonomy used in their study.

How the Mechanism Works

The basic path is:

skill discovered → instructions loaded → agent plan changes → existing tool selected → action executes

The important security transition occurs between instructions and tool use. Natural-language content is consumed by the same planning system that decides whether to read files, execute shell commands, access connected services, or invoke other available capabilities.

This has a strong resemblance to a confused-deputy problem. The comparison is not exact because the skill generally is not an authenticated security principal. Instead, untrusted instructions influence a more privileged actor into exercising capabilities available to it.

The attack surface can also extend beyond the primary skill file. Skills may reference scripts and secondary documents that are loaded later. In the Paperclip campaign documented by Zenity, the malicious installation path lived in a secondary setup-installation.md document. The agent was directed there when installation became relevant, and the instructions subsequently led through remote retrieval and execution to credential collection and exfiltration.

Datadog identified a related implementation-specific problem in Claude Code. Dynamic-context commands using ! can execute while skill content is being prepared, before the resulting content reaches the model. In its demonstration, Datadog used this path to retrieve an existing GitHub authentication token and send it to a controlled destination. This matters because a control that evaluates only what the model eventually sees cannot inspect an operation that has already executed during preprocessing.

Analysis

The Paperclip campaign turns what could otherwise look like a prompt-security problem into a supply-chain problem because the malicious instructions were delivered through a reusable artifact and its distribution path.

Controlled research points in the same direction. Qu et al. showed that malicious logic did not have to appear as an explicit instruction: it could be placed inside examples and configuration templates, then enter generated code when an agent treated those materials as reference implementations. Yang et al. separately found high susceptibility to malicious skill files across thousands of controlled runs against Gemini CLI and Qwen Code.

Taken together, the registry study and controlled experiments show both observed malicious artifacts and repeatable exploitation paths, while stopping short of establishing ecosystem-wide or production compromise rates.

Implications for Enterprises

The Zenity and Datadog findings point to three concrete control requirements.

First, review the full resource graph of a skill. Inspection should follow references from SKILL.md into secondary documents, scripts, packages, installation instructions, and remotely retrieved artifacts. Zenity's malicious path depended specifically on content outside the primary skill file.

Second, separate skill trust from tool authority. Approving a reusable instruction package should not automatically establish that every shell, filesystem, network, CLI, or MCP action it induces is acceptable. Runtime permissions and sandbox boundaries still determine how far malicious instructions can reach.

Third, log the execution chain. Audit records should connect skill activation to subsequent tool calls, child processes, network activity, and authorization decisions so that investigators can reconstruct how an apparently authorized action was initiated.

These controls matter at update time as well as installation. Zenity documented a time-of-check/time-of-use problem in the Paperclip campaign: listings accumulated displayed installs while skill files were still benign copies, surrounding repository content changed later, and the skill documents themselves were subsequently weaponized. Approval of an identity or repository at one point in time therefore does not establish the integrity of later content.

Risks and Open Questions

The portable Agent Skills specification defines the structure and loading of skills, but it does not standardize mandatory cryptographic signatures, content digests, or an authenticated provenance chain. Products and distribution systems can add controls outside the format, and runtime permission models also vary.

The unresolved attribution problem is straightforward: security teams need to know which version of which reusable instruction caused an action to enter an agent's execution path. As skills become reusable components of agent behavior, that provenance becomes part of the security boundary.

Further Reading

• Agent Skills Specification
• Yang et al., Towards a Risk Assessment of Malicious Skill Files in Coding Agents
• Liu et al., Malicious Agent Skills in the Wild
• Qu et al., Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems
• Datadog Security Labs, Malicious Coding Agent Skills and the Risk of Dynamic Context
• Zenity Labs, Attackers Target Agents via The Skill Supply Chain