Back to skill

Security audit

Task Harness

Security checks for vulnerabilities and agentic risk

Overview

This task-management skill is mostly coherent, but it directs agents to persist workflow rules in AGENTS.md and to push Git changes without requiring explicit per-action user approval.

Review this skill before installing. It is suitable only if you want a Chinese-language, repository-resident task harness and are comfortable with it adding future-agent workflow rules. Do not allow automatic AGENTS.md edits or Git pushes unless you first review the exact diff, destination remote, branch, and files being committed.

Vulnerability Patterns
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (2)

T02 · Agent Memory Poisoning

Error
Location
SKILL.md:94
Finding

Persistent Cross-Session Agent Control Through AGENTS.md

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 94-96; references/methodology.md, lines 72-78
Vulnerability Type: Persistent agent memory poisoning
Risk Level: High

Relevant Source Segment — English Rendering:

markdown
### Step 4: Configure AGENTS.md Rules

Add a Task Management System section to the project's AGENTS.md file to
ensure that all agent sessions follow the workflow. Refer to the corresponding
section in the current project's AGENTS.md.
markdown
### What if the agent does not follow the rules?

Write the constraints as explicit rules in AGENTS.md. AGENTS.md is loaded
into the agent's context at the beginning of every session and is more
authoritative than an ordinary file.

Important rules should be placed in the Rules section of AGENTS.md rather
than under Notes or Tips.

The related mandatory workflow in SKILL.md, lines 113-134, requires future agents to select stored features, execute their steps strictly, update persistent state, commit and push changes, and update the progress log.

Technical Analysis

The Skill deliberately modifies AGENTS.md, a repository-level instruction file that is automatically loaded into future agent sessions. The methodology explicitly identifies the file as more authoritative than ordinary project files and recommends placing constraints in its Rules section.

This behavior crosses the boundary between creating ordinary project documentation and modifying the persistent instructions that govern future agent behavior. Feature descriptions and execution steps are generated from user-provided requirements and stored in feature_list.json. Future sessions are then instructed to treat that persisted content as an authoritative workflow and to execute feature steps strictly.

The Skill does not require a separate security review of generated task steps before persisting the associated rules. It also does not explicitly stat ...[truncated 1744 chars]

Remediation
View remediation

Remediation Suggestions

  1. Require explicit, informed user approval before creating or modifying AGENTS.md.
  2. Present the exact proposed AGENTS.md diff before writing it.
  3. Avoid mandatory language that causes future agents to execute stored task steps without reassessment.
  4. Add an explicit precedence rule stating that system instructions, safety policies, current user instructions, and repository security requirements override all generated task-management rules.
  5. Treat every value in feature_list.json, progress.txt, and task.json as untrusted project data rather than executable instructions.
  6. Require each future agent to review task steps for command execution, data disclosure, dependency changes, credential access, and network operations before acting.
  7. Scope generated rules to the named project and task, and provide a clear removal or expiration mechanism.
  8. Prefer a non-authoritative task guide such as TASK_HARNESS.md instead of modifying an automatically loaded agent-control file.
  9. If AGENTS.md integration is essential, add only a reference to the task guide and prohibit stored task data from overriding agent safety or authorization checks.

other

Error
Location
SKILL.md:122
Finding

Mandatory Git Push Without Explicit User Confirmation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 122-123 and 129-133; references/methodology.md, lines 43-53
Vulnerability Type: Unconfirmed remote repository modification
Risk Level: High

Relevant Source Segment — English Rendering:

markdown
8. git commit    — one commit for each feature
9. git push      — synchronize with the remote
10. Append progress.txt — record the work performed in this session
markdown
## Strict Rules

- Only modify the passes field in feature_list.json.
- Work on one feature at a time.
- Commit and push are mandatory after every completed feature.
- Verification is mandatory before marking a feature complete.
- progress.txt must be updated.
- Stop and record the reason when blocked.

The methodology further states that pushing is mandatory to prevent progress loss and assumes that transmission to the remote repository is an acceptable default.

Technical Analysis

The Skill requires agents to run git commit and git push after completing each feature. A push is a network operation that modifies an external repository and may also trigger CI/CD pipelines, deployment hooks, security scans, package publication workflows, or other remote automation.

