Voice AI data security: Risks, controls, and checklist

What counts as voice AI data?

Voice AI data is any information captured, created, retrieved, or transmitted while an agent handles a conversation. The recording is only one part of it.

These artifacts have different risks. A raw recording is not automatically a voiceprint. Under the General Data Protection Regulation (GDPR), biometric data receives special treatment when technical processing relates to unique identification. California law includes linked audio information within personal information and defines biometric information to include voice recordings from which an identifier template, such as a voiceprint, can be extracted. Biometric information processed to uniquely identify a consumer is also sensitive personal information. Treat all linked customer data as sensitive, but do not use one label for every artifact.

Where voice AI security can fail

A production voice agent is a chain of systems. A phone or browser sends media through a carrier or real-time transport layer. Speech recognition turns audio into text. The agent runtime sends selected context to a model, may retrieve knowledge, and can call customer systems. Speech synthesis produces the reply. Webhooks, observability tools, staff consoles, exports, and backups create more copies.

Security can fail at any boundary:

• Too much data enters the pipeline. The agent captures a full recording when a short-lived stream would meet the purpose, or sends an entire customer record when one field would do.
• One service is treated as the whole system. The public API uses encryption, but a webhook, internal queue, exported file, or support workflow does not receive the same protection.
• Access is broader than the job. A shared service identity can read every tenant, a developer can download production calls, or a tool can update more fields than the conversation requires.
• Speech and retrieved content are trusted as instructions. A caller can speak a prompt-injection attempt, while a CRM note, email, web page, or knowledge document can contain an indirect instruction. Retrieval-augmented generation does not make that content trustworthy. OWASP's prompt-injection guidance notes that the impact grows with the model's access and agency.
• Sensitive data appears in secondary systems. Transcripts, tool arguments, model traces, quality dashboards, and incident tickets can hold the same information as the call.
• Deletion stops too early. Removing the audio file leaves the transcript, summary, embedding, export, processor copy, cache, or backup untouched.
• Vendor settings and contracts do not match the architecture. A provider may retain data by default, process it in an unapproved region, use another subprocessor, or offer a control only on a different plan.

Threat modeling makes these boundaries explicit. The useful questions are simple: What can go wrong? What control prevents or detects it? How will the team prove that control still works after a model, tool, vendor, or data flow changes?

This is an illustrative vendor-neutral flow. The providers, trust boundaries, and responsibilities in a production deployment will vary.

Nine controls for voice AI data security

1. Map the full data flow and assign owners

Create one inventory that follows data from capture through deletion. Include the carrier, media service, speech providers, agent runtime, model, retrieval system, tools, customer databases, webhooks, analytics, staff consoles, exports, and backups.

For each artifact, record:

• business purpose and data classification;
• people or tenants affected;
• source, destination, region, vendor, and subprocessor;
• human and machine identities with access;
• whether the data is used for training or product improvement;
• retention, deletion, backup expiry, and legal-hold handling;
• the engineering and business owner.

This turns "we secure voice data" into a control set that can be tested. It also follows the asset and data-flow outcomes in the NIST Cybersecurity Framework 2.0.

2. Collect and retain less

The safest sensitive record is one you did not create. Default to no audio recording when live processing and a narrow outcome are enough. If a transcript is required, decide whether it needs to be verbatim, redacted, summarized, or retained after the workflow completes.

Apply the same discipline to model context and tools. Send a delivery status instead of an entire order. Retrieve the minimum knowledge chunk. Keep diagnostic traces for less time than the customer record. Disable vendor training or secondary use unless it is intentionally approved and covered by the relevant notice and contract.

Retention should be specific to the artifact and purpose. "Delete the call" is not a complete policy unless it defines what happens to audio, text, derived data, logs, exports, processors, and backups.

3. Encrypt data and manage keys and secrets

Encrypt sensitive data in transit across the whole path, including the public endpoint, internal services, and webhooks. Encrypt retained recordings, transcripts, derived data, exports, and backups with managed keys. Separate keys from the data they protect and document generation, rotation, revocation, recovery, and emergency replacement.

Put API keys, certificates, database credentials, and webhook secrets in a managed secret store. Prefer scoped and short-lived service credentials. Never put a secret in a system prompt, transcript, test fixture, client-side bundle, or ordinary log.

Encryption is necessary, but it is not enough. It does not fix excessive collection, a user with the wrong permissions, cross-tenant access, prompt leakage, or a backup that never expires.

