Healthcare data demands a higher standard than typical SaaS workloads. This page describes the technical and operational measures Leadly Egypt LLC has in place to protect clinic and patient information.
Last reviewed: May 14, 2026 · Questions: security@leadly-egypt.com
Leadly is built on specialist infrastructure providers — each one certified for the workload it handles. We don't run our own servers, and we don't store patient data on the compute layer.
Our application code runs on Render's managed container platform. Render terminates TLS at the edge, auto-renews certificates, and provides DDoS protection.
Patient records, appointments, sessions, conversation history, and clinic configuration live here. Hosted in Europe, on AWS-backed infrastructure with block-storage encryption applied at the platform layer.
noeviction policy — your data is never silently dropped to make roomPatient-uploaded images (receipts, photos sent to the bot) and voice notes are stored here, separately from the database, with signed-URL access.
Subscription billing and payment processing for the clinic itself runs entirely through Stripe. Leadly never sees or stores card numbers — payment fields render directly inside Stripe's iframe, scoped out of our application.
Message content passes through these providers for natural-language understanding, voice transcription, and text-to-speech. All three operate under enterprise data processing agreements.
For phone-number verification, we receive a single short code message from each patient's WhatsApp. We don't store WhatsApp messages — the code is matched against the pending verification in memory and discarded.
Three layers of access control, each enforced independently. A failure in one doesn't bypass the others.
Every database key is prefixed with the tenant identifier
(t:<clinic-id>:customer:<phone>). Application code enforces this on
every query — no shared tables, no joins across clinics, no "global patient search".
One clinic literally cannot see another clinic's data, even if our access control had
a bug, because the keys they could request don't exist in their tenant scope.
Inside a clinic, four roles: owner (full access), doctor (sees their own patients and schedule), receptionist (booking, deposits, calendar), and the AI receptionist itself (most narrowly scoped — only the tools needed for the patient request). Sensitive actions require elevated permissions.
Patients prove phone ownership via WhatsApp before any of their data is revealed. Typing a phone number is never enough — the patient must send a one-time code from their own WhatsApp. This prevents the "type someone else's number, see their appointments" attack that plagues simpler systems.
Patient session cookies are signed with HMAC-SHA256. Even if a session ID leaked, an attacker can't forge a valid signature without our signing secret. Sessions expire after 30 days of inactivity. Staff sessions follow the same pattern with shorter lifetimes.
What happens to your data if something goes wrong.
Upstash takes daily snapshots of every database, retained for 7 days. If the worst happens — accidental delete, ransomware, our own bad deploy — we can restore from the most recent snapshot.
Many Redis deployments evict data when memory is tight. We use noeviction:
if memory fills up, writes fail loudly. We'd rather see a write error and fix the
capacity problem than silently lose patient records.
Critical operations like booking, deposit confirmation, and Stripe events are designed to be idempotent — retried automatically without duplication. Network blips during a booking don't create ghost appointments or double-charged deposits.
Logins, admin actions, booking changes, billing events, and security-relevant events are logged with timestamps and retained on our compute provider's logging infrastructure. Logs are queryable for investigation. We are working toward a first-class queryable audit log with structured actor/target/timestamp records.
Beyond infrastructure, the application layer enforces specific defenses against the categories of attack that target AI receptionist platforms: cost abuse, cross-tenant data leakage, and AI hallucination of unverified facts.
Every inbound patient message — whether from the web chat, WhatsApp, or Instagram/Facebook — passes through three concentric rate limits.
Inbound WhatsApp and payment webhooks are HMAC-verified using the platform's App Secret before any processing happens.
Every database read and write must run inside a tenant-context wrapper. The application layer logs and (in strict mode) refuses any data access that lacks an explicit tenant scope.
Before any AI-generated reply reaches the patient, a post-processing pass checks the message against the session's captured data and the clinic's verified catalog.
The AI is prevented from producing booking-confirmation messages unless an actual booking tool call was executed and a corresponding calendar event was created.
The AI is explicitly prevented from issuing medical opinions or diagnoses. Replies that match medical-advice patterns are intercepted and replaced with an escalation to a licensed clinician.
Three role types per clinic, all administered by the clinic owner. Each role sees only what it needs to do its job.
Full access to the clinic's dashboard, billing, staff management, and AI configuration. Invites doctors and receptionists via time-limited invite tokens. Sees everything the doctor and receptionist roles see, plus settings and analytics.
Sees today's appointments, patient intake summaries, allergies, and clinical notes. Cannot issue admin commands (broadcast, takeover, billing actions) — the dashboard chat is read-only for administrative operations and is intended for clinical questions to the AI copilot.
Sees the live patient activity feed, the outbox queue (messages waiting for human review), and can run administrative commands like marking deposits as received, taking over a conversation, or generating a magic link for a returning patient. Cannot manage billing, staff, or AI configuration.
Email and password, with passwords hashed using scrypt (N=16384). Sessions live in Redis with role-specific TTLs (10 hours for clinic staff, 24 hours for platform operators). Cookies are HMAC-signed and Secure+HttpOnly+SameSite=Lax. Onboarding uses single-use invite tokens that expire after 7 days.
Every third-party service that processes Customer data, with its purpose, region, and certifications. We notify Customers of changes per the Customer Agreement.
If you believe you've discovered a security vulnerability in Leadly, please email us at security@leadly-egypt.com. We will acknowledge your report within two business days and work with you toward a coordinated disclosure timeline.
We do not pursue legal action against good-faith security researchers who follow responsible disclosure: no public disclosure before we patch, no access beyond what's needed to demonstrate the issue, no destruction or exfiltration of patient data.
For PGP, append your public key in the first email and we'll respond encrypted.