Security & Privacy
DentzAI captures lead contact details and forwards them to your practice — that’s it. Your patients’ clinical data stays in your existing systems where it belongs. Below: how the architecture is built, what data we hold, and what we deliberately don’t.
Last updated: April 25, 2026
We capture what you need to follow up — name, phone, email, what they're interested in. We don't capture symptoms, conditions, insurance, or medical questions. PHI is out of scope by deliberate product choice.
Each practice's data is logically isolated. Connections are TLS-encrypted; database storage is encrypted at rest. Field-level encryption is on the roadmap for the most sensitive fields.
HIPAA-grade controls (audit logs, access controls, breach response) are built in. Most practices won't need a Business Associate Agreement because we don't capture PHI — but the architecture is there if you ever do.
The cleanest way to keep clinical data safe is to never capture it in the first place. The bot is configured to redirect any clinical question back to the practice. We don’t store:
The controls below describe how DentzAI is built. They map to standard technical safeguards (encryption, access control, audit logging, isolation) used across regulated SaaS.
Every query against patient-facing data is scoped to your organization at the application layer. Audited 2026-04-24 across 16 PII-bearing models and 220+ database call sites — zero cross-tenant access paths found.
Error tracking (Sentry) and product analytics (PostHog) strip emails, phone numbers, IP addresses, and known PII field keys from every event before it leaves the application. On dental tenants we additionally disable autocapture and session recording so the SDK can't bypass the filter. Code-complete on a feature branch; rolling to production behind a soak-test window.
All connections to DentzAI use TLS 1.2+ enforced at the edge by Vercel. Internal service-to-service calls (Postgres, Redis, OpenAI, Resend, Inngest) are also TLS-encrypted.
Database storage (Neon Postgres) and object storage are encrypted at rest with AES-256 by the underlying providers. Field-level application encryption for the highest-sensitivity columns is on the roadmap.
Authentication via Clerk with mandatory email verification, OAuth, and optional MFA. Multi-tenant role model (owner / admin / analyst / support). Admin operations are gated by an explicit allow-list and audit-logged on every action.
Application-layer encryption for the highest-sensitivity fields, with a per-organization data encryption key wrapped by an AWS KMS customer master key. Enables crypto-shred on tenant deletion.
Every read, write, and delete on sensitive tables is recorded via a Prisma extension. Logs include actor, action, target, timestamp, and request metadata.
Tenant deletion drops the per-org data encryption key, rendering all encrypted records mathematically unreadable while preserving audit-log immutability.
Third-party services that process data on our behalf. We do not transfer data outside the United States. The full subprocessor list and BAA-status detail is in our subprocessors document (linked below).
| Service | Purpose | Data | BAA |
|---|---|---|---|
| Vercel | Hosting + edge compute (US) | All request data | Available on Enterprise (planned) |
| Neon | Postgres database (US) | All persisted data | Available on Scale (planned) |
| Clerk | Authentication | Account credentials, email | Pending upon first covered-entity customer |
| OpenAI | AI inference (chat + embeddings) | Chat transcripts (no training) | Available via OpenAI Enterprise — pending engagement |
| Resend | Transactional email | Recipient address + email body | Pending upon first covered-entity customer |
| Inngest | Background job processing | Job payloads (chat IDs, etc.) | Pending upon first covered-entity customer |
| Upstash | Redis (rate limiting, cache) | Ephemeral session/rate-limit keys | Pending upon first covered-entity customer |
| Sentry | Error tracking | PII-scrubbed exceptions + breadcrumbs | Available on Business — pending |
| PostHog | Product analytics | PII-scrubbed events; on dental: hashed IDs only | Available — pending |
| Stripe | Billing | Payment method, billing address | Not applicable (PCI-DSS scope) |
We capture lead contact information — name, email, phone — and the visitor's expressed interest (e.g., "I'd like to book a cleaning"). That's it. Your practice handles the actual booking and any clinical conversation in your own system.
DentzAI is built on HIPAA-ready architecture (encryption, tenant isolation, audit logs, access controls). Because we deliberately don't capture Protected Health Information (no symptoms, conditions, insurance, or medical questions), most practices won't need a Business Associate Agreement with us. If your workflow ever requires us to handle PHI, we have a draft BAA ready and will sign it.
All storage is in US AWS regions (Neon Postgres for database, Vercel for edge compute and object storage). We do not transfer data outside the United States. Our subprocessor list above shows every third-party service that processes any data on our behalf.
We follow a documented incident-response process: detect → contain → notify. For incidents involving customer data, affected accounts are notified within 72 hours of confirmation, with details of what was affected, what we are doing, and what (if anything) you need to do.
Email security@suppabot.com (we route DentzAI security reports through the same address). We acknowledge within one business day and aim to remediate within the timeline appropriate to severity. Researchers acting in good faith will not face legal action.
Email security@suppabot.com for any of the documents below. Drafts are based on standard templates and marked accordingly.
For customers subject to GDPR or US state privacy laws.
Detailed inventory of every third-party service we use, with purpose, data category, and BAA status.
Available on request for practices whose workflow requires us to handle PHI. Most practices won’t need this — see the FAQ above.