Security at Kintaria

Kintaria holds health information about people in vulnerable moments. We take that seriously. This page documents what's in place today, what's coming, and where we're not yet — written for a family member who wants to know what they're trusting us with, not just for an auditor.

1. The controls in place today

• Row-level security (RLS) on every table. Every database row is gated by a family-membership check in Postgres itself. Even if our application code had a bug, the database would refuse to return another family's data.
• Audit log on every change. Every insert, update, and delete on workspace content writes a row to the audit_log table — who, what, when. Trigger-based, can't be bypassed by application code.
• Encryption in transit and at rest. All connections use TLS 1.2+. Database storage and document-vault storage are encrypted at rest.
• Time-limited share tokens. “Share with a provider” links use 32-byte random tokens, expire automatically (1–90 days), and can be revoked instantly.
• Magic-link authentication, no passwords. Sign-in uses one-time email links. Two-step sign-in (SMS or authenticator app) is available in Security settings and recommended for owners.
• Caregivers-only notes. Notes can be marked visible only to owners + caregivers, hidden from the parent role and observers. Server-enforced.
• Service-key isolation. The privileged Supabase service key is set only on the server, never sent to browsers.
• Security headers. HSTS preloaded, X-Frame-Options DENY, X-Content-Type-Options nosniff, strict Referrer-Policy, Permissions-Policy disallowing camera/microphone/geolocation, and a CSP that restricts where scripts, styles, fonts, frames, and form posts can go.
• Continuous RLS coverage testing. An automated script (scripts/audit-rls.ts) probes every public-schema table from an unauthenticated session and from a freshly-created non-member user. SELECT, INSERT, UPDATE, DELETE — any table returning rows or accepting writes is flagged.

2. Who can see what

Four roles inside a workspace, each with progressively narrower access. None of them can see other families' workspaces — that's a database-layer guarantee, not a policy.

• Owner — everything in the workspace, including caregivers-only notes.
• Caregiver — everything except deleting the workspace; can read & write caregivers-only notes.
• Parent (the person being cared for) — everything except caregivers-only notes; can write notes, profile, appointments, medications, documents.
• Observer — read-only; caregivers-only notes hidden.

Kintaria staff cannot read workspace contents in the normal course of operations. The privileged database role used for migrations and incident response is logged and bounded.

3. Where your data lives

All workspace data is stored in a single US-region Supabase project (database + storage). No cross-region replication. No CDN edge cache of workspace pages.

The marketing site (thrive.me) is hosted on Vercel and only serves static, non-personal content. The voice-line phone-number lookup runs on Fly.io.

4. Vendor list

Every third-party service that touches your data, and where each one stands on a BAA:

• Supabase — Database + file storage + authentication. Pro plan, BAA available — in process.
• Vercel — Hosts the app + marketing site. Enterprise plan required for BAA — not yet.
• Anthropic (Claude) — AI features (opt-in only). Enterprise tier required for BAA — in conversation.
• Resend — Transactional email. BAA available — in process.
• Twilio — SMS for two-step sign-in codes and urgent alerts. BAA available — in process.
• Plausible — Cookie-free site analytics. Aggregate visitor counts only, no PII.

What “BAA available — in process” means: the vendor offers a Business Associate Agreement for HIPAA-covered organizations and we are in the process of executing one. Until those are signed and Kintaria itself is a covered entity, please don't upload anything you would need bound by a HIPAA contract. See §7.

5. AI features

AI features (visit summaries, document classification, lab-report extraction from photos) are off by default. The workspace owner has to explicitly turn them on in Settings → AI features. When off, no content from the workspace is sent to any AI service.

When on:

• Content is sent to Anthropic (Claude) over TLS.
• Anthropic does not use API content to train its models — default API policy, not opt-in.
• Anthropic retains API content for up to 30 days for trust and safety review, then deletes it.
• We send the minimum necessary content for each feature.
• Every AI page surfaces a banner reminding you to review output before trusting it.

