Most security pages are theater — vague reassurances about “industry-leading practices.” This one is specific. Every claim below corresponds to verifiable code or operational practice. If something here doesn't match what you observe, that's a bug — please tell us at security@mallowa.com.
Mallowa runs on a small set of infrastructure providers. The providers that handle PHI each operate under a signed Business Associate Agreement:
Anthropic (Claude) provides AI inference for pattern insights and weekly summaries. It receives only de-identified surrogate data — never PHI — so it operates outside the BAA chain, and is enrolled in Zero Data Retention so prompts and completions are not retained beyond the request lifetime.
A current list of subprocessors is documented on the HIPAA / BAA page.
In transit. All connections to Mallowa use TLS 1.2 or higher. We do not accept unencrypted requests in production. The Convex WebSocket connection that powers live updates is also TLS-encrypted end-to-end.
At rest. Care data stored in Convex is encrypted at rest using AES-256 via the underlying infrastructure. File attachments stored in Convex Storage inherit the same encryption.
Backups. Convex production backups are encrypted with the same standards as primary storage.
Mallowa uses Convex Auth for session management. Passwords are hashed with bcrypt before storage. We never see your plaintext password — and your password is never logged in analytics, audit entries, or error reports.
Password reset uses 6-digit one-time codes delivered to the registered email address with a 15-minute expiry. To prevent abuse (OTP-flood attacks against any email), reset emails are rate-limited to one per email address per minute, and the system never confirms whether an email address exists in the database (preventing email enumeration).
Session timeout. An inactivity monitor signs users out after extended idle time, with a tighter timeout on the crisis page where stale sessions could mean stale crisis information.
Google sign-in. Optional OAuth provider for users who prefer SSO over password. Authenticates against Google's identity service with no password ever stored on our side.
Multi-factor authentication is on our pre-launch hardening roadmap and will be enforceable on a per-account basis with a per-organization option to require it for clinical roles.
Audited product surfaces record access and changes to Protected Health Information in the audit log. Current read evidence combines page-level events with inventoried per-resource client-triggered events; it is not yet an authoritative record of every server read:
Reads are recorded by the server, before the record is shown. Opening care information is a write: the server checks permission, writes the audit entry, and returns the record in a single transaction. If the entry cannot be written, the transaction is rolled back and nothing is shown. A live view stays open only while its access record holds, and renewing it writes a new entry. This is not browser-side logging that can be skipped, and it is not best-effort: there is no path through the API that returns care information without its entry.
The one exception, stated plainly. Four classes of information are treated as life-safety: a crisis protocol, a safety plan, emergency contacts, and the active medication list. If the audit service itself fails after repeated retries, those four will still be shown — with a persistent on-screen notice that the access record is outstanding, an operational alarm, and a retroactive entry written as soon as the service returns. We would rather a crisis plan reach the person holding the phone than withhold it to protect our own logging. Nothing else in Mallowa behaves this way, and this exception is unavailable during a Mallowa support session.
Merkle-chain tamper-evidence. Each audit row is hashed with the prior row's hash. A daily job walks the chain in bounded pages from the first row to the last — the whole table, not a sample or a prefix — records a resumable checkpoint, and emails the head hash to a compliance inbox. A weekly run re-walks the chain in full. If a row is altered after the fact, the chain breaks at that row, the job reports the break instead of an OK, and the checkpoint is frozen rather than advanced past the damage. No day is anchored unless its chain verified. This makes the audit log tamper-evident even against someone with write access to the database.
What is deliberately not audited. Your own profile and preferences, public pages, feature configuration, notification counts (the notification list itself is recorded), and image bytes fetched after an access-checked link has already been issued. Everything else that is care information is recorded. Each day's verified chain head is also written to a dedicated AWS S3 bucket under Object Lock in compliance mode with six-year retention, which neither the application's credentials nor the AWS root account can delete or overwrite before retention expires. That external copy is a control we operate on our own subprocessor — strong enough to survive compromise of the deployment and of the writing credential — but we do not present it as attestation by an independent party, because it is not one.
Family-accessible audit log. Per HIPAA §164.528 (Right to Accounting of Disclosures), family-role members can view a derived audit log for the individuals they support. The view shows actor name, actor role, action, resource type, and timestamp — sufficient to satisfy the disclosure-accounting requirement without leaking sensitive operational metadata.
Mallowa uses AI to surface patterns in care data — sleep trends, behavior correlations, medication effects, goal trajectories. Every byte sent for AI analysis passes through a 7-layer de-identification pipeline before leaving our infrastructure. The AI provider never sees a name, a date of birth, an address, or any identifier listed in HIPAA §164.514(b) Safe Harbor.
Layer 1 — Structural scrub. Typed identifier fields (names, DOB, addresses, contact info, MRN) are stripped from the structured payload.
Layer 2 — Free-text scrub. Care-note bodies pass through pattern recognition for the 18 HIPAA identifiers, with surrogate substitution.
Layer 3 — Validation gate. A deterministic regex/denylist check fails the request closed if any residual identifier survives.
Layer 4 — Semantic Haiku validation. A second-stage AI model (Claude Haiku) does named-entity recognition on the scrubbed payload and blocks the request if it surfaces anything that looks human-identifiable.
Layer 5 — Inference call. The analysis prompt runs against Claude Sonnet with Zero Data Retention enabled at the provider level.
Layer 6 — Re-identification. Surrogates in the response are substituted back to the real names/values inside Mallowa before display.
Layer 7 — Structured-output parsing. The response is parsed into a typed insight payload; anything that doesn't match the schema is rejected.
Care data is never used to train AI models. Anthropic's ZDR enrollment combined with the de-identification pipeline ensures that model training on our customer data is operationally impossible regardless of policy.
AI features are gated to the Growth tier. Roots and Roots+ users have no AI inference running on their data.
A small number of architectural rules govern how PHI moves through Mallowa:
Convex maintains automated daily production backups, including uploaded files, with a rolling 7-day retention window. The backup store inherits the same encryption-at-rest standards as primary storage.
Our recovery point objective (RPO) is 24 hours, matching the daily backup cadence. Recovery procedures are documented and scheduled for annual testing; we will publish a recovery time objective once it has been measured against a real restore rather than estimated.
Account deletion requests propagate to backups within the next scheduled rollover (max 7 days), at which point the deleted data is no longer recoverable from any system.
We maintain an incident response plan covering security events, suspected unauthorized access, data integrity issues, and service outages. The plan is exercised through tabletop reviews quarterly.
HIPAA breach notification. If a security incident results in a confirmed breach of unsecured PHI as defined in HIPAA §164.402, we notify affected individuals, covered entities (where applicable), and HHS within the time frames required by §164.404 and §164.408. Notification uses the email on file for the account.
Customer communication. For security-relevant events that don't rise to a HIPAA breach (e.g., a service outage, a non-PHI data exposure), we send a status communication via email and post a public incident note describing impact, remediation, and prevention.
We welcome reports from security researchers. If you believe you've found a vulnerability in Mallowa, please email security@mallowa.com with details. We commit to:
Safe harbor principles. Good-faith research means: don't access more data than necessary to demonstrate the vulnerability; don't exfiltrate PHI; don't modify or destroy data; don't degrade service for other users; report findings to us before any public disclosure; give us a reasonable window to fix.
A formal bug bounty program with monetary rewards is planned post-launch. Until then, we extend hall-of-fame recognition to disclosed researchers.
Mallowa is built to align with the HIPAA Security Rule (45 CFR §164.302–318) and Privacy Rule (45 CFR §164.500–534). The full HIPAA framework, including our Business Associate Agreement, is documented on the HIPAA / BAA page.
Pre-launch we are completing an external penetration test and the findings will be remediated before public launch. Audit reports are available under NDA to qualified enterprise prospects.
SOC 2 Type II is on our post-launch roadmap and we expect to complete the observation period within 12 months of public launch.
Security is a shared responsibility. Steps you can take:
Security issues, vulnerability reports, or compliance questions: security@mallowa.com
For general support or non-security questions, use hello@mallowa.com.