T01 · Skill Instruction Hijacking
- Location
SKILL.md:8- Finding
Automatic Workflow Activation Can Override the Agent's Intended Session Behavior
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a project workflow helper, but it also mandates automatic commits, persistent logs, remote SSH, external delegation, and execution of an unaudited local script without enough user control.
Install only if this is a private, trusted workflow for the named environment and you are comfortable with automatic commits, persistent logs, SSH to the specified host, and Jinx delegation. Before use, remove or gate the hard-coded SSH and curl steps, require approval before commits or outbound requests, stage only reviewed files, and verify any external enforcement script separately.
SKILL.md:8Automatic Workflow Activation Can Override the Agent's Intended Session Behavior
SKILL.md:26Unnecessary Access to Persistent Agent Memory and Prior Session Records
SKILL.md:61Hard-Coded Remote SSH Access Uses a Local Private Key Without Authorization Checks
SKILL.md:99Mandatory External Jinx Delegation Can Disclose Project and Session Data
SKILL.md:55Indiscriminate Git Staging Can Commit Secrets and Unrelated User Changes
SKILL.md:157Mandatory Execution of a Mutable Script Outside the Audited Project
Hard-coded SSH access to a specific host with a specific key path is a powerful external capability that is not justified for a build-execution protocol. This can cause unintended outbound connections, leak environment or operational details, and normalize use of sensitive credentials in a routine workflow, increasing the blast radius if the skill is triggered in the wrong context.
The auto-trigger conditions are broad enough that normal phrases like 'keep going' or 'work on [project]' can invoke a highly stateful protocol with testing, commits, file edits, and remote checks. Over-broad triggering is dangerous here because the skill performs consequential actions automatically, making accidental activation more likely.
The skill mandates automatic git commits and backup/state-changing file operations without clearly warning that it will modify project history and working state. Because the protocol can auto-trigger, this can create unauthorized commits, overwrite intended workflows, and persist potentially sensitive intermediate states without the user's explicit consent.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
- If the project uses git: `git add -A && git commit -m "checkpoint: session start — N tests passing"`
- If no git: copy critical files to a backup location
- **Why:** If task 3 breaks something silently, you can diff back to this known-good state
- Create a new checkpoint after each completed task
□ **6. Check Jinx Status**
- `ssh -i ~/.ssh/lucky_to_mac luckyai@100.90.7.148 "curl -s http://localhost:3001/status"`
The skill is presented as a local build-queue workflow, but it silently expands scope to include remote SSH access to a hard-coded host and HTTP status checks. That creates an unjustified trust boundary crossing: invoking the skill for ordinary project work can trigger access to external infrastructure, expose credentials or metadata, and couple local execution to a remote service the user may not expect.
The skill instructs remote SSH and HTTP operations without upfront warnings about network access, credential usage, privacy exposure, or impact on external systems. In context, this is especially risky because the skill auto-triggers and presents these actions as mandatory, which can lead users or agents to contact remote infrastructure without informed consent.
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.
- [ ] No regressions (test count ≥ baseline)
**Red Lines (Never Cross):**
- Never mark a task done without verification
- Never decrease test count
- Never start a new task with failing tests
- Never continue past 70% context without wrapping up
The stated purpose is to work through an ordered build queue with verification and session handoff. Requiring users to evaluate whether work should be generalized into a reusable skill and to create one if substantial expands the behavior beyond build-task execution into skill-authoring and capability expansion, which is not reflected in the manifest.
No suspicious patterns detected.