Security at VaaniLabs
Last updated: 29 July 2026
VaaniLabs runs AI voice agents that handle sensitive conversations — collections, support, and commerce — for Indian lenders, NBFCs, D2C brands, and enterprises. That means we hold borrower and customer contact data, call recordings, transcripts, and connected-source data. This page describes how we protect it and, just as importantly, what we are still hardening. We would rather be honest about the roadmap than claim guarantees we don't have.
1. Encryption at rest
Stored credentials and secrets are protected with AES-256-GCM field-level encryption. Critically, the master encryption key is held outside the database — so a database dump on its own is useless without the key, and cannot be decrypted by an attacker who obtains only the stored data.
2. Encryption in transit
All traffic between clients, our services, and our media and model providers is protected with TLS. Call media is carried over encrypted transport.
3. Tenant isolation and row-level security
Each customer workspace is isolated. We store data in Postgres (Supabase) with per-workspace row-level security (RLS), so one tenant's queries cannot reach another tenant's rows even in shared infrastructure.
4. Secrets handling
Connected-source credentials (for a customer's CRM, spreadsheet, or database) and other secrets are encrypted at the field level with the key held outside the database, as above. They are decrypted only in memory at the moment a call needs them and are never written to logs or transcripts in plaintext.
5. Sensitive-field redaction before the model
Sensitive fields — passwords, card numbers, CVV, Aadhaar, and tokens — are redacted before any data reaches the AI model or the transcript. The model sees what it needs to hold the conversation, not the raw secret.
6. The compliance gate and KMS-signed audit chain
Every outbound dial passes through a compliance gate that checks calling hours, consent, frequency caps, and DND before a call is allowed. Agents carry a pre-call identity disclosure. Each of these decisions is hashed and KMS-signed into an append-only audit chain, so the compliance record is tamper-evident and cannot be silently rewritten after the fact.
7. Access controls
The console is gated behind authentication, with signed session cookies and security headers. Access to a workspace is limited to that customer's authorised users, and internal access to production systems follows least-privilege principles.
8. Call recording and transcript handling
Recording is a per-customer setting. Where enabled, caller and agent audio tracks and transcripts are stored in the customer's workspace and retained for the period the customer configures, after which they are deleted or anonymised. Recordings and transcripts inherit the same encryption, isolation, and redaction protections described above.
9. Data residency — an honest note
Our goal is India-region processing, and we architect toward it. However, some voice and language models we depend on (for example, Gemini Live) may process call data outside India under a cross-border agreement. We do not claim 100% India-only processing today. If strict residency matters to you, talk to us about India-resident model configurations.
10. Responsible disclosure
If you believe you have found a security vulnerability, please report it to legal@starvoxlabs.io. We welcome good-faith research, will acknowledge your report, and ask that you give us a reasonable window to remediate before any public disclosure. Please do not access, modify, or exfiltrate other users' data while testing.
11. What we're still hardening
Security is a roadmap, not a finish line. We are actively working on moving key management fully to a managed cloud KMS/HSM, expanding audit and anomaly monitoring, and pursuing formal SOC 2 and ISO 27001 programs. We are not yet certified under those frameworks and will not claim otherwise until we are. We will update this page as these mature.
Questions? Contact legal@starvoxlabs.io