Is amstko/tts safe?
https://github.com/openclaw/skills/tree/main/skills/amstko/tts
The amstko/tts skill is a functionally straightforward TTS integration with Hume AI and OpenAI that behaves exactly as documented: it converts text to MP3 audio by calling legitimate third-party APIs. No prompt injection, hidden instructions, malicious code, install hooks, unexpected network activity, or canary file compromise was detected. The primary security consideration is structural and inherent to its stated purpose: every TTS invocation transmits the input text to an external service outside the operator's control, making this skill unsuitable for environments handling confidential or regulated data without explicit data-sharing agreements with Hume AI and OpenAI.
Category Scores
Findings (6)
MEDIUM All synthesized text transmitted to third-party TTS APIs -18 ▶
Both TTS scripts send the --text argument verbatim to external services: generate_hume_speech.js POSTs to https://api.hume.ai/v0/tts and generate_speech.js calls the OpenAI audio speech endpoint. Any text the host agent passes to these scripts — including potentially sensitive content from user conversations, documents, or system context — is transmitted to Hume AI or OpenAI. This is the intentional design of a TTS skill, but operators deploying in environments handling confidential data should treat every TTS invocation as an external data disclosure event.
LOW Three API credentials required from host environment -10 ▶
SKILL.md documents command-line usage that passes HUME_API_KEY and HUME_SECRET_KEY as inline environment variables, and generate_speech.js reads OPENAI_API_KEY from process.env. The keys are used only to authenticate with the documented TTS services and are not forwarded elsewhere; however, they must exist in the host environment, and inline env-var passing exposes them in the process table momentarily.
LOW npm dependency install required; broad semver range for openai package -12 ▶
The skill declares openai ^4.0.0 which permits any 4.x version; however package-lock.json pins the resolved version to 4.104.0 with SHA-512 integrity hashes for all 20 transitive dependencies, substantially mitigating supply-chain drift. No npm lifecycle hooks (preinstall, postinstall, prepare) are present. The commander package at 11.1.0 is a widely-used, low-risk CLI parser. Risk is limited to the npm install step itself.
LOW Hardcoded Hume AI voice UUID controlled by skill author -7 ▶
The default voice ID 9e1f9e4f-691a-4bb0-b87c-e306a4c838ef is hardcoded as the default in both the SKILL.md documentation and the --voice CLI flag default. This voice profile is owned by the skill author's Hume AI account. While not malicious, operators have no control over whether this voice profile remains available, changes character, or is deleted — all of which would silently break the skill. A more operator-friendly design would allow the voice ID to be configured by the deploying user.
INFO Clean install with no unexpected network connections or filesystem side effects 0 ▶
Network capture during the install window shows only the expected HTTPS connection to GitHub (140.82.121.3:443) for the git sparse-checkout clone. The connection diff confirms no new listening ports were opened and no persistent outbound connections were established. Filesystem diff shows only the six expected skill files were written to /home/oc-exec/skill-under-test/.
INFO Canary file accesses traced to oathe framework, not the skill 0 ▶
Inotify and auditd recorded accesses to .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCP credentials. Cross-referencing audit sequence numbers and timestamps places these accesses at audit events ~260-265 (timestamp 1771650933.981, approximately 6 seconds before the git clone at 1771650939.501) and audit events ~1445-1450 (timestamp 1771650955.230, post-install). Both windows align with oathe's pre-install canary baselining and post-install integrity verification. The oathe canary report explicitly confirms all files intact.