Security Practices

Production runs on AWS in the Mumbai region (ap-south-1). The data plane is split across three providers, each isolated to its own purpose:

• Compute — stateless API servers and worker processes run on EC2 behind an Application Load Balancer with TLS termination. The voice agent and meeting agent are containerised; horizontal scaling is automated.
• Database — Postgres, managed by Supabase, in a private network with no public internet ingress. Daily encrypted backups, point-in-time recovery for 7 days.
• Object storage — AWS S3 buckets in ap-south-1 forcall recordings and static assets. Bucket policies deny public access by default; recordings are served via short-lived pre-signed URLs.

Production secrets live only in environment variables managed at deploy time. They are not committed to source control, and the application enforces this with a startup check that rejects placeholder values.

• In transit: TLS 1.2 minimum, TLS 1.3 preferred, on every external surface — web, API, websocket, S3 download URLs, telephony bridge (PSTN/Twilio media streams over WSS).
• At rest: AES-256 server-side encryption on the S3 bucket; transparent disk encryption on Supabase Postgres; AES-256 disk encryption on EC2 instance volumes.
• Secrets: All API keys, database credentials, and signing keys are stored as environment variables in the deployment environment. Never in code, never logged, never returned in API responses.

Multi-tenancy is enforced in the database layer, not just the application layer. Every customer-owned table has Postgres row-level security (RLS) enabled with a policy that scopes rows by auth.uid() or by the workspace ID derived from the authenticated session. The application server holds an anon key with the same restrictions an end user would; only narrowly-scoped server-side jobs use the service role.

Internal access to production by Converlane staff is granted on a need-to-know basis, requires hardware-key MFA, and is logged. Production database queries by staff are recorded and reviewed.

Customer authentication is handled by Supabase Auth:

• Magic-link email sign-in via our own Resend / SES email pipeline.
• Email + password sign-in with per-user salted password hashes (bcrypt).
• Password reset over a short-lived signed link.
• OAuth via Google and Microsoft for workspace SSO.
• Two-factor authentication via TOTP is on the roadmap for Q3 2026.

Sessions are issued as short-lived JWTs with refresh-token rotation. Auth state is persisted in HTTP-only cookies; we do not put bearer tokens inlocalStorage.

Every webhook we send to a customer endpoint is signed with HMAC-SHA256 using a per-tenant signing secret. The signature is delivered in the X-Converlane-Signature header along with a timestamp. Receivers should:

1. Recompute the HMAC over the raw request body and the timestamp.
2. Compare in constant time.
3. Reject any request whose timestamp is more than 5 minutes away from now (replay-window protection).

Inbound webhooks from Razorpay and Meta WhatsApp are similarly verified before any state-changing action is taken.

We rate-limit at two layers. At the edge, the load balancer absorbs volumetric spikes and obvious DDoS patterns. In the application, we run a Postgres-backed token-bucket limiter (table rate_limit_buckets) that scopes by API key and by source IP; limits are tuned per route based on cost. Public endpoints (sign-up, OTP request, public-pitch landing) have stricter buckets to deter abuse. When a bucket is exhausted we return 429 Too Many Requests with a Retry-After header.

The voice and meeting agents apply additional concurrency caps per workspace. This prevents a runaway script from spending the wallet, accidentally launching hundreds of parallel calls, or saturating telephony quotas at our upstream carriers.

We treat application security as a development practice, not a compliance afterthought.

• Dependency hygiene. Lockfiles for both the frontend (npm) and the Python services (pip-compile) are committed and reviewed on every PR. Dependabot opens upgrade PRs for security advisories; we triage critical CVEs within 72 hours.
• Type safety. The web frontend is TypeScript-strict and the build fails on type errors. Backend services use Pydantic for runtime validation of every external input.
• SQL injection. All database access goes through the Supabase client or parameterised SQL. Raw string interpolation into SQL is forbidden by convention and reviewed in PRs.
• Cross-site scripting. React escapes by default; we never usedangerouslySetInnerHTML on user-provided content.
• CSRF. Cookies are SameSite=Lax; mutating endpoints require a bearer token, not just a session cookie, when called from cross-origin.
• Logging. Application logs are structured JSON, scrubbed of API keys, JWTs, signed S3 URLs, and request bodies for sensitive routes. We retain them long enough to investigate an incident, no longer.

A security incident is anything that could expose customer data or compromise the integrity of the service. When one is detected:

1. We acknowledge it internally within 1 hour and assign a single engineer as incident commander.
2. We contain the issue (rotate keys, revoke sessions, isolate hosts) before communicating externally.
3. We notify affected customers without undue delay — and within 72 hours where the GDPR or DPDP Act requires it — with a description of what happened, what data was affected, what we have done, and what we recommend they do.
4. We publish a post-incident review for material incidents, including the root cause, the timeline, and the corrective actions.

If you have found a security issue, we want to hear about it.

• Email security@vaanilabs.in with a description of the issue, reproduction steps, and any suggested mitigation.
• We acknowledge reports within 2 business days and aim to provide a remediation timeline within 14 days.
• We support coordinated disclosure: please give us reasonable time to ship a fix before publishing.
• We do not currently run a paid bounty program; we will publicly credit researchers who responsibly disclose, with their consent.
• A PGP public key for sensitive reports is in preparation and will be linked here when published.

A current list of every sub-processor we use, with their function and processing region, is maintained in our Privacy Policy. We notify customers at least 14 days before adding a new sub-processor with material scope.

• SOC 2 Type II — readiness work in progress; targeting an observation window starting Q4 2026.
• ISO/IEC 27001 — planned for 2027 once SOC 2 controls are in steady state.
• India DPDP Act compliance — implemented across the data lifecycle today; will be re-validated as the implementing rules are notified.
• GDPR & UK GDPR — Standard Contractual Clauses are signed with EU/UK customers on request; a Data Processing Addendum is available.

Enterprise pilots include a sales-facing trust pack before live traffic begins: security practices, architecture notes, sub-processor list, DPA answers, audit-chain explanation, operational checklist, and recording/transcript handling notes.

For paid pilots, we also provide an ROI pack with before/after targets and a tech pack with API, webhook, SDK, MCP, CRM, and meeting-agent setup guidance. Review the full enterprise adoption package, start the intake on the Enterprise Pilot page or email security@vaanilabs.in for a security questionnaire.

We are an early-stage company and have not yet completed an external security audit. As soon as we do, we will link the most recent attestation here. Until then, we are happy to share our internal threat model, infrastructure diagram, and answers to standard vendor security questionnaires under NDA — email security@vaanilabs.in.