Security audit
Security checks for vulnerabilities and agentic risk
This TTS skill appears to be a local text-to-speech helper, but its instructions are internally inconsistent about API keys, external services, and network behavior.
Review before installing. Treat it as a local Piper TTS skill only, do not provide API keys unless you independently confirm a real need, and inspect any setup or synthesis commands before running them because no implementation scripts are included in the package.
The feature list contradicts the stated limitations of the free edition, creating uncertainty about what capabilities are actually present. Such ambiguity can cause agents or users to invoke unsupported flows, install unnecessary components, or grant permissions based on incorrect expectations.
The documentation gives conflicting claims about being fully local and requiring or using API keys/LLM APIs. This is dangerous because operators may enable unnecessary secrets, network access, or trust assumptions that broaden the skill's attack surface and lead to accidental secret exposure or policy bypass.
The markdown states that the free version uses only the preset en_US-kusal-medium voice, which hard-codes an English (US) locale for synthesis. While limitations can be documented, the skill does not offer a user language choice or frame this as an opt-in locale restriction, and elsewhere presents the skill as generally applicable.
The line says 英文优先 and explains that Chinese reading requires a paid version, which imposes a language preference constraint in the skill behavior. This is a natural-language locale policy concern because the skill does not present the language restriction as a user choice or clearly scoped regional limitation.
The input/options section advertises adjustable voice controls while later sections state that speed, pause, and pitch are unsupported. This mismatch can cause downstream agents to pass unvalidated option fields into scripts or command lines, increasing the chance of unsafe parameter handling or broken automation.
Claiming external API integration in a skill described as local-only can mislead users into permitting outbound connectivity or treating remote behavior as expected. In security-sensitive environments, this undermines trust boundaries and may mask unintended data egress paths.
The FAQ says API keys are required, directly contradicting repeated no-API-key claims. This can lead administrators to provision secrets unnecessarily, creating avoidable secret-management risk and normalizing broader access than the skill should need.
The troubleshooting table includes API authentication failure, rate limiting, gateway timeout, and network connectivity failures, even though the skill is described as local-only with zero cloud calls. These documented failure modes contradict the stated intent and imply external service usage that the manifest denies.
