Privacy Policy

1. The Architecture Is the Policy

Vaultbeat uses a zero-knowledge, end-to-end encrypted (E2EE) architecture. Your health data is encrypted on your iPhone before it ever leaves the device, using keys that only exist on your devices. Our cloud stores and routes ciphertext only. We — the developers — hold no decryption keys, operate no decryption capability, and cannot read your health data even if asked to. This is not a promise we keep by discipline; it is a property of the system's design.

Decryption happens in exactly two kinds of places, both chosen by you: (a) your own devices and your partner's device (if you opt in to sharing), and (b) a computer you own and explicitly pair, where your personal AI agent runs (see Section 5).

2. Health Data We Process (Always Encrypted)

With your explicit permission via Apple HealthKit, and depending on which features you enable, Vaultbeat can read the following data types. Every one of them is encrypted on-device before upload:

• Sleep — sleep analysis (stages, in-bed time), sleep heart rate, respiratory rate.
• Activity — steps, active energy, exercise minutes, stand hours, walking/running distance.
• Heart — resting heart rate, heart rate variability (HRV).
• Cardio fitness & energy — VO₂ Max, basal (resting) energy burned.
• Body — weight (body mass).
• Cycle tracking — menstrual flow records, if you enable cycle tracking.
• Symptoms — the HealthKit symptom types (e.g. headache, cramps, fatigue), if you enable symptom tracking.
• Wrist temperature — from Apple Watch, if available.
• Workouts & mindfulness — workout sessions and mindfulness minutes.
• Water intake, food log, strength-training log & notes — entered by you in the app, or by your own AI agent on your behalf (see Section 5). These are not read from HealthKit.

HealthKit write access: Vaultbeat writes exactly one kind of record back into Apple Health — a body-weight entry — and it reaches Apple Health by one of two routes, both of which you control:

• A weigh-in you type in yourself. Vaultbeat asks for write permission at the moment you tap save, not during onboarding.
• A weigh-in your own AI agent logs for you over MCP — but only if you switch on Settings → Data & AI → "Allow AI to update Apple Health". That switch is off by default. While it is off, weights your agent records live in Vaultbeat only and never touch Apple Health. Turning it back off stops the writeback; entries already written stay in Apple Health, where you can delete them yourself.

Nothing else is ever written to Apple Health. Your sleep, cycle, symptoms, water, food and strength records — including the ones your agent writes — are stored inside Vaultbeat and are not pushed into Apple's database, so your Health app stays a source you control.

Motion & Fitness:if you use Vaultbeat without an Apple Watch, the app can ask for Motion & Fitness permission to infer sleep from periods of phone inactivity. This inference runs entirely on your device; raw motion data never leaves your iPhone.

In line with Apple's HealthKit rules: we never use HealthKit data for advertising or marketing, never sell it, never share it with data brokers, and never use it for any purpose other than the features you see in the app.

3. A Note on Cycle & Symptom Data

We treat menstrual and symptom data as the most sensitive category in the app. It is protected by the same E2EE pipeline as everything else, which has a concrete consequence worth stating plainly: the contents of every cycle and symptom record are ciphertext on our servers, so there is no readable cycle data on our side to disclose, leak, or hand over. Sharing cycle data with your partner is an opt-in toggle that only you, the data owner, can switch, and you can turn it off at any time. Symptoms are never shared with a partner at all — there is no toggle for it, because the app has no partner-side symptom view.

One caveat we would rather state than let you discover: the routing label described in Section 7 means our servers can see thata cycle record exists for a given day, without being able to open it. We do not use that fact for anything beyond delivering the right rows to the right device, but "encrypted contents" and "invisible existence" are different guarantees and we are only claiming the first.

4. How the Encryption Works

• Each record is sealed on your iPhone with AES-GCM-256 under a random data key.
• That data key is wrapped per recipient using Curve25519 (X25519 ECDH + HKDF-SHA256) — one sealed envelope for you, one for your partner (if sharing), one for your paired AI machine (if paired).
• Your private identity key is generated on-device and stored in your personal iCloud Keychain (end-to-end encrypted by Apple, synced across your devices). It is never sent to our servers.
• The cloud (our Supabase-hosted backend) stores ciphertext blobs and wrapped envelopes. It cannot open either.
• You don't have to take our word for it: the local MCP server that performs this decryption is open source — audit the code yourself.

5. Your AI Agent (Local MCP Access)

Vaultbeat's defining feature is that your health data can be read — and, for four categories, written — by an AI agent you run: a Claude Code instance, a personal server, your own computer, via the Model Context Protocol (MCP). Here is exactly how that works, privacy-wise:

