Remote script execution is exactly what it sounds like: a skill fetches a script or binary from an external location at runtime and executes it, most commonly through a pattern like piping a curl or wget download straight into bash or sh. It's one of the oldest tricks in software supply chain attacks, and agent skills give it a new, more trusted delivery vehicle.

Why this pattern is so dangerous

The skill installed on disk can look completely clean. Because the actual payload isn't fetched until execution, a static review of the package at install time has nothing incriminating to find. The dangerous code doesn't exist yet as far as a pre-deployment scan is concerned. It only shows up the moment the skill runs and reaches out to download it, which means the window between "looked safe" and "did something harmful" can be entirely invisible to anyone reviewing the source ahead of time.

This is also why remote script execution pairs so easily with persistence and credential theft. Once a downloaded script executes with the same permissions as the agent and the user running it, it can do essentially anything the user could do manually: install further tooling, modify configuration, or reach for credentials directly.

What legitimate developer tooling looks like versus what doesn't

Development workflows use curl and installation scripts constantly, and that legitimate usage is exactly why this category produces so many false positives for naive scanners. A curl command hitting localhost in a "testing locally" section of documentation is not exfiltration. A read-only curl pulling official public documentation is not remote code execution. The distinguishing signal isn't the presence of curl, it's the combination of an external, unfamiliar destination with a pipe directly into a shell interpreter, especially when that destination has no clear connection to the skill's stated purpose.

Remote code-fetch behavior correlated with execution of a downloaded script through shell and interpreter commands is treated as one of the highest-confidence indicators of executed malicious behavior in sandboxed analysis, not merely blocked intent.

How this gets caught safely

A sandbox built for this specifically instructs the agent to skip any command that would fetch and execute unknown remote code, then records the exact command and the reason it was skipped. That gives you the evidence, a documented attempt at remote script execution, without ever actually running the potentially harmful payload. Static detection complements this by flagging the textual pattern itself: a fetch command piped directly into a shell or interpreter, or a call to exec() on content just pulled from an HTTP response.

FAQ

Is every curl-to-bash pattern in a skill malicious? No, and this is one of the more common sources of false positives in the category. Legitimate installation instructions for real developer tools frequently use this exact pattern. Destination and context matter more than the syntax alone.

What makes this riskier than a typical malicious dependency? A malicious npm or pip package still has to go through some form of publication and review, even if imperfect. A remotely fetched script can change on the server side at any time after a skill has already passed review, meaning the artifact that was approved is not necessarily the artifact that eventually executes.

Can this be blocked without breaking legitimate skills? Yes, largely through network allowlisting and by keeping the sandbox's execution scoped to safe, local, non-destructive workflows so genuinely necessary remote fetches can be evaluated deliberately rather than executed blind.

Related reading: "Backdoors That Outlive the Session: Persistence in Agent Skills," "When Trusted Isn't: Understanding MCP Impersonation"