Security audit
Security checks for vulnerabilities and agentic risk
This Gladia transcription skill is purpose-aligned, but it needs review because it processes sensitive live audio and includes session/file deletion without clear privacy, consent, or confirmation guidance.
Review this skill before installing in environments that handle calls, meetings, customer data, health data, financial data, or confidential conversations. Make sure users know audio and derived transcripts may be sent to Gladia and possibly callback endpoints, choose retention and deletion behavior deliberately, secure callback receivers, and require explicit confirmation before deleting sessions or recorded files.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
client.live().delete(session_id)
Raw REST: `DELETE /v2/live/:id`
This skill instructs use of a third-party live transcription service that streams user audio and supports session/file retrieval and deletion, but it provides no warning about sending potentially sensitive spoken content to an external provider or about consent, retention, and data handling considerations. In a live audio context, users may transmit PII, confidential business discussions, health information, or call content, so omission of privacy and disclosure guidance can lead to unintended exposure and noncompliant deployments.
The manifest describes a skill for real-time speech-to-text streaming over WebSocket with low-latency transcripts, but this file documents post-session management operations including listing historical sessions, downloading recorded audio, and deleting sessions. Those are broader lifecycle and data-management capabilities, not just live transcription streaming implementation details.
The manifest frames the skill as real-time speech-to-text streaming for low-latency transcripts, but this section adds a separate capability to retrieve recorded audio files after the session. Accessing stored media is not an obvious requirement of providing live transcription and expands the skill into recording retrieval.
Deleting sessions and associated data is an administrative data-management action, not a direct or obvious requirement for performing live speech-to-text streaming. This capability goes beyond the manifest's stated purpose of enabling real-time transcription.
The documentation describes deleting a session and associated data without warning that the operation may be irreversible or lead to permanent loss of transcripts and recordings. In an agent context, terse destructive examples can encourage automation to invoke deletion without confirmation, increasing the chance of accidental data loss.
The manifest describes this skill as focused on real-time speech-to-text streaming for low-latency partial and final transcripts. This documentation recommends configurations for post-processing summarization and additional analytics features that go beyond transcription, indicating broader behavior than the stated scope.
The manifest frames the skill as real-time speech-to-text streaming, but this section recommends realtime sentiment analysis, named entity recognition, and post-processing summarization. Those are distinct analytics functions, not obvious implementation details of basic live transcription.
The call center example enables named entity recognition and summarization on customer conversations without any warning about sensitive personal data, consent, retention, or downstream handling. In a call-center context, transcripts commonly contain names, account numbers, phone numbers, and other regulated data, so normalizing these features without safeguards increases the risk of privacy violations and unsafe deployments.
The manifest promises speech-to-text streaming and transcripts, but this example enables translation into additional languages. Translation is a separate capability from transcription and is not described in the stated purpose.
The documentation enables callback delivery of live transcription events and optional analysis features such as translation, named entity recognition, sentiment analysis, and summarization without warning that sensitive spoken content may be transmitted, stored, or exposed to third-party endpoints. In a live transcription skill, omission of privacy and data-handling guidance can lead integrators to deploy unsafe defaults, especially when callback URLs receive user speech-derived data.
This documentation describes a real-time speech processing capability that handles highly sensitive audio-derived data, including transcripts, translations, sentiment, named entities, and summaries, but provides no warning about privacy, consent, retention, or appropriate handling of sensitive content. In the context of a live transcription skill, that omission can lead integrators to deploy the feature in ways that expose PII, confidential conversations, or regulated data without adequate safeguards or user notice.
The JavaScript example sets language_config: { languages: ["en"] }, which can be read as forcing English by default. Because the file does not pair this with guidance to choose the language according to the user's locale or preferences, it may violate language/locale policy expectations.
The Python example uses LiveV2LanguageConfig(languages=["en"]), which presents English as the fixed language configuration. Without accompanying text that this is merely illustrative and should follow user preference, the example creates a locale policy concern.
Several example configurations hard-code "languages": ["en"] for voice agents, call centers, and live subtitles. Because the document presents these as recommended parameters by use case rather than as explicitly region- or customer-specific examples, this can be read as prescribing a fixed language without user opt-in or a documented justification.
Both examples set the language configuration to English only (languages: ["en"]) as the default without explaining that this is merely illustrative or that users may choose other languages. This can be read as enforcing a specific language/locale without user opt-in, which falls under the language policy concern.
The example enables translation and hard-codes target_languages: ["fr"] without indicating that the target language should be user-selected or context-specific. This is a natural-language locale policy issue because it imposes a language choice without documented opt-in or justification.
No suspicious patterns detected.