T09 · Insecure Skill Coding Practices
- Location
finance.py:16- Finding
Financial transaction data is stored in plaintext with default filesystem permissions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This accounting skill is mostly purpose-aligned, but it handles sensitive financial records while overstating security protections and under-scoping external sharing and automation guidance.
Review before installing, especially if you will use real business, tax, invoice, or bank data. Treat generated CSV/JSON/PDF/XLSX outputs as sensitive plaintext unless you add your own encryption, access controls, private storage, backups, and review steps. Do not sync financial data to GitHub or connect external systems unless you have confirmed what data leaves your machine.
finance.py:16Financial transaction data is stored in plaintext with default filesystem permissions
README.md:8Runtime dependencies are installed without version or integrity constraints
The README encourages exporting financial data and even integrating with GitHub for version control, but it does not explicitly warn that these outputs may contain highly sensitive accounting, tax, and personal data. In this context, users could accidentally publish confidential records, commit secrets to remote repositories, or distribute unredacted reports.
The README asserts security properties like encrypted storage and audit logging, but the documented usage only shows ordinary local file handling and log file access with no evidence of encryption at rest, key management, tamper resistance, or audited event generation. In a finance/accounting skill, overstating these protections can cause users to store sensitive financial data under false assumptions, increasing the risk of data exposure and compliance failures.
The README states the skill complies with Chinese accounting standards, while the overall skill description presents the tool as a general finance/accounting package rather than a clearly region-specific compliance tool. This can amount to a locale/policy constraint imposed without explicit user opt-in or upfront scoping.
The skill advertises capabilities that imply reading and writing local files, but it does not declare any explicit tool scope or permission boundaries. In a finance/accounting context, this is more dangerous than usual because the likely data involved includes invoices, bank statements, ledgers, tax documents, and reports, so an agent could access or modify sensitive records without clear user-visible constraints.
The skill integrates with external systems such as bank APIs, tax systems, ERP platforms, GitHub, and search services, but it does not clearly warn users that sensitive financial data may be transmitted outside the local environment. This creates a real risk of unintended disclosure of regulated or confidential information, especially given the highly sensitive nature of accounting and tax records.
The file is entirely written for a China-specific tax regime, using Chinese-language labels and country-specific tax categories and rates, but it does not document that the skill is restricted to Chinese tax workflows or offer any language/locale choice. Under the policy, locale constraints should be explicitly justified or optional rather than implicitly enforced.
This code file contains natural-language descriptions and CLI help text that are Chinese-only, beginning with the module docstring and continuing throughout the interface. Under the policy rule, forcing a specific language without opt-in is a violation unless the locale restriction is explicitly justified or alternatives are offered.
The file's docstrings, comments, and user-facing print messages are consistently in Chinese, which effectively imposes a single language on users of the skill. There is no indication that this locale is optional, configurable, or required for a region-specific use case.
The script deletes directories with shutil.rmtree before running tests, which is a destructive file operation. Although there are comments describing cleanup, there is no user-facing warning, prompt, or explicit disclosure that existing local data in those paths will be removed when the script is executed.
The README labels the skill as production-ready while explicitly noting that reconciliation functionality is still 'to be implemented.' For financial software, presenting incomplete core controls as production-ready can lead users to rely on missing safeguards, producing accounting errors or skipped review steps.
The file's natural-language description and instructions are entirely in Chinese, which can constitute a language/locale policy issue when the skill does not explicitly state that it is China-specific or offer an opt-in language choice. No justification is provided that the skill is intentionally limited to Chinese-language use despite covering general accounting functions.
This YAML file uses Chinese for the title and all account names/descriptions, which imposes a specific language/locale in the skill content. Under the policy, language constraints should be optional, justified, or presented with user choice; no such opt-in or justification appears here.
This file contains natural-language content in Chinese for transaction descriptions, which imposes a specific language without any visible user opt-in or documented locale justification. Under the policy rule, forcing a specific language in skill-related content can be a language/locale policy violation.
No suspicious patterns detected.