The workflow does not require the agent to:

  • Obtain immediate user confirmation before pushing.
  • Verify the configured remote URL and repository owner.
  • Confirm the destination branch.
  • Review the complete staged diff for secrets or unrelated files.
  • Check whether force-push behavior, hooks, or CI/CD triggers are configured.
  • Confirm that the user is authorized to modify the destination.
  • Determine whether local-only work was requested.

Mandatory pushing is not necessary for the Skill's core task-management purpose. Local state files and local commits are sufficient to preserve progress in many use cases. Treating remote transmission as an unconditional workflow step therefore ...[truncated 1683 chars]

Remediation
View remediation

Remediation Suggestions

  1. Remove mandatory git push behavior from the default workflow.
  2. Default to updating local task files and, where requested, creating a local commit.
  3. Require explicit user confirmation immediately before every push.
  4. Before requesting confirmation, display:
    • The remote name and resolved URL.
    • The destination branch.
    • The commits that will be transmitted.
    • The complete staged diff or a concise reviewed summary.
    • Any detected sensitive files or credentials.
  5. Refuse to push when the remote destination is unknown, newly configured, or inconsistent with the user's stated repository.
  6. Check for detached HEAD state, protected branches, force-push options, submodules, Git hooks, and remote automation where practical.
  7. Never stage files with broad commands such as git add -A without reviewing the resulting staged file list.
  8. Run secret scanning before committing or pushing.
  9. Allow users to select local-only, commit-only, pull-request, or push workflows.
  10. For shared repositories, prefer pushing to a user-approved feature branch and opening a reviewed pull request rather than modifying the primary branch directly.
Vulnerability Patterns
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (9)

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding

声明的核心能力是任务拆解与任务管理系统生成;而提供的代码块并不进行需求分析、任务分解或规划生成。它的主要用途是恢复/概览开发环境:查看 git 状态、最近提交、读取 feature_list.json 统计完成度、检查依赖目录,并给出下一步操作提示。虽然其中包含“进度跟踪”相关元素,但整体主功能与声明明显不同,属于开发会话初始化脚本而非任务拆解或任务管理系统生成逻辑,因此应判定为描述与行为不匹配。

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The auto-trigger conditions are broad enough that ordinary project-planning language could invoke the skill in unintended contexts. Because the skill instructs the agent to generate files, modify AGENTS.md, and run shell commands like bash init.sh, accidental activation could lead to unauthorized repository changes or execution-oriented workflow steps when the user only wanted discussion or lightweight planning.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The usage examples list generic phrases such as '拆解任务', '任务管理', and '项目规划', which commonly appear in benign conversation. In this skill's context, activation is more dangerous because the workflow goes beyond analysis: it directs creation of multiple project files, modifies agent-governance documentation, and normalizes command execution and Git operations across sessions.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
89% confidence
Finding

The entire methodology document is written as prescriptive guidance in Chinese and does not offer any language choice or indicate that the skill is intended only for a Chinese-speaking or region-specific audience. Under the policy rule for natural-language violations, forcing a specific language without opt-in is reportable.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

This JSON template uses Chinese placeholders and instructional text throughout, which imposes a specific language/locale on users of the skill. The file does not offer any language choice or explain that the template is intended only for a Chinese-language or region-specific workflow.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The script's user-facing text, status messages, and next-step instructions are entirely in Chinese, which imposes a specific language on users. There is no opt-in, language selection mechanism, or documentation indicating that the skill is intentionally limited to a Chinese-speaking or region-specific context.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
91% confidence
Finding

The entire template is written in Chinese and provides no indication that users may choose another language or locale. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale constraint is explicitly justified.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The harness rules are written entirely in Chinese, which effectively imposes a specific language on downstream usage of this template without offering a language choice or documenting a locale-specific constraint. This can violate language/locale policy expectations when the skill is intended for broader use.

Content

No source excerpt is available for this finding.

Vague Triggers

Low
Category
Not specified by scanner
Confidence
83% confidence
Finding

This JSON template describes the project's purpose via a generic description field, but it does not define any explicit activation conditions, trigger phrases, or scope constraints for when the skill should be invoked. For manifest-style files, the lack of specific invocation boundaries can lead to ambiguous or overly broad skill activation.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.