T09 · Insecure Skill Coding Practices
- Location
scripts/cli.py:69- Finding
API Credential Exposure Through Command-Line Arguments
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This ETF skill appears to be a real iWenCai query wrapper, but it needs review because it handles an API key, sends finance queries externally, and leaves some tool and credential behavior under-scoped.
Review before installing. Use IWENCAI_API_KEY from the environment rather than passing --api-key on the command line, avoid sending sensitive investment strategies in queries, and be aware that the skill may send ETF questions to iWenCai and may invoke other financial or search tools unless constrained by the runtime.
scripts/cli.py:69API Credential Exposure Through Command-Line Arguments
Mixing characters from multiple Unicode scripts in a single identifier is a common technique to create visually ambiguous tool names.
The skill claims to provide ETF screening logic, but the documented implementation mainly rewrites the user query and forwards it to an external API, with result quality entirely dependent on that service. This mismatch can mislead users and calling agents about what validation, filtering, and parameter handling actually occur, which is dangerous in a finance context where users may overtrust the output.
The skill performs network access and reads an environment variable API key, but it declares no explicit tool scope or permission boundary. That makes its effective capabilities broader and less auditable, increasing the chance of unintended secret access or unauthorized outbound requests in agent runtimes that rely on manifest-style restrictions.
The instruction that this skill must be used for any ETF-screening question is overly broad and mandatory, which can force routing even when another safer or more privacy-preserving path would be better. In an agent ecosystem, broad activation rules increase the chance of unnecessary external calls and reduce human or orchestrator control over sensitive financial queries.
The documentation describes sending user queries to an external API with API-key-authenticated network requests, but it does not provide a user-facing warning that their query content will be shared off-platform. This is a real privacy and transparency issue, especially for finance-related prompts that may contain sensitive investment interests or strategies.
The skill authorizes itself to call other financial or search tools when it decides more context is needed, expanding behavior beyond the stated ETF-screening function. That creates tool-chaining and data-propagation risk, because user financial queries may be forwarded to additional services without clear scope limits or consent.
The help text says the API address defaults to the value of environment variable IWENCAI_API_URL, implying the tool honors that setting. However, the implementation later assigns api_url = DEFAULT_API_URL unconditionally and never reads IWENCAI_API_URL, so the documentation actively contradicts runtime behavior.
The function docstring describes page, limit, and is_cache as operative parameters to the ETF query. In the request payload, the code uses DEFAULT_PAGE, DEFAULT_LIMIT, and DEFAULT_IS_CACHE instead of the provided arguments, so the documented behavior contradicts what the function actually does.
This Python file performs a POST request to an external API using the user's query content and an Authorization bearer token. While the code is documented as an ETF query tool, there is no visible runtime disclosure, confirmation, or explicit warning in this file that user-provided query text and authentication data will be sent off-host.
Natural-language strings in the module docstring and CLI help force a single locale/language for all users. The policy specifically calls out language or locale restrictions as violations when the skill does not provide a user choice or clearly justify the constraint.
No suspicious patterns detected.