Trust Center
Clinics hand Vantra their front door: calls, messages, bookings, and the personal data inside them. This page sets out — plainly and verifiably — how that data is protected, what third parties touch it, how long it is kept, and what we will sign. If a claim on this page names a mechanism, that mechanism exists in the product today.
Encryption & data protection
Where personal data lives, and how it is protected at each layer. We state exactly what is field-encrypted rather than making a blanket claim.
Encryption in transit
All traffic between browsers, phones, our APIs and our datastores is encrypted with TLS.
How: HTTPS-only hosting (Vercel) and TLS connections to Google Cloud Firestore and every subprocessor API.
Patient identifiers encrypted at rest
Patient-identifying fields in server-only stores — caller memory (names, emails, preferences) and archived conversation sessions — are field-encrypted with AES-256-GCM on top of Google Cloud's disk-level encryption, and production refuses to treat encryption as optional: a missing key is flagged loudly at boot.
How: AES-256-GCM envelope encryption (phi:v1) with boot-time key checks; Google Cloud encrypts all stored data at the infrastructure layer.
No patient identifiers in logs
Phone numbers are never written to operational logs in full — they are redacted to a dialing prefix and last two digits, with a keyed one-way token when correlation is needed.
How: Central log-redaction helpers (redaction + keyed HMAC-SHA256 correlation tokens) used across the platform.
Tenant isolation
Every clinic's data is scoped to that clinic. Database rules are default-deny; every API route independently authenticates and checks the caller's authority over the specific clinic it names.
How: Default-deny Firestore security rules plus per-route server-side authorization (principal + per-clinic role checks) on every API endpoint.
Auditability & provenance
You should not have to take our word for what happened in your tenant.
Tamper-evident audit log
Privileged and sensitive actions are written to a per-tenant audit log where every entry is hash-chained to the previous one — altering or deleting a historical entry breaks the chain and is detectable.
How: Per-tenant SHA-256 hash chain with transactionally-advanced chain heads and a verification endpoint that re-walks the chain.
Fail-closed auditing of exports
Data exports (patient subject-access exports, audit-log exports) are themselves audited before the data leaves — if the audit entry cannot be written, the export does not happen.
How: Strict audit writes precede every export response; the export endpoint returns an error when the audit write fails.
Provenance on writes
Governed data changes carry who did it, through which channel, and what changed — an append-only event ledger alongside the data itself.
How: Append-only entity-events ledger recording actor, source channel, field changes and trace links for governed mutations.
Audit-log export for your compliance team
Clinic managers can export their own tenant's audit log — including the chain hashes and an integrity verification result — for retention or external audit.
How: Self-service export endpoint (manager-and-above) returning chained rows plus the chain-verification verdict, itself audited fail-closed.
AI safety & communication controls
The agent works inside guardrails; it does not improvise on safety.
Emergency handling fails conservative
Messages that look like emergencies short-circuit the assistant and surface emergency guidance. When the emergency classifier cannot decide, it treats the case as unresolved rather than clear.
How: Deterministic pre-LLM emergency gates plus an LLM classifier whose failure mode appends emergency guidance instead of clearing the case.
Opt-outs are honored durably
A person who opts out of calls is suppressed at the task level — an opted-out contact is never re-queued by any automated campaign, regardless of how old the opt-out is.
How: Suppression records checked by every automated enqueue path (reactivation, waitlist offers, reminders, revenue calls).
Guarded outbound calling
Automated calls respect per-clinic calling windows, daily caps, per-purpose cooldowns, and a global kill switch. Money-spending paths are rate-limited with limits that fail closed.
How: Distributed (cross-instance) rate limiting with fail-closed semantics on dialing paths; per-clinic cadence policies; an operator kill switch read at call time.
Every change to agent behavior is regression-tested
Prompt, tool and model changes must pass a golden-scenario evaluation suite in CI before they ship — including prompt-injection resistance and grounding checks.
How: A CI-gating eval harness replaying scenarios through the production agent orchestrator on every change.
Retention & deletion
Retention is enforced by a daily job, not by policy documents alone. Clinical-record retention is deliberately a per-clinic policy decision — many jurisdictions require multi-year retention — so it is configurable rather than hard-coded.
Scheduled deletion
Operational data ages out automatically on a daily schedule with per-category windows.
How: A daily data-retention cron with bounded deletes; webhook dedup and rate-limit records also expire via TTL fields.
Subject-access & deletion requests
We support data-subject access requests with a single-document export of everything held about a person at a clinic, and honor deletion requests subject to the clinic's legal retention obligations.
How: Audited subject-access export endpoint; deletion handled with the clinic as controller of record.
Default retention windows
| Data | Retention |
|---|---|
| Webhook replay-protection records | Expire automatically (TTL) — hours to days |
| Rate-limit counters | Expire automatically (TTL) — hours |
| Website-demo logs | Deleted after 30 days |
| Error diagnostics | Deleted after 90 days |
| Dead-letter queue entries | Deleted after 30 days |
| Agent turn telemetry | Expires after 90 days |
| Call logs & archived conversations (clinical records) | Retained per the clinic's own policy — configurable window, off by default because medical-record law often requires 6–10 years |
Subprocessors
Third parties that process data on Vantra's behalf. The same table forms the sub-processor annex of our Data Processing Agreement; customers are notified of changes per their DPA.
| Provider | Purpose | Location |
|---|---|---|
| Google Cloud / Firebase | Database, authentication, file storage | US / EU (region-configurable) |
| Vercel | Application hosting, scheduled jobs, operational logs | US / EU |
| Twilio | Telephony and WhatsApp transport | US |
| Meta Platforms | WhatsApp Cloud API, Instagram, Messenger | US / EU |
| OpenAI | Language models, call transcription | US |
| LiveKit | Realtime voice infrastructure (SIP) | US / EU |
| Cartesia | Text-to-speech voices | US |
| ElevenLabs | Text-to-speech voices | US |
| Soniox | Speech recognition / text-to-speech | US |
| Google Calendar | Appointment calendars (when the clinic connects one) | US / EU |
| Stripe | Subscription billing; optional patient payment links run on the clinic's own Stripe account | US |
| Resend | Transactional email | US |
What we sign
Data Processing Agreement (DPA)
Processor terms covering instructions, confidentiality, security measures, sub-processors, data-subject rights, breach notification and deletion — with jurisdiction variants for GDPR, UK GDPR and Turkish KVKK. Includes the full security-measures annex and the sub-processor table above.
Business Associate Agreement (BAA)
For US covered entities under HIPAA: permitted uses, safeguards, breach notification, subcontractor flow-down, individual-rights support and return/destruction of PHI on termination.
Outbound-consent warranty
For clinics running outbound campaigns: warranties on consent basis and list provenance, suppression-list handling, and the agent's self-identification on calls (modelled on the Turkish İYS regime, adaptable per market).
To request any of these, a security questionnaire response, or a walkthrough of the audit verification, write to info@vantra.xyz.
This page describes product mechanisms, not legal advice. Where a jurisdiction requires specific terms (GDPR, UK GDPR, KVKK, HIPAA), the signed agreement for your clinic is the authoritative document.