Security audit
Security checks for vulnerabilities and agentic risk
This skill coherently translates audio through OATDA and discloses its API key and upload behavior, though users should understand recordings are sent to an external service.
Install only if you are comfortable sending selected audio recordings to OATDA for processing and storing or providing an OATDA API key. Avoid using it on sensitive recordings unless you intend that external upload.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
"openclaw":
{
"emoji": "🌍",
"requires": { "bins": ["curl", "jq"], "env": ["OATDA_API_KEY"], "config": ["~/.oatda/credentials.json"] },
"primaryEnv": "OATDA_API_KEY",
},
}
The skill instructs the agent to read an API key directly from ~/.oatda/credentials.json and export it into the shell environment for execution. Accessing local credential files expands the skill's authority to sensitive secrets and creates risk of unintended disclosure, misuse, or reuse by subsequent commands, especially in agentic environments where shell state and logs may be observable.
All commands need the OATDA API key. Resolve it inline for each exec call:
export OATDA_API_KEY="${OATDA_API_KEY:-$(cat ~/.oatda/credentials.json 2>/dev/null | jq -r '.profiles[.defaultProfile].apiKey' 2>/dev/null)}"
If the key is empty or null, tell the user to get one at https://oatda.com and configure it.
This command again reads the API key from a local credentials file and uses it in a network request. Repeated inline credential harvesting increases the chance of secret exposure through process inspection, shell history/debugging, or accidental reuse across unrelated operations.
export OATDA_API_KEY="${OATDA_API_KEY:-$(cat ~/.oatda/credentials.json 2>/dev/null | jq -r '.profiles[.defaultProfile].apiKey' 2>/dev/null)}" && \
curl -s -X GET "https://oatda.com/api/v1/llm/models?type=audio" \
-H "Authorization: Bearer $OATDA_API_KEY" | jq '.audio_models[] | {id, supported_params}'
The multipart upload example relies on the same pattern of reading secrets from a local credential store and exporting them before making a remote request. In a skill context, this is dangerous because the skill is teaching and normalizing direct credential file access rather than using least-privilege secret injection.
export OATDA_API_KEY="${OATDA_API_KEY:-$(cat ~/.oatda/credentials.json 2>/dev/null | jq -r '.profiles[.defaultProfile].apiKey' 2>/dev/null)}" && \
curl -s -X POST "https://oatda.com/api/v1/llm/translations" \
-H "Authorization: Bearer $OATDA_API_KEY" \
-F "provider=<PROVIDER>" \
This example combines local credential-file access with transmission of full audio content to a remote service, increasing the blast radius if the skill is triggered unexpectedly or used in sensitive contexts. The credential is fetched from disk and then used in a command that may be logged or inspected, making secret handling weaker than necessary.
AUDIO_DATA_URL="data:audio/mpeg;base64,$(base64 -w 0 audio.mp3)"
export OATDA_API_KEY="${OATDA_API_KEY:-$(cat ~/.oatda/credentials.json 2>/dev/null | jq -r '.profiles[.defaultProfile].apiKey' 2>/dev/null)}" && \
curl -s -X POST "https://oatda.com/api/v1/llm/translations" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OATDA_API_KEY" \
The final example repeats direct local credential-file access, reinforcing an unsafe pattern throughout the skill. Even without printing the key, instructing an agent to read and export secrets from ~/.oatda/credentials.json creates unnecessary secret exposure pathways and exceeds what a minimally privileged skill should do.
export OATDA_API_KEY="${OATDA_API_KEY:-$(cat ~/.oatda/credentials.json 2>/dev/null | jq -r '.profiles[.defaultProfile].apiKey' 2>/dev/null)}" && \
curl -s -X POST "https://oatda.com/api/v1/llm/translations" \
-H "Authorization: Bearer $OATDA_API_KEY" \
-F "provider=openai" \
The manifest description says the skill triggers when the user wants 'audio translation, spoken-language translation, Whisper-style translation, or English output from uploaded recordings,' which is a broad natural-language description rather than a specific invocation scope. It does not provide explicit trigger phrases, exclusions, or negative examples, increasing the chance of unintended activation for ordinary translation-related requests.
The description explicitly states the skill translates foreign-language audio into English text, and the document later reiterates that the output is English. This imposes a fixed language outcome without offering the user a choice or opt-in, which is a language/locale policy concern.
This skill sends user-provided audio, potentially including sensitive spoken content, to an external third-party API. The risk is heightened because the base64 JSON path makes the entire recording content part of the outbound request body, creating clear data exfiltration/privacy exposure if used without explicit user awareness and consent.
AUDIO_DATA_URL="data:audio/mpeg;base64,$(base64 -w 0 audio.mp3)"
export OATDA_API_KEY="${OATDA_API_KEY:-$(cat ~/.oatda/credentials.json 2>/dev/null | jq -r '.profiles[.defaultProfile].apiKey' 2>/dev/null)}" && \
curl -s -X POST "https://oatda.com/api/v1/llm/translations" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OATDA_API_KEY" \
-d "$(jq -n \
No suspicious patterns detected.