How Heir handles your data.

• Your check-ins, profile, and notes are AES-256 encrypted on your device with a key that never leaves your Keychain.
• Apple Health data is read ephemerally, on-device only— never written to disk, never uploaded to our servers, never sold, never shared.
• Everything in transit is encrypted with TLS 1.3.
• Our database is encrypted at rest with row-level access controls scoped to your authenticated identity. Other users cannot read your rows. Heir staff cannot read your rows without an audited service-role action.
• AI calls to Anthropic run with zero data retention enabled — your prompts are not stored on the model side.
• We don’t sell your data. We don’t share it with advertisers. We don’t share cycle or reproductive information with anyone, ever.

Heir uses Apple’s CryptoKit framework to encrypt every sensitive file the app writes locally. The encryption is AES-256-GCM— an authenticated encryption scheme that protects both the content and its integrity. A unique 256-bit symmetric key is generated on first launch and stored in the iOS Keychain with kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:

• After first unlock— the key is unusable until you have unlocked your device once since reboot.
• This device only— the key never roams to iCloud or another device. Even a restored backup on a different device cannot decrypt your Heir data.

Every encrypted file is also written with FileProtectionType.complete: while your device is locked, the operating system will not allow the file to be read even by Heir’s own process.

What this means in practice: if you lose your phone unlocked, the attacker has the data Heir has. If you lose your phone locked, or your phone is taken in a forensic-extraction scenario, the data remains encrypted at rest behind a key the attacker doesn’t have.

When you connect Apple Health, Heir reads three signals: last night’s sleep duration, recent heart-rate variability (SDNN), and recent resting heart rate. We never persist those values to disk and we never upload them to our servers. Each value is held in memory only for the duration of the current daily read, then released.

This is enforced two ways:

• In code: the HealthKitService exposes the values as@Observable in-memory properties only. There is no write path to disk or network for any HealthKit value.
• In the app entitlements: Heir declares HealthKit read-only access. We do not write to Apple Health.

We comply with all of Apple’s HealthKit privacy requirements. HealthKit data is never used for advertising, never sold, never rented, never shared with brokers, never disclosed to a third party.

Every connection between the iOS app, our backend, and our subprocessors is encrypted with TLS 1.3 (or 1.2 where required for compatibility). This includes:

• iOS app ↔ heir.health backend
• iOS app ↔ Apple StoreKit
• Backend ↔ Supabase Postgres
• Backend ↔ Vercel AI Gateway ↔ Anthropic
• Backend ↔ Stripe
• Backend ↔ Resend (transactional email)

The bundle does not ship certificate pinning in v1 — pinning is brittle without out-of-band rotation infrastructure, and the incremental security at our scale doesn’t justify the rotation risk. We’ll add it before any enterprise / employer deal.

Heir’s primary database is Supabase Postgres, hosted in the United States. Volume-level encryption (AES-256) is enabled at the storage layer — if a physical drive were stolen, the data would be unreadable.

More importantly, every user-data table is covered by Postgres Row-Level Security(RLS). The RLS policies are scoped to your authenticated Clerk identity, so a row written under your account can only be read by your account. Even our backend code, when running with the user-scoped key, cannot read another user’s rows. The rare service-role operations (the Stripe webhook, the safety-audit job) are isolated to a small number of paths and are logged.

The free-text notes field on your check-ins receives additional field-level encryption in Phase 2, using Supabase Vault as the key management layer. That work is scheduled for the first sixty days post-launch.

Today’s Read and Library Ask are generated by Claude models from Anthropic, routed through the Vercel AI Gateway. Two things to know:

• We use retrieval-augmented generation: the model is shown only short excerpts from our curated corpus, and is constrained at the schema level to cite only sources retrieved for that specific request. It cannot invent sources, and it cannot pull in arbitrary internet content.
• Zero data retention is enabled on our Anthropic account.Your prompt and the model’s response are not retained on Anthropic’s side beyond the request itself. There is no future model trained on your check-in history.

Free-text content you enter (check-in notes, profile notes) is run through our hard-coded safety regex layer before any AI sees it. If self-harm or medical emergency indicators are detected, the AI is bypassed entirely and you receive an escalation screen with clinician and crisis-line contacts.

• We never sell your data. We never rent it. We never share it with data brokers.
• We never use your data for cross-context behavioral advertising.
• We never share cycle, reproductive, or pregnancy-related data with any third party, for any reason. See Section 9 of the privacy policy for the legal commitment.
• We never train external AI models on your individual content.
• We never read your HealthKit data on our servers. It never leaves your device.

You can delete your account from inside the app at any time: Profile → Account → Delete account. Within thirty days we delete your profile, your check-ins, your reads, your scans, your stack, and every dependent row, in cascade. Encrypted files on your device are erased when you uninstall the app or sign out.

We retain billing records with Stripe for the period required by tax law (typically seven years in the US), with your customer record marked heir_deleted=true. We retain anonymized PostHog analytics without your user identifier. We retain security audit logs for up to ninety days, then purge.

This page describes the architecture at launch. The following items are scheduled for the first six months:

• Field-level encryptionfor check-in notes using Supabase Vault — ~30 days post-launch.
• Biometric-gated notes— Face ID required to decrypt your notes even on your own device.
• Audit logging on every sensitive table read and write.
• End-to-end encryption for the notes field, where the key is held only by you and the server never sees the plaintext.
• External penetration test by an independent firm.
• SOC 2 Type I scope, then Type II.
• HIPAA readiness: BAAs with every relevant subprocessor (Supabase, Vercel, Clerk, Anthropic), in service of future employer and insurer deals.

If you believe you’ve found a vulnerability in Heir, email security@heir.health. We confirm within forty-eight hours, investigate, and credit responsible disclosures in a public security advisory once the issue is fixed. We do not yet run a paid bounty — that arrives in 2026 once we’ve hardened the highest-value surfaces.