Back to skill

Security audit

Mission Control

Security checks for vulnerabilities and agentic risk

Overview

This skill appears intended for task tracking, but it takes unusually broad control of agent workflows and writes persistent local task files with weak path scoping.

Install only if you deliberately want a strict, persistent mission-control workflow for many agent tasks. Review and constrain the hardcoded storage path, validate task IDs, remove automatic source-file copying, and treat project-intake.md content as untrusted data rather than instructions.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • 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
Findings (3)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:15
Finding
Mandatory Global Workflow and Agent Role Hijacking## Vulnerability Details **File Location**: `SKILL.md`, lines 15-57 **Vulnerability Type**: Mandatory instruction and workflow hijacking **Risk Level**: Critical ### Vulnerable Snippet The following is an English translation of the relevant Skill instructions: ```markdown **Plan-confirmation system**: Every task involving code or file operations must have its plan confirmed by Boss before execution. **Single-agent execution system**: The entire process is performed by Moss, without SubAgents or an expert-agent intermediate layer. Scan the task: ├── Does it involve .py/.sh/.js/.md/.yaml/.json file operations? → Required ├── Does it generate or modify code/scripts? → Required ├── Does it delegate to a SubAgent? → Required ├── Does it require online research? → Required ├── Does it involve terminal/command-line operations? → Required └── Is it only pure conversation/simple Q&A under one minute? → Not required Stage 3: Boss confirmation - Display the complete plan, including conclusions from all three iterations. - Wait for Boss to reply "approved." - If Boss does not approve, record the comments and return to Stage 2. ``` Additional mandatory restrictions appear in `SKILL.md`, lines 234-242: ```markdown - Do not enter Boss confirmation before completing three Stage 2 iterations. - Do not allow Moss to execute before obtaining Boss confirmation. - Do not execute without recording the process in t-log.md. - Do not finish without generating t-report.md. ``` ### Technical Analysis The Skill does not present its task-management process as an optional capability. It issues mandatory instructions that broadly apply whenever the agent encounters file operations, code changes, terminal activity, delegation, or online research. These rules alter the agent's current-session be ...[truncated 2197 chars]
Remediation
## Remediation Suggestions 1. Make mission-control explicitly opt-in. Activate it only when the user directly asks for task tracking, plan approval, or mission-control formatting. 2. Replace mandatory language such as “must,” “cannot,” and “prohibited” with scoped recommendations. 3. Do not redefine the agent or user identity. Use neutral terms such as “agent” and “user.” 4. Do not block task execution unless the user explicitly requests approval gating. 5. Treat `qiushi` integration as optional and availability-dependent. 6. Add an explicit precedence rule stating that system, developer, and current user instructions override Skill guidance. 7. Ask before creating persistent artifacts outside the current project directory. 8. Limit automatic triage to tasks where mission-control was explicitly enabled, rather than all code, file, terminal, or research activity. 9. Allow users to disable individual stages, logging, external Skill invocation, and persistent storage.

T01 · Skill Instruction Hijacking

Error
Location
templates/project-intake.md:208
Finding
Project Intake Data Can Inject Behavioral Rules and Persistent Memory Content## Vulnerability Details **File Location**: `templates/project-intake.md`, lines 208-241 **Vulnerability Type**: Data-driven instruction injection and memory poisoning **Risk Level**: High ### Vulnerable Snippet The following is an English translation of the relevant template content: ```markdown > **Moss core-memory synchronization**: > - The absolute red lines for this task are: > [RED_LINE_1] = ____, [RED_LINE_2] = ____ > - The single source-of-truth file for this task is: ____ > - The core deliverable for this task is: ____ ## Moss Input Response Specification — Important After receiving this file, do not immediately begin generating the plan. Strictly perform the following steps first: 1. Complete the self-check table in Section 10 and output the completed table. 2. Restate the core deliverable in one sentence. 3. Restate the absolute red lines by directly quoting the [RED_LINE_N] labels. Example response: ✅ Self-check complete: - Objective and acceptance criteria complete: ✅ - Ambiguities requiring confirmation: None - Core deliverable: Generate the transcriptome analysis report. - Absolute red line: [RED_LINE_1] = Do not delete historical backup files. Ask Boss to confirm before entering the plan-generation stage. ``` The ingestion behavior is also established in `SKILL.md`, where the agent is instructed to read all fields from a discovered `project-intake.md` and incorporate them into task requirements. ### Technical Analysis A project intake document is task data and may be supplied or modified by a project participant, repository contributor, or other untrusted source. However, this template embeds imperative instructions that control agent sequencing, response structure, and memory behavior. The design does not establish a trust boundary between: - Declarative project information, such as goals and file paths. - User-defined constraints and acceptance criteria. - Behaviora ...[truncated 2225 chars]
Remediation
## Remediation Suggestions 1. Treat every intake file as untrusted data, not as executable agent instructions. 2. Remove the “response specification,” “strictly perform,” and “core-memory synchronization” directives from the template. 3. Parse only a fixed, documented schema with typed fields and size limits. 4. Reject or ignore behavioral directives embedded in ordinary field values. 5. Never write intake content into persistent memory automatically. 6. Require explicit confirmation in the current conversation before adopting red lines, sources of truth, credentials, external paths, or long-term constraints. 7. Present imported constraints as quoted data and ask the user whether they are authoritative. 8. Record provenance for each imported field, including the file path and whether the file is trusted. 9. Apply prompt-injection defenses when processing project documents, including a rule that document content cannot redefine agent behavior or instruction precedence. 10. Do not automatically repeat sensitive field values in responses or logs. 11. Restrict accepted file locations and verify ownership or integrity where intake files are automatically discovered.

