Security checklist for production voice agents
Production voice agents need tenant isolation, encrypted provider keys, signed integrations, audit logs, retention controls, export and deletion paths, and runtime safety policies.
Protect production voice agents
tenant isolation, retention, and runtime guardrails
Short checklist
A production voice agent should protect both the operator workspace and the human user in the conversation. That means securing credentials, isolating tenant data, signing external events, limiting retention, exposing audit trails, and making export or deletion workflows possible.
- Keep workspace API keys on the server; browsers should use signed session tokens.
- Encrypt provider keys before storage and never expose plaintext to operators.
- Enforce tenant isolation at the database layer.
- Sign webhooks and reject unsafe callback targets.
- Store audit records for privileged operator actions.
- Provide user export and deletion workflows.
- Apply runtime guardrails before assistant output reaches the user.
Credential handling
Voice agents often need model, speech, voice, telephony, webhook, and internal API credentials. Provider keys should be encrypted with envelope encryption, decrypted only when a conversation needs them, and hidden from normal operator views.
A workspace API key should never be shipped to a web page or mobile client. Use your backend to create a signed session URL or token, then hand only that scoped session credential to the client.
Data boundaries
Tenant isolation should not depend only on application code. Database-level row-level security gives the platform a second boundary when queries evolve. Every tenant-scoped entity should carry a tenant ID, and every repository path should respect that boundary.
| Control | Purpose | Operator question answered |
|---|---|---|
| RLS tenant isolation | Prevent cross-workspace data access | Can another workspace see this user? |
| Audit log | Record privileged changes | Who changed the agent, key, member, or policy? |
| Retention controls | Limit long-term exposure | How long do transcripts or recordings stay? |
| DSAR export and forget | Support user rights workflows | Can we export or delete this user data? |
Runtime safety
Static policy documents are not enough for agents that talk to customers. Runtime safety checks should run where risk appears: before assistant output, around retrieval, near tool calls, and during escalation decisions.
For sensitive products, teams should define no-go zones, escalation rules, sleep windows, fatigue handling, and topic cooldowns before launch.