T01 · Skill Instruction Hijacking
- Location
SKILL.md:7- Finding
Mandatory Cross-Task Instruction Hijacking and Automatic Task Replay
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This task-resume skill has a coherent purpose, but it automatically stores and replays task context across sessions with weak user control.
Install only if you want automatic cross-session task tracking. Avoid using it with secrets, private logs, regulated data, or tasks that should not resume without explicit approval. Before use, narrow activation to opt-in, require confirmation before enqueueing or resuming, restrict recovery to trusted session logs, and add expiry and revocation controls for any watchdog job.
SKILL.md:7Mandatory Cross-Task Instruction Hijacking and Automatic Task Replay
scripts/task_resume_queue.py:108Untrusted Session-Log Content Persisted as Future Agent Context
SKILL.md:86Guidance for Recurring Cross-Session Task Execution
The README documents persistence to a workspace-global memory file shared across sessions, but it does not prominently warn that queue operations write user task context to disk and make it visible across main/clone/group sessions. Since stored fields include title, context, acceptance criteria, source, and session metadata, users may unknowingly persist sensitive workflow details beyond the current interaction. The cross-session design increases the privacy and data-handling risk.
The recommended policy says everything except a short list of explicit override commands can be treated as a temporary interruption candidate. In this skill’s context, that broad default can cause unintended capture and later resumption of tasks the user did not mean to persist, potentially storing sensitive context and triggering autonomous follow-up across sessions. Because the skill is specifically designed to auto-enqueue and auto-resume, ambiguity in interruption detection is more dangerous here than in ordinary documentation.
The guidance introduces a non-English output requirement ('巡检回执') without user opt-in or localization context. In an automation skill that sends periodic progress and continuity reminders, this can cause confusing or inappropriate outbound messaging, especially in environments expecting English-only or user-selected language behavior. The risk is primarily integrity/usability rather than direct compromise.
The skill clearly directs file reads/writes to shared workspace memory and helper scripts, but it declares no tool scope or permission boundaries. That mismatch is risky because it enables persistence and cross-session state changes without transparent authorization, making accidental or unauthorized data access more likely.
The description is broad enough to match ordinary conversational context switches, increasing the chance that the skill activates when the user did not intend persistent task tracking. Over-broad triggering is dangerous here because the skill writes task context to shared storage and may later auto-resume work across sessions.
The rule treats most non-explicit topic switches as interruptions by default, which is too aggressive for normal chat behavior. In this skill, that means routine conversation changes can trigger automatic persistence of unfinished task details and later autonomous resumption, creating privacy and control risks.
The skill mandates writing task context to a workspace-global shared queue across main, clone, and group sessions without a clear warning or consent flow. Cross-session persistence can expose sensitive task details to unrelated contexts, create data retention issues, and allow one session to influence another through shared state.
The watchdog section expands a resume helper into autonomous ongoing task execution with periodic user-facing updates and automatic continuation when there is 'no recent progress.' This can cause the agent to act without a fresh user prompt, potentially performing unintended actions, spamming users, or continuing sensitive workflows after context has changed.
Automatic watchdog execution plus periodic user-facing messages are prescribed without a strong safety boundary, approval model, or stop conditions. That combination increases the risk of unbounded autonomous behavior, unintended side effects, and repeated outbound messaging after the user's needs or environment have changed.
The clear_items function overwrites the queue file contents with an empty list, irreversibly deleting queued items. There is a JSON status output after the action, but no prior confirmation prompt, warning comment, or user-facing disclosure that the operation is destructive.
The recover command accepts an arbitrary filesystem path and reads the referenced file without constraining it to an expected session-log directory or validating that it is actually a session .jsonl log. In this skill context, that enables unintended local file disclosure and ingestion of unrelated sensitive data into the task-resume queue, which is especially risky because the recovered content is then persisted for later access.
The recover flow reads the tail of the provided log file and stores it in the queue context verbatim, with no redaction, sensitivity checks, or user-visible warning. Session logs can contain secrets, prompts, tokens, file paths, or personal data, so this creates a secondary persistence channel that can expose sensitive information beyond its original location and retention scope.
The clear command is presented as a normal operation without an explicit warning that it irreversibly removes queued interrupted-task data. While not a code-execution issue, this can lead to accidental loss of recovery state and continuity data, which is security-relevant when the queue is relied on for task integrity and auditability. The impact is limited but real in an operational recovery tool.
Mandating a specific language for status updates without user opt-in can degrade clarity and user control, especially if it causes system-generated messages the user cannot easily understand. While lower severity than the persistence and autonomy issues, it still creates a trust and usability problem in an automated messaging workflow.
No suspicious patterns detected.