Security
Security & data protection — how DzentAI earns the right to hold patient data
Most software tells you it's secure. Ours has to prove it every night — to a test suite that blocks the release when it disagrees. This page is written to be forwarded — to your office manager, your IT consultant, or your compliance reviewer.
Built and working — all data synthetic today. Pilot practices onboarding fall 2026.
The software that attacks itself
Every night, DzentAI runs an adversarial suite against its own production code: roughly 12,000 checks — every API endpoint crossed with every staff role, patient access, and administrative tier — verifying that each one admits exactly who it should and refuses everyone else. The expected answers come from an independently maintained intent record, not from the code being tested, so the code can never quietly grade its own homework. If a single check fails, the next release is blocked — automatically, by the pipeline itself — and an alert is filed. This is not an annual audit. It's last night.
Isolation the database enforces
Every practice's data carries its tenant identity down to the database row, and the database itself — not just our application code — refuses to return one practice's rows to another. This row-level security is tested behaviorally on every build with real SQL, including deliberate cross-tenant attack attempts that must come back blocked.
Three keys, three doors
Staff, patients, and platform administrators are three cryptographically separate worlds: distinct signing keys, distinct token audiences. A patient's portal login is structurally incapable of opening a staff screen — the rejection happens in the cryptography, before any application logic runs. Administrative access adds a tiered-privilege ladder and TOTP multi-factor authentication.
Records that can't be quietly changed
Signed clinical notes are immutable — signed means signed. Posted payments, remittances, and adjustments are append-only: corrections are new entries, never silent edits. Every change to a chart is written to an audit trail with the author's name.
AI with a human gate
Everything the AI produces, a clinician confirms before it enters the record. The AI cannot invent a billing code — suggestions come from a closed, verified set, re-checked at the moment of application. And the platform refuses to learn from anything that could identify a patient: records that fail de-identification are declined, and cross-practice learning only activates when enough de-identified data stands behind it to make identification mathematically implausible.
For technical reviewers: the deeper mechanics
The detail behind the promises above — the level your IT consultant or compliance reviewer will want.
A deterministic safety spine
Medical alerts, periodontal staging (2017 AAP), and exam gating are deterministic rule systems, not model output. Language models draft; rules and clinicians decide. A missing input is surfaced as a named gap — it is never defaulted to "healthy".
K-anonymity, enforced in code
Cross-practice learning surfaces only patterns observed at 2 or more distinct practices with 3 or more samples. The floor is enforced in the aggregation code and covered by tests — when there isn't enough data, the system says so instead of guessing.
Three isolated data planes — 168 tables
168 database tables across three isolated planes: tenant clinical records (row-level security in the database), de-identified cross-practice learning, and public clinical terminology. The de-identification boundary is whitelist-only: fields not explicitly permitted never cross, and records that fail validation are refused.
Licensing that fails closed
The clinical-terminology engine (107,862 codes ingested) refuses to load licensed code sets until the license is on record — sets default to unlicensed and are hard-refused, and descriptors follow what each license permits. The guard fails closed, never open.
Built for your HIPAA obligations
A Business Associate Agreement with every practice we serve · encryption in transit and at rest on Microsoft Azure · role-based access with least-privilege defaults (your front desk sees front-desk screens) · full audit trail · MFA. We publish what we do, not badges: HIPAA has no official certification, and any vendor claiming one is telling you something.
Eligibility and claims are built on Stedi's HITRUST e1-certified clearinghouse infrastructure.
Where we are today: all data in the product is synthetic — no real patient data has been processed. Go-live for a real practice is gated on executed BAAs across our stack and on commercial code-set licenses, a checklist we complete with each pilot practice.
Ask us anything
Ask us anything on this page in your demo — including the parts we're still improving. We'd rather earn trust than assert it. Questions a reviewer would ask that aren't answered here? Email hello@dzentai.com and we'll answer in writing.