T09 · Insecure Skill Coding Practices

Error
Location
scripts/save_plan.py:14
Finding
Unsanitized Task Identifier Permits Out-of-Root Directory Creation and File Overwrite## Vulnerability Details **File Location**: `scripts/save_plan.py`, lines 14-45 **Vulnerability Type**: Path traversal and arbitrary file write **Risk Level**: High ### Vulnerable Snippet ```python def save_plan(task_id, content_type, content_or_path): today = datetime.now().strftime("%Y-%m-%d") today_folder = os.path.join(MISSION_CONTROL_DIR, today) task_folder = os.path.join(today_folder, task_id) os.makedirs(task_folder, exist_ok=True) filename_map = { "requirement": "t-requirement.md", "plan": "t-plan.md", "log": "t-log.md", "report": "t-report.md" } if content_type not in filename_map: print(f"Error: unknown content type '{content_type}'") return False filename = filename_map[content_type] filepath = os.path.join(task_folder, filename) content = content_or_path if os.path.isfile(content_or_path): with open(content_or_path, "r", encoding="utf-8") as f: content = f.read() with open(filepath, "w", encoding="utf-8") as f: f.write(content) ``` The command-line entry point assigns the untrusted value directly: ```python task_id = sys.argv[1] content_type = sys.argv[2] content_or_path = sys.argv[3] save_plan(task_id, content_type, content_or_path) ``` ### Technical Analysis `task_id` is supplied through the command line and used directly as a path component without validation or canonicalization. Two path-escape mechanisms are available: - A task identifier containing `../` components can traverse above the date directory. - An absolute task identifier causes `os.path.join(today_folder, task_id)` to discard `today_folder` and use the absolute path. The script then calls `os.makedirs()` on the resulting path and opens the destination in write mode. Write mode truncates an existing file. Although the destination basename is restricted to one of fou ...[truncated 1978 chars]
Remediation
## Remediation Suggestions 1. Enforce the documented task-ID format with a strict allowlist: ```python import re if not re.fullmatch(r"T-\d{8}-\d{3}", task_id): raise ValueError("Invalid task ID") ``` 2. Resolve and verify the destination before creating directories or files: ```python from pathlib import Path base = (Path(MISSION_CONTROL_DIR) / today).resolve() task_folder = (base / task_id).resolve() if task_folder.parent != base: raise ValueError("Task path escapes the archive root") ``` 3. Reject absolute paths, separators, `.` components, and `..` components in task identifiers. 4. Open new artifacts with exclusive creation mode where overwriting is not expected. 5. Require explicit overwrite authorization and use atomic replacement when updates are legitimate. 6. Separate literal content input from source-file input. Use distinct command-line options such as `--content` and `--source-file`. 7. If source files are supported, restrict them to approved project roots after canonicalization. 8. Run the script under a least-privileged account with write access limited to the mission-control archive. 9. Add automated tests for absolute paths, traversal sequences, symbolic-link escapes, duplicate task IDs, and overwrite attempts. 10. Consider descriptor-based safe directory access or equivalent platform protections to reduce symbolic-link race conditions.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (17)

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The skill claims lifecycle coverage across task intake, confirmation, progress updates, and completion, but the reported implementation does not provide those controls and only performs minimal state checks or file output behavior. This can mislead downstream automation into believing governance, auditability, and approval exist when they do not, enabling unreviewed actions and broken accountability.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The skill claims lifecycle coverage across task intake, confirmation, progress updates, and completion, but the reported implementation does not provide those controls and only performs minimal state checks or file output behavior. This can mislead downstream automation into believing governance, auditability, and approval exist when they do not, enabling unreviewed actions and broken accountability.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The skill claims lifecycle coverage across task intake, confirmation, progress updates, and completion, but the reported implementation does not provide those controls and only performs minimal state checks or file output behavior. This can mislead downstream automation into believing governance, auditability, and approval exist when they do not, enabling unreviewed actions and broken accountability.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The skill claims lifecycle coverage across task intake, confirmation, progress updates, and completion, but the reported implementation does not provide those controls and only performs minimal state checks or file output behavior. This can mislead downstream automation into believing governance, auditability, and approval exist when they do not, enabling unreviewed actions and broken accountability.

