Security at Kavach
Every architectural choice we make is also a security choice. This page describes — concretely, no vague reassurance — how we encrypt, authenticate, log, and defend the data you trust us with.
01Principles
- Minimize — collect only the data needed to deliver a specific user-visible feature.
- Encrypt everywhere — at rest, in transit, in backups, in transit between internal services.
- Own the audit trail — every LLM call, every admin action, every Doctor Bridge access is logged in our own database, not a third-party SaaS.
- No silent partners — every external service that touches user data is enumerated in the Privacy Policy with a corresponding DPA.
- Default deny — feature flags off, rate limits on, suppression respected, kill switches wired before features ship.
- Boring on purpose — we prefer deterministic, testable safety code over clever AI-mediated guardrails.
02Data security rails
Encryption at rest
All user records — labs, vitals, meds, chat messages, document images — are stored in encrypted form. Backups inherit the same encryption.
AES-256-GCM · per-user-keyed where applicableEncryption in transit
Every request between the Kavach app and our API, and between our internal services, runs over modern TLS. HSTS is set; the public marketing site is forced over HTTPS at the Cloudflare edge.
TLS 1.3 preferred · TLS 1.2 minimum · HSTS max-age 1 yearData residency
Your primary record lives in India-approved regions. Cross-border egress happens only for the limited LLM-inference and email-delivery purposes enumerated in the Privacy Policy §4.
Primary store: IN region · Backups: same regionData minimization
The cloud LLM gets the specific prompt and a curated context window — not your entire history. Crash reports are scrubbed of personal data before they leave the device. Telemetry events are categorical, not free-text.
PII scrubber on Sentry hooks · LLM context whitelist · No free-text telemetryData deletion
When you delete your account, the primary database is hard-purged within 30 days. We do not currently operate a separate redundant backup of the production database, so deletion within this window is final. Audit logs of the deletion event itself are retained for compliance purposes (no PII in those logs).
Hard delete < 30d · no redundant backup · per-user purge query03Authentication and session
Phone + OTP login
Login is phone-based with a single-use OTP sent via SMS. OTPs expire in 10 minutes and are bounded to 5 attempts per 10-minute window per phone. Invalid attempts are rate-limited per IP and per phone.
6-digit OTP · 10-min TTL · 5-attempt cap · per-phone + per-IP rate limitJWT sessions with rotation
Successful OTP issues a short-lived access token plus a long-lived refresh token. Refresh tokens are rotated on every use; reuse of a stale refresh token revokes the entire session family.
Access JWT 15 min · refresh 30 days · rotation-on-use · reuse-detection family revokeBiometric on cold start
When a logged-in user reopens the app from a cold start, the device's biometric (fingerprint or face) is required before any data is decrypted for display. The biometric template never leaves the device; we only see a boolean success signal.
Android BiometricPrompt · iOS LocalAuthentication · template stays on deviceInvite-only access
During early access, accounts are gated by single-use invite codes. Codes are bound to the inviting waitlist row, time-limited (14 days), and consumed atomically. The full state machine is documented in the waitlist ops runbook.
Single-use · 14-day expiry · audit row per redemptionAdmin surface separation
Administrative endpoints (waitlist, invite minting, run-wave) are gated by a separate bearer token, not user JWTs. The token is rotated on demand and is never embedded in client code.
/api/v1/admin/* · separate ADMIN_TOKEN env · constant-time compare04AI safety architecture
This is the area where Kavach's design is most different from a typical SaaS. We treat AI safety as a deterministic problem, not a prompt-engineering problem.
Input gates (6)
Every user message to Sutra is screened before it reaches the LLM. Six categorical gates short-circuit the call entirely: suicidal ideation, medical emergency, drug-drug interaction request, dose-change request, pediatric scenario, prescription request. These trigger a deterministic safe response (e.g., emergency helpline card) instead of an LLM call.
backend/src/services/chat/safety.ts · 6 input matchers · 18 unit testsOutput gates (9)
Every LLM response is filtered before render: hallucinated diagnoses, dose-change instructions, "stop taking" patterns, dangerous-combination suggestions, drug-by-children dosing, and others. A violating response is swapped for a canned safe fallback and logged.
9 output matchers · 30 unit tests · safetyEvents audit row on every blockProvider abstraction
All LLM calls go through a single LLMProvider interface. This makes it trivial to swap providers, A/B test, and enforce uniform audit + safety. Today: OpenAI (zero-data-retention enterprise tier). Migrating to: NVIDIA NIM on India infrastructure.
Per-call audit log
Every LLM call writes a row to llmAuditLog with prompt hash (not the prompt itself — we don't want a duplicate copy), provider, latency, token cost, and outcome. We can answer "what did we send, where, and when?" with full fidelity for any user.
Non-LLM fallback
Memory summarization has a deterministic non-LLM fallback. The chat surface never bricks because the upstream LLM is down — degradation is graceful.
rules-summary-provider.ts · used when network unavailable05Vendor due diligence
Every external processor enumerated in the Privacy Policy goes through the same intake checklist before it gets credentials:
- Signed Data Processing Agreement (DPA) limiting use to a specific purpose.
- Documented security posture (SOC 2 Type II, ISO 27001, or equivalent — accepted in that priority).
- Confirmation of zero-data-retention or written retention limits, in writing.
- Sub-processor list reviewed; non-trivial change triggers re-review.
- Region of processing confirmed and recorded.
Vendors used today: Resend (mail), OpenAI (LLM), Cloudflare (CDN/edge), Sentry (errors), Twilio or local provider (SMS OTP). Planned: NVIDIA NIM (replaces OpenAI).
06Observability and audit
Structured request logs
Every API call emits a structured log line with request ID, route, status, latency, profile ID (when authenticated). No request bodies, no PII. Retained ≤ 30 days for debug; key transitions promoted to permanent audit rows.
winston JSON · 30-day rotation · req-id correlatorPermanent audit tables
State transitions that matter for compliance are written to permanent tables: auditLog (admin actions), llmAuditLog (every LLM call), chatToolAudit (every tool execution), WaitlistRun (every invite wave), safetyEvents (every safety block).
Service-health watchdog
A scheduled task probes every service every 5 minutes; if a watchdog itself has died, a healer restarts it. Reduces silent outages of background workers.
KavachHealWatchdogs · 5-min interval · per-service HTTP probe07Incident response
If a data incident is suspected, our response sequence is:
- Triage (≤ 1 hour) — confirm scope, kill the active vector, preserve evidence.
- Contain (≤ 4 hours) — rotate credentials, revoke active sessions, freeze affected accounts.
- Notify Data Protection Board of India (≤ 72 hours) for reportable incidents under DPDP §8(6).
- Notify affected users in clear language with what happened, what we know, what they can do.
- Post-mortem published within 14 days, with root cause and what we changed.
Until a real incident teaches us otherwise, we exercise this sequence as a quarterly tabletop. Founder-level escalation path is in place.
08Compliance posture
| Framework | Status | Notes |
|---|---|---|
| India DPDP Act 2023 | Architected for compliance | Designated Grievance Officer, lawful basis per category, India-resident primary store, cross-border egress limited to DPDP §16-compliant destinations. |
| RFC 8058 (one-click unsubscribe) | Implemented | List-Unsubscribe + List-Unsubscribe-Post headers; native unsubscribe in Gmail / Outlook. |
| OWASP Top 10 2023 | Architected against | Auth, input validation, rate-limiting, dependency review on every CI run. |
| HIPAA (US) | Not applicable today | Kavach is an India product. If we expand to US-resident users we will perform the BAA chain review before launch. |
| SOC 2 Type II | Roadmap | Not certified today. Planned attempt after 12 months of stable operations as the user base expands beyond friends-and-family. |
09What we have NOT done yet (honest)
Trust pages that don't list their limitations aren't trustworthy. As of v1.0:
- No SOC 2 attestation yet. We follow the controls; the certification is a roadmap item, not a current claim.
- No bug bounty program with paid rewards yet — but valid disclosures will receive acknowledgement and a place on a public Hall of Fame once we have one. See §10.
- No penetration test report from a third-party firm yet. Internal threat modeling has been done; external assessment is planned ahead of the 10,000-user threshold.
- No public status page yet. We surface incidents in-app and via direct email for early-access users.
- Kavach is not a regulated medical device. We do not claim CDSCO clearance or FDA clearance.
10Responsible disclosure
If you believe you have found a security or privacy issue in Kavach, please email [email protected] with:
- A clear, reproducible description of the issue.
- The affected endpoint, app version, or surface.
- Your assessment of the impact.
We commit to:
- Acknowledge receipt within 3 business days.
- Provide an initial assessment within 14 days.
- Coordinate disclosure timing with you. We ask that you do not publicly disclose until a fix has shipped or 90 days have passed (whichever is earlier).
- Credit you publicly on a Hall of Fame page once it launches, unless you prefer to remain anonymous.
- Not pursue legal action against good-faith security research that follows this policy.
Please do not: access another user's data; run automated vulnerability scanners against production infrastructure; perform DoS testing; social-engineer Axivon staff or contractors.