4. Enforce least privilege and tenant isolation

Use single sign-on and multi-factor authentication for staff. Separate development, staging, and production. Give people distinct read, write, export, support, and admin permissions where the platform supports them. Review access on a schedule and remove it immediately when a role changes.

Machine access needs the same treatment. Give each service and tool its own identity, tenant scope, allowed operations, and credential. Do not let an agent use a shared superuser connection to a customer database.

For multitenant products, derive tenant context from the authenticated session rather than a client-supplied tenant ID. Enforce that context in the database, cache, queue, object store, vector index, file layer, logs, and exports. Test direct object references, stale caches, background jobs, and offboarding for cross-tenant leakage. The OWASP multi-tenant security guidance is a useful implementation reference.

5. Treat caller input, retrieved content, and model output as untrusted

Treat caller speech, retrieved documents, and tool results as untrusted input. A natural-language instruction must not, by itself, authorize a sensitive action. Keep trusted instructions separate from untrusted content, but do not assume delimiters or a carefully worded prompt will stop injection.

This vendor-neutral pattern illustrates the policy boundary: the model proposes an action; deterministic server-side controls decide whether it can execute.

Enforce policy outside the model:

• expose only granular, allowlisted tools;
• authorize every action on the server for the current user and tenant;
• validate tool arguments against strict schemas and business rules;
• restrict network egress and destination domains;
• set rate, cost, time, and step limits;
• treat model output as untrusted before it enters SQL, HTML, email, file paths, or another tool;
• apply risk-based step-up controls to high-impact actions, with human or out-of-band approval where the risk and policy warrant it, including for sensitive payments, credential resets, disclosures, account changes, and destructive actions.

Red-team spoken, multilingual, obfuscated, multi-turn, and indirect attacks before release and after changes. Include attempts to extract another customer's data, reveal prompts or secrets, misuse tools, and persist a malicious instruction through memory or retrieval.

6. Secure webhooks and downstream tools

Use HTTPS for every integration. When a provider supports signed webhooks, verify the signature over the raw request body before parsing. Check signed timestamps or another freshness value to reduce replay risk. Use constant-time comparison, rotate secrets, reject stale or malformed deliveries, and keep secrets out of URLs.

Design handlers to tolerate retries and duplicate delivery, with idempotency controls when an event can change state. Validate a small schema, enforce body and rate limits, acknowledge quickly, and move slow work to a protected queue. Minimize the payload: a downstream system should not receive the full transcript when it needs only a call ID and outcome.

Authentication at the webhook endpoint is only the start. The receiving system, its logs, its queue, and any later automation become part of the voice AI security boundary.

7. Control recordings, transcripts, and derived data separately

Recording notice and consent depend on the jurisdictions, people, purpose, and type of call. Do not rely on a universal "one-party consent" rule: federal law has a limited one-party exception, while states and other countries can impose stricter duties. Give the application a recording-off mode and, where the workflow needs it, pause or redact both audio and transcription before sensitive input.

Restrict playback, download, search, export, and support access. Log those actions without copying the sensitive content into the audit event. Test whether a deleted user or expired link can still retrieve the file.

Build deletion as an orchestrated workflow. It should remove or expire the recording, transcript, summary, extracted fields, embeddings, caches, exports, and processor copies, then record completion. Backups and legal holds may need separate documented expiry or exception paths; do not promise instant physical erasure when the architecture cannot provide it. NIST SP 800-88 Rev. 2 provides current media-sanitization guidance.

8. Govern every vendor and subprocessor

Map every organization that can receive raw audio or derived data, including carriers, speech providers, model hosts, retrieval services, observability tools, support systems, and subprocessors.

Ask each provider:

• What exact artifacts do you collect or derive?
• What is retained by default, and which settings change it?
• Does customer data train shared models or improve shared services?
• Where is data processed, stored, replicated, and backed up?
• How are tenants isolated and staff access controlled?
• Who holds encryption keys?
• Which subprocessors are involved, and how are changes communicated?
• Which contract, data-processing, healthcare, or payment terms apply to this exact service?
• What logs, incident notice, deletion verification, portability, and exit support are available?

An audit report or certification can support due diligence. It does not prove that your particular call flow, settings, tools, and retention policy are secure or compliant.

9. Monitor, test, and rehearse response

