T01 · Skill Instruction Hijacking
- Location
SKILL.md:65- Finding
Automatic Scope Expansion Can Trigger Unapproved External Actions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 65-73 and 137-145
Vulnerability Type: Unrequested scope expansion and delegated external actions
Risk Level: HighVulnerable Code
markdown **Inference rules:** - If BUILD → always include deploy + git push - If OUTREACH → always check domain health + warmup state - If PRODUCT → always include unit economics - If CAREER → always include resume + cover letter + company research - If BUILD + PRODUCT → include Stripe setup consideration - If any bucket → check if it connects to an OPEN project in PROJECTS.md **Cap inference at 3 inferred items.** More = scope creep. Ryan's rule: don't expand beyond what's useful.The inferred jobs are subsequently delegated:
markdown ## Step 5: POST → Hand to Spawner For each job that needs a sub-agent, create a **job posting**: [... job-posting template omitted from this excerpt ...] Write all postings to `workspace/JOB_BOARD.md` and invoke the **spawner** skill.Technical Analysis
The skill explicitly requires itself to add work that the user did not request. In particular, every request classified as
BUILDautomatically acquires deployment and Git-push tasks. These are externally consequential operations: deployment may publish content and consume infrastructure, while a Git push may modify or disclose repository contents.The generated tasks are not merely presented as recommendations. The workflow writes them to a job board and invokes another skill to perform them. No approval gate separates inference from delegation. The limit of three inferred tasks restricts only the number of additions; it does not restrict their privileges, destinations, data sensitivity, or side effects.
This behavior changes the effective goal of a session when the skill is loaded. It therefore best matches
T01: Skill Instruction Hijacking, even though the instructions are shipped directly in the audited skill rather than dynamically injected....[truncated 1479 chars]
- Remediation
View remediation
Remediation Suggestions
- Change all inferred tasks into non-executable recommendations.
- Require explicit, task-specific user approval before:
- Deploying or publishing content.
- Pushing commits or changing remote repositories.
- Sending outreach communications.
- Modifying payment, domain, account, or infrastructure settings.
- Add an approval state to every inferred job, such as
PROPOSED, and prohibit delegation until it becomesAPPROVED. - Require the approval prompt to identify the destination, affected repository or account, data to be transmitted, expected cost, and rollback method.
- Enforce least privilege in downstream agents so that build agents cannot deploy or push by default.
- Replace rules such as “always include deploy + git push” with “suggest deploy and Git push when relevant.”
- Add reconciliation checks that distinguish user-requested work from inferred work and reject unapproved side effects.