What we can and cannot see

When you use DoctorVault, our infrastructure does not receive:

• Health records, chat messages, files, or reminders (plaintext or ciphertext)
• Vault passphrases, recovery codes, or encryption keys
• S3 access keys or Google OAuth tokens
• LLM or embedding API keys

The vault app at doctorvault.ai hosts static pages and GET /api/health only — no endpoint accepts vault payloads.

The accounts service at accounts.doctorvault.ai handles Pro sign-in and subscription status only. It never receives health data or vault credentials.

Your vault lives in your S3-compatible bucket or Google Drive app-data folder. We cannot list, read, or delete it without your storage credentials — which stay in your browser.

Deletion is real: “delete my vault” wipes your storage. We hold no backup copy.

When you use panel chat, relevant record excerpts go browser-direct to the LLM provider you configure (Anthropic / OpenAI) under yourAPI key. We are not in that path. Review your provider's data and retention policies.

If you use DoctorVault Pro, your browser also calls accounts.doctorvault.ai to check entitlements and open checkout — JSON only, no health payloads.

The strongest check: confirm health data never hits our origins with POST/PUT bodies carrying vault content.

1. Open /vault in Chrome or Firefox.
2. Open DevTools → Network. Enable “Preserve log”.
3. Complete onboarding (demo vault is fine) and unlock.
4. Create a record, save, and optionally run a panel chat.
5. Filter requests by hostname and inspect request payloads.

Expected on doctorvault.ai: page loads, /_next/* static assets, GET /api/health — no POST or PUT carrying health JSON or API keys.

Expected on accounts.doctorvault.ai (if signed in for Pro): GET /v1/me/entitlements, checkout or portal redirects — small JSON only, no health records or vault keys.

Expected off our origins: your S3 or Google API host, api.anthropic.com, api.openai.com (when using chat/embeddings).

Our automated E2E suite enforces the same invariant on the vault origin in CI. Operators can also run pnpm e2e:vault against a production build.

• The JavaScript we serve — a malicious deploy could betray the vault while unlocked. Mitigations: documented data boundaries, no analytics on the vault surface, version transparency on this page, and the network checks above.
• Your browser and device — malware or extensions can read an unlocked vault.
• Pro billing integrity — entitlements depend on the accounts service and Lemon Squeezy webhooks; payment data stays with Lemon Squeezy.
• Not HIPAA or clinical certification — personal-use tool; see Terms.

This deployment reports the build version embedded at image build time. Match it here before you trust a public instance.

Third-party review: internal self-review is complete; an external penetration test is not yet published.

Report a vulnerability: email [email protected] with a description, impact, and steps to reproduce. Please do not post exploit details in public channels. We aim to acknowledge reports within five business days.