T05 · Unauthorized Access and Privilege Escalation
- Location
scripts/validate_scope.py:27- Finding
Scope and Skill Permission Validation Does Not Enforce Least Privilege
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a workflow-plan generator and validator scaffold; it does not show deception, exfiltration, persistence, or execution of business actions, but its validation should not be treated as a security boundary.
Install only if you are comfortable with a planning scaffold whose validators annotate plan files in place and provide structural checks, not complete authorization enforcement. Do not let a downstream workflow engine execute high-impact business actions solely because these validation flags pass; enforce permissions, tenant boundaries, condition-expression parsing, and human review separately.
scripts/validate_scope.py:27Scope and Skill Permission Validation Does Not Enforce Least Privilege
scripts/compile_plan.py:11Business Goal Injection Guardrail Is Documented but Not Enforced
assets/output_schema.json:38Condition Expressions Accept Arbitrary Unvalidated Strings
scripts/validate_scope.py:20Empty Entry-Node List Causes Scope Validator Denial of Service
SKILL.md:144Third-Party Dependencies Are Installed Without Version or Integrity Pinning
The declared purpose says this skill should transform complex business goals into a structured workflow execution plan (Plan IR), including orchestration, DAG generation, and task decomposition. The supplied code performs a much narrower and different function: validating that target_skill names already present in an existing plan are listed in a provided manifest. It neither accepts a business goal nor constructs nodes, edges, or a DAG. Its primary purpose is static validation/binding of skills, not workflow planning. Writing validation results back into the plan file is also behavior not reflected in the description. Therefore this is a material description-behavior mismatch.
The description promises a planner/compiler that transforms complex business goals into a structured workflow execution plan (Plan IR) for multi-step orchestration. The actual code only validates a provided JSON plan against a schema and annotates the file with a validation_report. While static validation is related to the phrase '可静态校验', this code covers only the validation step, not the core advertised behavior of generating or compiling plans. Therefore the primary purpose is materially different: validator versus planner/compiler.
The declared purpose centers on planning/orchestration: transforming complex business goals into a structured workflow execution plan (Plan IR). The supplied code does not perform planning, decomposition, DAG generation, or multi-skill orchestration. Its primary function is static validation of an already-existing plan's scoped_state_keys and input mappings, plus persistence of a validation report into the same file. That is a materially different primary purpose from compilation/generation of workflow plans, so this should be flagged as a mismatch.
The declared purpose centers on planning/orchestration generation: turning complex business objectives into a structured Plan IR and producing DAG workflow plans. The supplied code does not perform planning, decomposition, orchestration, or IR generation at all. Its primary function is post hoc validation of an already-existing Plan IR/DAG, including cycle detection, node reference checks, and structural limit checks. It also modifies the input JSON by appending a validation_report, which is an operational behavior not suggested by the description. While static validation is mentioned in the description as a property of the generated plan, this code is only the validator, not the compiler/planner itself. Therefore the actual behavior is materially different from the declared primary purpose.
Without declared permissions the skill's intent is opaque and cannot be validated.
The manifest description and invocation guidance are written to require Chinese trigger phrasing such as '编排多步任务' and '生成DAG执行计划', while also mixing in a single English phrase. This creates a language/locale preference in the skill's activation behavior without stating that users may choose their preferred language or that the limitation is intentional.
The file's instructional content is written entirely in Chinese, and there is no indication that users may choose another language or that the locale restriction is intentionally scoped to a China-specific or Chinese-speaking context. Under the stated policy, forcing a specific language without opt-in is a natural-language policy violation.
The file’s operational instructions and rule descriptions are written entirely in Chinese, with no indication that users may choose another language or that the locale restriction is required for a region-specific purpose. Under the stated policy, forcing a specific language without user opt-in is a natural-language policy violation.
The module docstring at L02 and function docstring at L11 present this component as only validating skill bindings. However, the main routine later reopens the plan and writes a validation_report back into the original plan file at L67-L73, which is a side effect inconsistent with a validation-only description.
Given the skill's workflow-planning purpose and this script's stated role of binding/validating skills, checking plan references is expected. Persistently modifying the plan file is an additional write-back behavior not conveyed by the script's own described purpose, creating a description-behavior mismatch.
The top-level docstring and validate_schema docstring frame the behavior as validation only. In practice, main() reopens the plan and writes validation_report fields back to disk, which is an additional side effect not reflected by the documented intent.
The module and function documentation describe this script as validating Plan IR against a schema, which implies a checking operation. However, after validation it rewrites the provided plan JSON file to inject or update a validation_report section, making the tool state-changing rather than purely validating.
The module docstring at L02 and function/doc CLI descriptions at L11 and L66 describe the script as validating scoped state keys, which implies a checking operation. However, L85-L92 modify the supplied JSON file in place by adding validation_report data, so the implementation is not purely validation and the documentation omits this side effect in a way that misstates intent.
The skill is described as compiling business goals into statically checkable workflow plans, and this script is labeled as a validator. Instead of only checking scope consistency, it rewrites the provided plan JSON with a validation_report, introducing stateful file modification behavior not clearly implied by a validation step.
This code overwrites the JSON file passed via --plan by writing validation results back into the same path. Although the script prints validation status, it does not clearly disclose that the input file itself will be modified, and the docstring/argument help also frame the action only as validation.
The docstring states the script only validates DAG topology, but the implementation also persists changes back to the input file. This documentation/behavior mismatch is dangerous because operators, calling tools, or higher-level agents may treat the script as side-effect free and invoke it on important plan files without safeguards, increasing the chance of unintended state changes.
This validator has an unexpected side effect: it rewrites the supplied plan file to append a validation_report, even though its interface and description present it as a read-only validation step. In workflow orchestration contexts, mutating user-supplied plan artifacts can corrupt source-of-truth files, break downstream integrity assumptions, or allow a simple validation operation to become a destructive file modification if pointed at sensitive or shared JSON data.
The script overwrites the input JSON file in place without explicit confirmation, backup, or a dedicated output path. In an orchestration skill, plan files may be generated, versioned, or consumed by other systems, so silent overwrite can cause data loss, race-condition style corruption, or unsafe modification of files that callers expected to remain unchanged.
The business goal and all skill descriptions are written in Chinese, and the file provides no indication that the skill supports user language selection or that it is intentionally limited to a Chinese-language environment. Under the natural-language policy rule, forcing a specific language without opt-in can be a locale-policy issue.
This JSON manifest contains all human-readable purpose fields in Chinese, but provides no indication that the skill is region-specific or that users can opt into this locale. Under the policy, forcing a specific language without user choice or documented justification is a natural-language policy concern.
The document's instructional content is primarily written in Chinese, but there is no indication that the skill is region-specific or that users can opt into this locale. Under the natural-language policy rules, forcing a specific language without user choice is a policy concern.