DoctorVault
Security & trust

What we can and cannot see

DoctorVault is designed so your health data stays in storage you own, encrypted under keys only you hold. This page explains that boundary — and how you can verify it yourself before you trust us with your browser.

Last updated July 5, 2026. Plain language for clarity — not a substitute for professional legal advice.

Part 1

What our servers 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

There is no API endpoint on this app that accepts vault payloads. The server hosts static pages and GET /api/health only.

Part 2

What you own

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.

Part 3

What still leaves your device (by design)

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.

Part 4

Verify yourself — network tab

The strongest check: confirm health data never hits this website's origin.

  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 your site's hostname (not external APIs).

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

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

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

Part 5

What you still trust us for

  • The JavaScript we serve — a malicious deploy could betray the vault while unlocked. Mitigations: open source, signed release manifests, and the checks on this page.
  • Your browser and device — malware or extensions can read an unlocked vault.
  • Not HIPAA or clinical certification — personal-use tool; see Terms.

Part 6

Build provenance

This deployment was built from the following source revision. Match it to a signed release before you trust a public instance.

Version
v0.3.23
Commit
4fc1d2cbbcfada7dbf16a6e4e3d6c55938cec3a3
Site
doctorvault.ai
Source
github.com/magemaclean/agentic-hospital

Compare with build-manifest.json on the matching GitHub Release. See reproducible builds for Cosign verification steps.

Part 7

Audits and reporting

Third-party review: internal self-review is complete; an external penetration test is not yet published. Scope and status: third-party review doc.

Report a vulnerability: please use GitHub Security Advisories (see SECURITY.md). Do not post exploit details in public issues.