• You pair a machine by scanning a QR code it displays. Pairing mints a credential for that specific machine and registers its public key.
• From then on, your iPhone seals an additional envelope for that machine. The machine downloads ciphertext from our cloud and decrypts it locally, on your hardware.
• No AI model runs in our cloud. No plaintext health data flows through us on its way to your agent — we only ever relay ciphertext.
• What your agent does with the decrypted data happens on your machine, under your control, outside our systems.
• A paired agent can also writefour kinds of record on your behalf — food log, strength-training log, weight, and free-text notes — encrypted on your machine the same way your iPhone encrypts, so we still only ever receive ciphertext. Of these, only weight can additionally reach Apple Health, and only with the opt-in switch described in Section 2. Your agent cannot write sleep, cycle or symptom data, and cannot write anything to your partner's account.
• You can revoke a paired machine at any time in Settings; revocation deletes its envelopes so it can no longer decrypt anything new.

6. Partner Sharing

• Sharing is opt-in and starts only when you exchange an invite code with your partner.
• Exactly four categories can be shared today — sleep, cycle, water intake and weight — each behind its own toggle on the phone of whoever owns the data, changeable any time.
• Symptoms and notes are never displayed in your partner's app, but they have their own separate opt-in — off by default, on the phone of whoever owns the data, revocable any time — which, when you turn it on, lets your partner's AI agent read them. Not their app: their agent. We state it plainly because for a product whose whole point is handing health data to an AI, “your partner's AI can read it” is the same thing as “your partner can read it”. Leave that toggle off and neither can.
• Everything else is personal-only and has no sharing toggle at all: activity, resting heart rate, HRV, workouts, mindfulness, wrist temperature, VO₂ Max, basal energy, food log and strength log. These never reach your partner or their AI, whether or not they ask.
• Ending the partnership deletes the envelopes that let your ex-partner decrypt your data. Already-delivered data on their device cannot be remotely erased — that is a physical property of E2EE, stated here so there are no surprises.

7. Non-Health Data We Keep (the Minimum to Run the Service)

To route ciphertext between your devices, we store a small amount of non-health metadata:

• Your account identifier from Sign in with Apple (we receive no password; email is whatever you chose to share via Apple).
• Device records, invite codes, partner-relationship status, and sharing settings.
• Public keys and hashed (never plaintext) machine credentials.
• Security metadata such as rate-limit counters.
• A per-record routing label: which category a record belongs to (sleep, weight, cycle, …) and the day or hour it covers. The server needs these to store, deduplicate and deliver the right rows to the right device. The record's contents remain ciphertext at all times — this label says a record of that category exists for that period, never what it contains.

8. Analytics & Diagnostics

We use PostHog (hosted in the EU) to understand app usage and diagnose bugs — events like "sync succeeded", "screen viewed", or error types. These events are engineered to carry no health values: numbers are bucketed (e.g. "sync took 1–3s"), text inputs and images are masked in session replays, and identifiers are internal. Your sleep hours, cycle dates, weight, and symptoms never appear in analytics.

That last sentence rests on two switches in the code rather than on our restraint, and both are worth naming. First, event properties never carry a health value to begin with — a count or a duration is bucketed before it is captured, so there is no raw number to leak. Second, session replay's network capture is disabled: left on, it records the URL of every request the app makes, and a request URL can carry a record identifier in its query string — which for a cycle record is derived from a date. Switching it off removes that channel entirely instead of trying to redact it afterwards. Screenshot-based replay (the part that shows us a visual bug) is unaffected, and still masks all text inputs and images.

Analytics data is not sold or shared with advertisers; there is no third-party advertising SDK in the app.

9. Data Retention & Deletion

• Encrypted health blobs are kept so your history can sync across your devices, until you delete them or your account.
• Deleting your account removes your encrypted blobs, envelopes, device records, and relationships from our systems.
• Dissolved partnerships and expired security records are garbage-collected automatically on a fixed schedule.
• Data you keep locally (on your iPhone, or on a machine you paired) is yours and outside our reach — deleting your account does not reach into your own hardware.

10. What We Never Do

• No selling of any data, health or otherwise.
• No advertising, no ad SDKs, no data brokers.
• No AI training on your data — we could not even if we wanted to; we only have ciphertext.
• No reading your health data for "service improvement", "research", or any other purpose.

11. Children

Vaultbeat is not directed at children and is not intended for use by anyone under the age of 13 (or the equivalent minimum age in your jurisdiction).

12. Changes to This Policy

If we change this policy, we will update this page and the date at the top. A change that weakened the E2EE architecture described above would be a different product — treat the architecture in Sections 1–5 as the contract.