What should teams do first when a skill requests a download or shell command?

Why the first move is to freeze execution and inspect the request

The safest first step is to stop the fetch-and-run path before anything reaches the host. A skill that asks for a download or shell command can still introduce a payload, redirect execution, or alter system state, so the request itself needs scrutiny before it is treated as routine automation.

This is less about distrusting every skill and more about refusing to let a proposed action bypass review. If the command is syntactically valid, it can still be operationally unsafe because the target, arguments, working directory, environment variables, and privileges all shape what actually runs.

What to inspect before allowing any download or shell action

Review the download target, the command syntax, and the execution context as a single control decision. The target should resolve to an expected source, the syntax should match the intended operation, and the context should be limited to the minimum privileges and environment needed for the task.

Checksums or signatures matter when the downloaded file is meant to be trusted, but they are only useful if you know what artifact you expected in the first place. A legitimate-looking prompt can point to the wrong binary, a swapped script, or a staged second command that changes behaviour after the initial fetch.

Where a command is involved, pay attention to path resolution, shell expansion, pipes, command substitution, and any implied use of inherited credentials or local state. The same visible command can do very different things depending on which shell executes it and which directories, tokens, or environment values it can see.

How to handle untrusted skill requests without breaking the workflow

Use a review-first pattern: approve only the exact file, command, and context you intended, and require a human decision when the action crosses a trust boundary. If the skill cannot explain why it needs network fetch, local execution, or elevated permissions, treat that as a signal to pause rather than to auto-confirm.

When possible, separate retrieval from execution. Download to a staging location, inspect the artifact and its metadata, and only then decide whether to run it. That reduces the chance that a skill can convert a routine helper step into an uncontrolled system change.

For commands that must be allowed, constrain them to a narrow allowlist of paths, arguments, and permitted actions. A command can be safe in one context and unsafe in another, so the verification step should be tied to the exact execution environment, not just the text of the request.

Risk and Threat Considerations

Fetch-and-run requests are attractive because they collapse review, retrieval, and execution into one action. That creates a clean path for payload staging, unauthorized system modification, and abuse of any trust already granted to the skill or its runtime.

Failure mechanism: The request redirects a trusted automation path toward an attacker-controlled or incorrect artifact, then uses shell semantics or inherited privileges to execute code with more access than intended.

Impact: A single approved request can produce code execution, credential exposure, persistence, or changes to local state that are difficult to distinguish from normal automation after the fact.

Practitioner Guidance

What to verify: Confirm the exact source URL, expected filename or hash, and the command’s privilege boundary before permitting execution. If any part of the request is ambiguous, default to manual review rather than trying to infer intent from the prompt.

Decision rule: If the skill requests both download and execution in one step, split the action and require an explicit check of the artifact before any shell invocation. If the request depends on elevated privileges, treat that as a separate approval condition, not a normal extension of the task.

Practitioner takeaway: The first control is not to “run it carefully”, it is to prevent an unverified artifact or command from entering an execution path at all.

Related resources from NHI Mgmt Group

• What breaks when an agent only applies sandboxing to the first command in a model-generated shell string?
• What should security teams do first when a widespread shell exploit exposes Unix systems to remote command execution?
• Should organisations prioritise tool scoping or skill governance first for AI agents?
• How should organisations respond when command traffic is hidden inside normal HTTPS requests?