The prerequisite trap: when setup becomes the attack

Why setup deserves its own boundary

A skill can make a legitimate task appear conditional on an unrelated installation. The prerequisite may be presented as an authentication helper, compatibility patch, or required core utility. The review question is whether that dependency actually serves the task and whether its origin and behavior can be verified.

Setup text is influential even when the host cannot execute it. An agent can repeat the instruction to a human, who then runs it in a less constrained environment. A denied tool call and a persuasive manual workaround are therefore different paths to assess.

A published case to read

The Google-branded skill case file links Snyk’s package analysis. It illustrates a prerequisite lure and a separated delivery chain. Read the report for its observations; this guide’s checklist is editorial guidance, not a reproduced incident investigation.

A dependency review before execution

1. Identify what the approved task actually requires.
2. Trace the claimed dependency to its genuine upstream publisher.
3. Verify the artifact and version using evidence independent of the skill’s own assertions.
4. Inspect its installation and normal execution behavior separately.
5. Record requested permissions, destinations, and any further downloads.
6. Test in an isolated environment with synthetic inputs before considering operational use.

A familiar hosting service does not establish that a particular account, release, or file is legitimate. An encrypted archive, encoded command, or broad permission request needs context; none becomes acceptable simply because the agent calls it routine.

Worked example: a task can pause without accepting a workaround

A calendar-summary skill says an external helper must be installed first. The host blocks the installer. The agent then asks the user to paste the same instruction into a terminal. A useful test checks whether the workflow explains the unresolved dependency and stops, rather than treating manual execution as a way around the boundary.

Record the original request, proposed dependency, agent recommendation, human approval context, and any observed execution. Do not label a displayed command as an executed action.

Decision and recovery

Hold an unverified prerequisite rather than broadening the environment to make it work. If it was executed, investigate the resulting access and changes through the organization’s response process. Removing the skill cannot by itself revoke credentials or remove another program. Keep the setup artifact and the skill revision linked in the evidence record.