One Package, Two Execution Paths
An agent skill becomes a security problem through a sequence of handoffs, not through a single suspicious line. This chapter follows a skill from a community listing into a local agent environment, asking who controls each transition and how the package can influence both the agent’s decisions and the host system. The result is a practical distinction between code execution and instruction-level influence—the distinction needed to test a skill’s public contract instead of trusting its packaging.
From a registry listing to local authority
The sequence begins before any code runs. A publisher prepares a package that presents a capability: perhaps a calculator, a document workflow, or a specialized development routine. A community registry indexes that package so a user or an agent can find it. The registry makes discovery easier, but discovery is not the same as endorsement. In the January 2026 snapshot studied by Liu and colleagues, the large public registries were aggregators of skills hosted in public repositories, and no AI-agent vendor had a centralized inventory of everything deployed.
The next transition is installation. The user, an installer, or a platform adds the skill to the environment in which the agent operates. This is the point at which a descriptive artifact becomes an available capability. The host framework may load its persistent instructions, expose its entry points, and allow the skill to call local helpers. In the threat model, the skill does not need to break into the machine after this transition. It is already operating within the privileges the agent has been granted.
Invocation completes the path into behavior. The agent reads the skill’s description and instructions, relates them to a request, and decides whether to use the capability. If the skill includes helper code, the agent or framework may invoke that code on the local system. The helper can then interact with files, processes, network services, or credentials according to the permissions of its host. The precise mechanics vary by platform, but the trust question is stable: what was merely listed is now available to a component that can act.
The operating sequence can be separated into five ownership questions:
- Who published the artifact? The publisher controls the package’s content and the claims attached to it.
- Who made it discoverable? The registry controls indexing, presentation, and whatever identity or reputation signals it supplies.
- Who admitted it? The installer or framework determines whether the package enters the local environment and what permissions are visible at that point.
- Who interpreted its instructions? The agent converts natural-language guidance into a plan of action, subject to the host’s rules and its own behavior.
- Who supplied the authority? The runtime exposes the files, credentials, network, and tools that make the plan consequential.
These owners are connected, but their responsibilities are not interchangeable. A registry can remove a package after disclosure; it cannot retroactively make an earlier installation safe. A framework can provide a permission prompt; it cannot tell from a publisher name alone whether the package’s behavior matches its description. A user can decline installation; that decision is meaningful only if the package’s relevant actions are visible. A skill can be signed or hosted in a reputable place; neither fact, by itself, proves what the agent will cause it to do.
The important failure condition is therefore a mismatch between stages. The public listing says “capability,” the installer treats that as “authorization,” and the runtime supplies broader access than the user understood. The agent then acts as the bridge between the package’s prose and the host’s tools. Following the path makes clear why a software-supply-chain analysis must include the registry and the agent loop, not just the files in a repository.
The distinction between availability and authorization is easy to lose because the installation experience is often designed to be convenient. A user searches for a name, adds a package, and expects the agent to handle the rest. Yet a registry entry can tell the user that a skill exists without telling them what information it will reach, which helper it will invoke, or which instructions it will treat as binding. The missing step is not necessarily another warning dialog; it is a trustworthy account of the boundary being crossed. Without that account, the user is asked to approve a capability in the abstract while the runtime later supplies concrete authority.
The diagram below is therefore a control-flow model, not a claim that every platform implements the same interface. It identifies the handoffs that must be made visible. A skill can fail before invocation if its publisher identity is unclear or its description is incomplete. It can fail at installation if the framework admits it without a meaningful view of permissions. It can fail during planning if its instructions steer the agent away from the user’s request. It can fail during helper execution if the runtime exposes data or network access unrelated to the advertised function. These are different failure conditions, even when the user experiences them as one misleading installation.
The sequence has a normal ending and a dangerous one. In the normal path, the skill’s declared purpose, requested permissions, agent instructions, helper behavior, and resulting action remain aligned. In the dangerous path, the package crosses an unexamined boundary: a hidden helper reaches data unrelated to the stated task, or an instruction changes the agent’s choices without giving the user a clear opportunity to understand or refuse. The same installation event can enable either path.
Why the document is part of the control plane
In ordinary software, documentation tells a human how to use a program. An agent skill’s documentation can also tell the agent how to behave. That does not mean every sentence is an operating-system command. It means the sentence is an input to a system that chooses tools and actions. The distinction matters: executable code acts through the host runtime, while natural-language instructions act through the agent’s interpretation of the task.
The paper places skills alongside several other extension mechanisms to make this difference precise. In-context instructions steer an agent without directly executing code, but they remain vulnerable to prompt injection. Function calling gives a model structured tool definitions, with the host application controlling what those tools expose. The Model Context Protocol generalizes external tool integration through a protocol in which code runs on separately administered servers. A skill combines persistent instructions with optional local code, so the authority boundary is located in a package that is both read by the model and available to the local environment.
That coupling creates two paths through one package. Consider a skill advertised as a calculator. A helper might perform an undisclosed network operation or open an interactive shell; that is a code-level deviation from the public function. The instruction document might instead tell the agent to conceal a side effect, skip a confirmation, or treat the skill’s own directions as more important than the user’s. That is an instruction-level deviation. The specific payload is not the central issue. The central issue is that a human can approve a calculation while the agent receives a different set of behavioral instructions and the runtime receives a different set of capabilities.
The two paths also differ in what evidence can reveal them. Code inspection can find suspicious file access, remote execution, or transmission patterns, but it may not understand whether an operation is authorized by the described function. A semantic review can notice coercive or secrecy-oriented language, but it cannot prove what a helper does when invoked. Runtime monitoring can observe network and file effects, yet a short or narrow test may not trigger a conditional instruction or a delayed action. The security boundary is not one scanner; it is the agreement among description, code, agent behavior, permissions, and observed effects.
This creates a hidden coupling between the agent’s planner and the host’s executor. The planner decides which capability appears relevant; the executor gives the selected helper the environment in which it can act. A document-level instruction can therefore be a trigger for a code-level effect without containing the effect itself. Conversely, a helper can introduce a side effect that the agent never explains to the user. In both cases, reviewing only the last action misses the transition that made it possible.
The comparison with server-side tools makes the location of that coupling clearer. When tool code runs on a separately administered service, the service owner and the host application occupy more distinct administrative positions, even though other risks remain. With a local skill, the package, the agent, and the host runtime are closer together. That can make useful workflows faster to install and easier to personalize, but it also means that a mistake in the package’s instructions can meet the machine’s existing authority with little distance between them. The design succeeds only when the framework makes that relationship explicit enough to inspect and constrain.
This is why the phrase “the skill has access” needs refinement. Access can mean at least three things. The helper may have operating-system access because it runs under the agent’s local privileges. The agent may have tool access because the framework exposes commands or APIs. The instruction document may have influence because the agent treats it as guidance when planning the next step. A review that sees only one of these forms can mistake partial visibility for containment.
The same distinction helps explain why a suspicious operation is not automatically malicious. A penetration-testing utility may legitimately inspect a network. A credential manager may need to handle secrets. A document workflow may need to write files. The study therefore defines maliciousness through observed behavior and apparent intentional abuse, not through the mere presence of a sensitive operation. The relevant test is contextual: does the behavior serve the stated capability, stay within the user’s authorization, and remain visible to the people responsible for the environment?
A well-designed skill should make those answers inspectable. Its publisher should state what it does and what permissions it needs. Its registry should preserve enough identity and provenance for a user to know what they are installing. Its framework should constrain the available tools and make exceptional access visible. Its runtime should make effects observable and, where possible, reversible. Its instructions should help carry out the user’s request, not quietly redefine the request or the user’s right to know what happened.
For the reader, this translates into a simple but demanding audit question: can each transition be explained in the same language as the public promise? If the answer is yes, the package may still contain ordinary bugs, but its authority is at least legible. If the answer is no, the ambiguity is itself a security signal. The publisher may have omitted a capability, the registry may have flattened an important distinction, the framework may have hidden a permission, or the agent may have been steered by text that a human would not treat as an instruction. The source of the mismatch determines who must fix it.
This model also avoids an unhelpful binary between “trusted” and “untrusted.” A skill can be trusted for a narrow calculation but not for access to a credential store. A publisher can be identifiable while a particular release remains unsafe. A framework can constrain helper execution while still allowing instruction-level manipulation. Trust is therefore a set of claims about a package in a particular environment, not a permanent property attached to its name. The study’s later measurement uses this logic by checking observed behavior against the function the skill presents.
The public contract is something to test
The public description is best understood as a contract, but not as a guarantee. Contracts become useful when another system can compare them with behavior. For an agent skill, that comparison has several dimensions: the declared purpose versus the tools it invokes; the requested permissions versus the data it touches; the documented destinations versus the network connections it makes; and the agent’s visible interaction versus any instructions that suppress questions or notifications.
The USENIX study operationalizes this idea by comparing documented functionality with observed runtime behavior. It calls an undocumented capability a “shadow feature” only when two researchers judged that it could not be inferred from the public documentation. That term is valuable because it names a mismatch without assuming that every mismatch has the same severity. A silent log file, an unexpected endpoint, a conditional trigger, and a credential transmission do not have identical consequences, but all should prompt the question: where did this behavior enter the trust model?
The comparison also changes how failure is diagnosed. If a skill’s helper is safe in isolation but its instructions cause the agent to invoke it for an unrelated purpose, the problem is not solved by reviewing the helper alone. If the instructions are ordinary but the helper downloads another payload at runtime, reading the Markdown is insufficient. If the public contract is accurate but the host gives the skill unrestricted access to secrets, the framework has contributed to the exposure even when the publisher is honest. Causal analysis must follow the whole route.
The next chapter turns this operating model into an evidence question. The existence of two execution paths explains why suspicious patterns appear in both code and prose; it does not tell us how many cases were confirmed or how representative they are. To answer that, the study used a staged funnel that separates a pattern worth investigating from behavior strong enough to support a maliciousness judgment. That distinction is the first test of whether a large number is telling us about the ecosystem—or merely about the scanner.