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, and symptoms you log in the app yourself or that your own AI agent logs on your behalf.
• Health profile — biological sex, date of birth and height, if you allow Apple Health to share them or choose your sex in the app. Readable only by the AI agents you authorize, never by your partner.
• Wrist temperature — from Apple Watch, if available.
• Workouts & mindfulness — workout sessions and mindfulness minutes.
• State of mind — the moods and emotions you log in Apple Health (on Apple Watch, in the Health app or another app): how pleasant they felt, the feeling words and the parts of life they were about — and moods your own AI agent records for you (see Section 5).
• 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 two kinds of record into Apple Health — a body-weight entry and a state of mind (a mood) — by these routes, all 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 MCP tab → "Allow AI to update Apple Health"(app 1.2.8 and earlier: Settings → Data & AI). 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.
• A mood your own AI agent records for you— behind the same switch, off by default. While it is off, the moods your agent records stay in Vaultbeat (you see them in the app's mood calendar) and never touch Apple Health. If your agent deletes a mood it recorded, Vaultbeat removes the copy it wrote into Apple Health. Vaultbeat has no way to log a mood into Apple Health other than this one.

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. A note your agent attaches to a mood stays in Vaultbeat too.

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 never appear in your partner's app— it has no partner-side symptom view. The one way they reach your partner is a separate opt-in, “Let my partner's AI read my symptoms”, which seals the symptoms Apple Health records for your partner's AI agent; it is off by default and only you can switch it. Symptoms you report yourself in the app, or that your own agent logs for you, never go to your partner's side.

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 six kinds of record, 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 writesix kinds of record on your behalf — food log, strength-training log, weight, free-text notes, the symptoms you report, and your state of mind (a mood you describe to it) — encrypted on your machine the same way your iPhone encrypts, so we still only ever receive ciphertext. Of these, only weight and mood can additionally reach Apple Health, and only with the opt-in switch described in Section 2. Your agent cannot write sleep or cycle data or the symptom days Apple Health records, and cannot write anything to your partner's account.
• You can revoke a paired machine at any time in the MCP tab (app 1.2.8 and earlier: Settings → Data & AI); 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, moods 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.

This website is measured separately, and without cookies. Page views on vaultbeat.app are tagged with app: "vaultbeat-web" and filtered strictly apart from iOS app events (posthog-ios) so that a visit to a marketing page is never counted as app usage or linked to an account. It runs cookie-free: no cookies, no advertising identifiers, no profile, no session recording, and clicks are not captured. Nothing is stored in your browser unless you deliberately ask for it — the single exception is spelled out below. That is also why you are not being asked to dismiss a consent banner. The trade-off is ours to accept — a returning reader is counted as a new one, because there is nothing kept to recognise you by.

One deliberate exception, stated because it is the only thing this site can put on your device: adding ?ph_internal=1 to any URL stores a single value, the text 1, so that our own visits can be excluded from our numbers. It is written only if you ask for it by using that address, it holds no identifier and nothing derived from you, and you can remove it in your browser's site-data settings at any time.

The local MCP server (from version 0.9.0) reports tool usage the same way — which tool an AI agent called, whether it succeeded, and the client and package versions — never tool arguments, results or health data. Setting VAULTBEAT_TELEMETRY=0 turns it off.

Setting up a computer from the app (from app 1.3.0) uses a one-time setup code tied to your account. When the computer's bindcommand starts, it reports that code, with the computer's operating system and the package version, so the app can tell you the computer is ready. With VAULTBEAT_TELEMETRY=0 or DO_NOT_TRACK set, it sends the code alone. A code is valid for 24 hours; expired codes are deleted in routine clean-ups, and deleting your account deletes them at once.

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.