What AI doesn't do — ambient recording is not supported. Kintaria does not currently record audio in clinical or family settings. There is no “turn on the microphone in the doctor's office” feature in the app. If we ever add one, it will ship only after: a per-state all-party vs one-party consent rule engine (the 14 all-party states require affirmative consent from every participant); a mid-recording new-participant prompt that pauses the recording when a new voice is detected; a signed Business Associate Agreement with whichever vendor processes the audio; and one-tap revoke that propagates to vendor-side deletion within 7 days. The internal spec for that bar lives in RECORDING_CONSENT_SPEC.md. We mention all of this publicly because the question gets asked and we'd rather pre-empt the ambiguity than let people guess.

6. Sharing with providers

• 32-byte cryptographically random token. Effectively unguessable.
• You choose which sections to include.
• Auto-expires (1, 7, 30, or 90 days — you pick).
• Revocable any time; revocation is immediate.
• Access is counted — you can see when and how often the link was opened.
• Recipient can't see anything outside the chosen sections.
• The shared page doesn't index in search engines (noindex header).

Treat the URL like a one-time password. For sensitive recipients, send via a portal message or by phone rather than open SMS.

7. HIPAA posture — stated plainly

Kintaria is not yet a HIPAA covered entity. We are pre-launch and not yet under Business Associate Agreements with every vendor that touches workspace data.

The architecture is built to HIPAA-aligned controls (audit logging, encryption, access control, minimum-necessary disclosure, secure development practices). A formal BAA framework, a Notice of Privacy Practices, and the operational policies HIPAA requires are all on the pre-launch readiness path. Until those are complete, please don't upload anything you would need bound by a HIPAA contract today.

Texas Responsible AI Governance Act (TRAIGA, effective January 1, 2026). Texas now requires licensed healthcare practitioners to give patients conspicuous written disclosure of any AI use in diagnosis or treatment. Kintaria's AI features (visit summaries, lab extraction, document tagging) are off by default and require explicit per-feature opt-in by the workspace owner — designed so a Texas clinician reviewing notes a family caregiver brings in can accurately disclose AI involvement when they need to.

HHS HIPAA Security Rule update (final rule expected late 2026). The proposed rule would mandate encryption of ePHI in transit and at rest (already in place at Kintaria), MFA for critical and remote systems (we offer optional two-step sign-in today), and explicit handling requirements for AI systems touching patient data (written inventories, ongoing vulnerability monitoring). Our existing posture aligns with most of the proposed controls; we'll update this section as the final rule lands.

8. Data retention & deletion

Workspace data is retained as long as the workspace exists. When you delete a workspace:

• All content is hard-deleted from the database within 7 days.
• Database backups age out on their own schedule (typically 7 days for point-in-time recovery, then deleted).
• Document-vault files are deleted from object storage immediately.
• Audit-log rows are cascade-deleted.
• Your account (if you have no other workspaces) is hard-deleted on request — email info@thrive.me.

9. Reporting a security issue

Email security@thrive.me (alias to info@) or call (888) 704-0999. We acknowledge within one business day. No formal bug bounty yet; good-faith reporters acknowledged publicly with permission.

10. Operational practices

• Two-factor authentication required on every account that touches production infrastructure.
• Production secrets in Vercel env vars and the Supabase dashboard. Never in source control. Repository is private.
• Database migrations are version-controlled, reviewed before applying, and applied through Supabase's migration tooling.
• Dependency vulnerabilities tracked via GitHub Dependabot; security advisories reviewed within one week.

11. Coming next

• Complete BAA execution with Supabase, Anthropic, Resend, and Twilio.
• SOC 2 Type 1 readiness work. Target: within the first year of GA.
• Promote CSP from report-only to enforcing.

12. Questions

Email info@thrive.me or call (888) 704-0999. We answer every message.