Record security events that help you investigate an incident: authentication and admin changes, exports and playback, authorization results, tool calls, secret rotation, webhook verification failures, cross-tenant denials, unusual volume, deletion jobs, and vendor or model changes.

Do not solve monitoring by logging every prompt and transcript forever. Passwords, tokens, encryption keys, payment-card data, and unnecessary personal or health data should not appear directly in ordinary logs. Separate protected audit events from short-lived, redacted debugging traces.

Connect alerts to response playbooks. Rehearse leaked credentials, cross-tenant exposure, prompt-injection tool misuse, malicious exports, compromised providers, payment-data capture, health-data leakage, and voice-clone fraud. Preassign owners, escalation contacts, credential-revocation steps, and kill switches for tools or recording. NIST SP 800-61 Rev. 3 places incident response inside continuous cybersecurity risk management rather than treating it as a document opened after a breach. The same ownership, alert, and recovery discipline belongs in a broader voice AI site reliability engineering program.

Does on-premises voice AI solve data security?

On-premises deployment can reduce external processors and give you more control over residency, keys, access, and retention. It does not secure the system by itself. Carriers, speech and model services, monitoring tools, updates, backups, and administrator access may still cross the boundary, while your team owns patching, isolation, logging, deletion, and incident response. Apply the same data map and evidence checklist to every deployment model.

How security changes for regulated or high-risk data

Security, privacy, recording consent, telemarketing, and sector rules overlap, but they are not the same. The table below is a technical scoping guide, not legal advice. Counsel should determine the duties for the actual jurisdictions and use case.

Voice AI security review checklist

Before launch, verify that the team can answer yes to each item:

• We mapped the full voice-data flow, trust boundaries, regions, vendors, and subprocessors.
• We classified live audio, recordings, transcripts, model context, retrieval, tool payloads, derived data, logs, exports, and backups separately.
• Each artifact has an approved purpose, owner, access policy, retention period, and deletion path.
• Recording is off by default where live processing is enough, with notice and pause or redaction controls where needed.
• Every network hop and sensitive store is protected, and keys and secrets have rotation and revocation procedures.
• Human roles, service identities, environments, tenants, tools, and network egress follow least privilege.
• Webhooks are authenticated and, where supported, signed and replay-resistant; handlers are validated, rate-limited, and idempotent.
• Agent actions are authorized outside the model, with strict arguments and risk-based step-up controls or approval for high-impact work.
• Payment and health data stay inside their approved capture, contract, and processor boundaries.
• Logs help detect misuse without becoming a second copy of every sensitive conversation.
• Deletion reaches derived data, exports, processors, and documented backup expiry.
• Vendors supplied evidence for the exact service, plan, deployment, regions, subprocessors, retention, and incident process we use.
• Red-team tests cover spoken and indirect prompt injection, cross-tenant access, data exfiltration, and tool misuse.
• Incident playbooks, notification decisions, escalation contacts, and kill switches have been exercised.
• A new model, tool, vendor, region, recording mode, or authentication feature triggers another review.

What we manage and what your team owns

We provide the managed runtime, web application, and API surface for voice AI agents. Your team controls the use case, recipients, business rules, customer data, downstream tools, telephony choices and configuration, recording choices, compliance policy, and production acceptance. Our terms of service place responsibility for recipients, content, timing, recording consent, privacy configuration, and customer-selected integrations with the customer.

Our conversations generate transcripts and metadata, and audio recording is configurable. We provide bearer API keys and Admin and Developer organization roles, plus searchable operational activity logs. These are data surfaces and operating controls to include in your architecture review; they are not a blanket compliance result.

Call-recording media links currently use a public, unauthenticated endpoint. Access is controlled by possession of the URL rather than a Dasha API key or organization role. Treat recording URLs as sensitive capability links: do not expose them in public pages, logs, tickets, analytics, or untrusted downstream systems; restrict who can receive them, and confirm the behavior for the exact deployment before relying on it.

For a regulated or sensitive deployment, confirm data locations, retention and deletion behavior, subprocessors, access boundaries, incident terms, and enabled-artifact protections with us for the exact service, contract, and configuration you plan to use. Do not infer that one feature, report, or certification makes the complete application compliant.

Compare our managed runtime with a custom stack using the voice AI backend architecture and managed-versus-DIY guide. Evaluate both options against the same data map, controls, and evidence requirements.