T01 · Skill Instruction Hijacking
- Location
SKILL.md:7- Finding
Global Agent Role and Instruction Hijacking
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is not plainly malicious, but it overreaches by applying itself to all coding work and repeatedly recommends running an unpinned external scanner in local and CI environments.
Install only if you want a broad CTO-style engineering standards skill and are comfortable with it affecting many coding tasks. Do not copy the scanner commands as written for CI, hooks, or home-directory scans; pin and vet the scanner version, run it with least privilege, and scope scans to files you intend to inspect.
SKILL.md:7Global Agent Role and Instruction Hijacking
SKILL.md:113Execution of an Unpinned Third-Party Package Through uvx
The skill description claims it should trigger for architecture, hiring, security, product planning, any coding task, and even installing or reviewing other skills or MCP servers. Such broad activation criteria create overreach and prompt-surface expansion, increasing the chance the skill influences unrelated tasks and overrides narrower, safer context-specific instructions.
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
- name: Install uv
run: |
# Install uv using your platform package manager or approved internal image.
# Example (Ubuntu): sudo apt-get update && sudo apt-get install -y uv
uv --version
- name: Scan agent skills
run: uvx snyk-agent-scan@latest --skills .claude/skills/ --json
The skill imposes a mandatory technology/language policy ('TypeScript for all JS/TS work... No exceptions') without user opt-in. This can distort user intent, force toolchain choices, and cause the agent to disregard project constraints or safer alternatives in environments where different languages, standards, or compliance requirements apply.
The skill repeatedly instructs users to execute uvx snyk-agent-scan@latest, which pins only to the moving latest tag rather than an immutable version or digest. That creates a supply-chain risk: a future compromised or malicious release would be automatically trusted and executed during security scanning workflows, including CI environments.
Using uvx snyk-agent-scan@latest --skills for a full scan implicitly downloads and runs the newest package version at execution time. In a security-sensitive workflow, that undermines trust by making the scanner itself a mutable dependency that could become the attack vector.
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
# Full machine scan — agents, MCP servers, and skills
uvx snyk-agent-scan@latest --skills
# Scan Claude Code skills
uvx snyk-agent-scan@latest --skills ~/.claude/skills
# Scan Codex CLI skills
The command shown for scanning Claude Code skills relies on @latest, so the exact code executed is not stable or reviewable over time. That is especially risky because the skill presents this as a mandatory security control, increasing the likelihood of repeated execution in trusted contexts.
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
# Scan Claude Code skills
uvx snyk-agent-scan@latest --skills ~/.claude/skills
# Scan Codex CLI skills
uvx snyk-agent-scan@latest --skills ~/.codex/skills
# Scan a specific skill before installing
The Codex CLI skill scan example also uses a mutable latest dependency. Because the command is meant to inspect local skill directories, a compromised scanner could gain access to sensitive local configuration and metadata while appearing to perform a defensive action.
The example for scanning a specific skill before install still fetches @latest, so the recommended safety check itself is untrusted. This is dangerous because users are likely to run it precisely when evaluating whether content is safe, which can invert the trust boundary.
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
# Scan a specific skill before installing
uvx snyk-agent-scan@latest --skills /path/to/skill/SKILL.md
# Scan project-level skills
uvx snyk-agent-scan@latest --skills .claude/skills/
uvx snyk-agent-scan@latest --skills .agents/skills/
The project-level scan example uses @latest, introducing a mutable execution path into repository workflows. In teams adopting this skill broadly, that can propagate a supply-chain weakness across many developer environments and automation pipelines.
This second project-level scan command repeats the same unpinned package execution pattern. Repetition in multiple examples increases the chance that users copy the unsafe form into scripts and CI, turning documentation into durable insecure automation.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
uvx snyk-agent-scan@latest --skills .claude/skills/
uvx snyk-agent-scan@latest --skills .agents/skills/
# Inspect MCP tool descriptions without verification
uvx snyk-agent-scan@latest inspect
# JSON output for CI/CD integration
Even the inspect example uses @latest, meaning metadata-inspection workflows also trust mutable remote code. While the immediate privileges may be lower than a full CI run, it still expands the supply-chain attack surface and normalizes unsafe package execution.
The JSON-output example is positioned for CI/CD integration, so @latest here is especially risky: automated pipelines would repeatedly execute a moving target in privileged, networked environments. Attackers often target build and scanning infrastructure because it has broad access and high trust.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- name: Install uv
run: |
# Install uv using your platform package manager or approved internal image.
# Example (Ubuntu): sudo apt-get update && sudo apt-get install -y uv
uv --version
- name: Scan agent skills
run: uvx snyk-agent-scan@latest --skills .claude/skills/ --json
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
# Install uv using your platform package manager or approved internal image.
# Example (Ubuntu): sudo apt-get update && sudo apt-get install -y uv
uv --version
- name: Scan agent skills
run: uvx snyk-agent-scan@latest --skills .claude/skills/ --json
- name: Scan MCP configs
run: uvx snyk-agent-scan@latest --json
The GitHub Actions example directly embeds uvx snyk-agent-scan@latest, which is a classic pipeline supply-chain weakness. Because this is copy-paste-ready automation, it materially increases the chance of insecure adoption at scale.
The MCP config scan step also uses the mutable latest tag in CI. This broadens risk across both skill and MCP scanning and could allow a malicious package update to exfiltrate repository or environment data from automation runners.
The pre-commit hook invokes uvx snyk-agent-scan@latest --skills --json, so every developer commit may execute freshly resolved remote code. That creates a high-frequency supply-chain exposure on developer endpoints, not just in CI.
Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.
### Rules for Skill Installation
1. **Never install a skill without scanning it first.** Run `uvx snyk-agent-scan@latest --skills /path/to/SKILL.md` before copying to `~/.claude/skills/` or `~/.codex/skills/`.
2. **Review the SKILL.md manually.** Read the file. Check for suspicious instructions, external URLs, or encoded content.
3. **Check bundled scripts.** If the skill includes `scripts/` or executable code, audit every file.
4. **Verify the source.** Only install skills from trusted repositories. Check stars, contributors, and commit history.
The installation rules explicitly instruct users to run @latest before trusting a skill. Because this is framed as mandatory security hygiene, it can strongly encourage execution of an unpinned third-party package at the exact moment users are trying to reduce risk.
The playbook instructs users to run uvx snyk-agent-scan@latest --skills, which fetches and executes the latest package version at runtime rather than a pinned, reviewed release. That creates a supply-chain risk: if the package is compromised, typo-squatted, or updated with breaking or malicious behavior, users following the guidance may execute untrusted code on their systems.
This line repeats the same unsafe installation guidance, telling users to run uvx snyk-agent-scan@latest --skills /path/to/skill. Using @latest in a security-sensitive context is especially risky because this skill is explicitly meant to be used when installing or reviewing other agent components, so it can normalize execution of an unpinned third-party package during a trust decision.