Ae1
- Category
- analysis-evasion
- Confidence
- 100% confidence
- Finding
Referenced artifact was not completely inspected
- Content
md node scripts/run.mjs --sample # 先看样例
Security audit
Security checks for vulnerabilities and agentic risk
This local subsidy-reconciliation skill does not show malware behavior, but its financial output can misleadingly imply that cap validation was applied when the code explicitly does not perform that check.
Install only if you are comfortable with a local Chinese-language checker for user-supplied promo subsidy tables. Do not rely on a clean result as proof that activity caps were honored; cap validation is not implemented even though parts of the output mention the cap rule. Any collection, approval, or accounting decision should independently verify capped payable amounts.
Referenced artifact was not completely inspected
node scripts/run.mjs --sample # 先看样例
Referenced artifact was not completely inspected
node scripts/run.mjs --sample # 先看样例
The engine requires an '活动封顶' column as mandatory input, but explicitly withholds cap validation and never applies the cap when recomputing payable subsidy. In a financial reconciliation skill, this creates a misleading assurance gap: users may believe capped subsidies were checked when the most error-prone rule is not enforced, allowing material overstatement of receivables or false discrepancy conclusions.
The result summary states the calculation basis includes the cap rule ('应结补贴 = 实际销量 × 单件补贴(且不得高于活动封顶)'), but no such validation is executed. This is dangerous because downstream users or agents may rely on the returned summary as evidence that cap-based recomputation was performed, causing incorrect approval, escalation, or collection decisions.
The description lists trigger phrases such as “补贴核销”, “活动补贴没结到”, and especially “应结补贴”, which are generic business expressions rather than narrowly scoped invocation commands. The file does not provide exclusion conditions or negative examples, so it is unclear when these phrases should activate the skill versus when they are merely part of normal discussion.
The top-of-file natural-language description, contract text, sample data labels, and user-facing advice are all written in Chinese, which effectively constrains the skill's interaction/output language. The file does not offer a language choice or state that the skill is intentionally limited to a Chinese-language/regional workflow, so this is a locale-policy issue under the stated rule.
All user-facing help, errors, usage text, and status messages are written only in Chinese, and the skill does not offer any language or locale selection. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale restriction is explicitly justified.
The inline documentation states that non-JSON input is treated as plain-text material such as a '合同全文', which contradicts the rest of the file's stated purpose of checking a promotion subsidy reconciliation table with headers. The actual CLI help and insufficiency messages consistently require a 促销补贴核销表, so this comment describes a broader/different intent than the surrounding code.
The JSON value on L2 consists entirely of Chinese headers and activity labels, indicating a fixed language/locale in the skill content. There is no accompanying natural-language indication that this is optional, user-selected, or justified as a region-specific skill, which can violate language/locale policy expectations.