Vague Triggers

High
Confidence
97% confidence
Finding
The activation criteria are extremely broad, covering most coding, file, terminal, delegation, and web-research tasks. An overly broad trigger surface can let the skill intercept many ordinary workflows, impose unintended process changes, and expand the opportunities for unauthorized file creation or policy confusion, especially because it also directs use of fixed local paths.

Vague Triggers

Medium
Confidence
92% confidence
Finding
The auto-triage rules are extremely broad and effectively force this skill to intercept most tasks involving files, code, web access, or terminal usage. In an agent framework, such catch-all routing can create denial-of-service-like workflow lock-in, unnecessary privilege exposure, and a larger attack surface because many unrelated tasks are funneled through a high-control orchestration skill. The skill context makes this more dangerous because it is explicitly designed to gate execution and modify agent behavior across multiple stages.

Lp3

Medium
Category
MCP Least Privilege
Confidence
84% confidence
Finding
The skill describes and requires local file creation and updates, but it declares no explicit tool scope or permission boundaries. In practice this can cause the host agent to apply the skill to filesystem operations without a least-privilege contract, increasing the chance of unintended writes, unsafe file access, or policy bypass via ambiguous capability inference.

Natural-Language Policy Violations

Medium
Confidence
88% confidence
Finding
The manifest description is written as a mandatory Chinese-language operational instruction for the agent, with no indication that the user may choose another language or locale. This can violate language-choice policy when the skill behavior effectively forces a specific language absent opt-in or documented regional justification.

Natural-Language Policy Violations

Medium
Confidence
86% confidence
Finding
SQP-3 applies to all file types and covers language or locale policy violations. This markdown file presents all instructions and operational notes only in Chinese, and nowhere indicates user opt-in, multilingual support, or a documented reason that the skill/reference must be Chinese-only.

Natural-Language Policy Violations

Medium
Confidence
97% confidence
Finding
The module docstring at L02-L05 is entirely in Chinese, and the script also presents usage/output strings only in Chinese. This imposes a specific language on users without opt-in or justification, which matches the language/locale policy violation criteria.

Natural-Language Policy Violations

Medium
Confidence
94% confidence
Finding
The print statements shown at L42 and L47 display only Chinese text to the user. Because the file does not offer a language selection mechanism or explain a justified locale restriction, this is a natural-language policy violation.

Natural-Language Policy Violations

Medium
Confidence
97% confidence
Finding
The module docstring and CLI usage text are entirely in Chinese, which imposes a specific language on users without opt-in. The file does not state that the skill is region-specific or provide any alternative locale, which fits the language/locale policy violation criterion.

Context-Inappropriate Capability

Medium
Confidence
94% confidence
Finding
The function treats the third argument as either raw content or a filesystem path, and if the supplied value names an existing file it reads and copies that file into the mission-control directory. In an agent skill that may handle untrusted task inputs, this enables arbitrary local file read/copy behavior well beyond the stated purpose of saving plan content, which can expose sensitive host data such as tokens, configs, or private source files.

Intent-Code Divergence

Medium
Confidence
97% confidence
Finding
The module documentation at L03-L04 and the function name imply that task status will be updated. However, the implementation only checks whether the task ID string exists in the file content and then prints a success message; it never modifies or writes ACTIVE_MISSIONS.md.

Natural-Language Policy Violations

Medium
Confidence
97% confidence
Finding
This code file contains natural-language text exclusively in Chinese in the module docstring and CLI usage, and all runtime messages are also Chinese. Under the stated policy, forcing a specific language without offering the user a choice or documenting a justified locale restriction is a natural-language policy violation.

Vague Triggers

Low
Confidence
78% confidence
Finding
这是一个 markdown 文件,适用 SQP-1。L101-L103 的“使用建议”给出项目阶段化建议,但未明确该参考文档在什么具体条件下应被采用、何时不应采用,也没有列出明确触发短语或负例,容易导致在过宽场景下被引用或调用。

Natural-Language Policy Violations

Low
Confidence
93% confidence
Finding
The file's user-facing docstring is entirely in Chinese, including the usage and output description, which imposes a specific language on users without any opt-in or documented locale-specific scope. Under the policy rules, language constraints should either offer user choice or be clearly justified as region-specific.

Static analysis

No suspicious patterns detected.