How Vaulith is built to be safe to run

A public, honest mapping from architecture to controls. The defining property isn’t a policy — it’s a design choice: the sensitive work happens entirely on the endpoint, so your file content never leaves the machine and there is no server-side copy of it to breach. This page states what’s true today, and what’s honestly still on the roadmap.

Public version · Last updated July 2026 · security@vaulith.com

1. The core control: no egress of file content

File enumeration, hashing, exact- and near-duplicate detection, and the AI analysis (LLaVA for images, Mistral for documents) all run locally, on the user’s own hardware through Ollama. There is no cloud AI call. File names, paths, contents, thumbnails, and photos are never included in any network request under any configuration.

2. Architecture at a glance

3. Minimal data — the complete egress list

No account is required to use the app. Signed out, nothing leaves the device except the launch-time version check — and, only if the app hits an internal error, an anonymous path-scrubbed crash report. The complete list of what can leave, and why:

• License validation. For paid plans, confirms the license is valid. Carries a license key / account identifier; nothing about files.
• Scan summary sync (only while signed in). After a scan, an aggregate summary appears in the dashboard: files-scanned count, duplicates-found count, reclaimable gigabytes, timestamps, and a device identifier. No file names, paths, contents, thumbnails, or photos.
• Update check. On launch, asks GitHub Releases whether a newer version exists. No account or file information.
• Newsletter. Only if the user opts in; stores the email address provided.
• Crash reports. Anonymous, with the error type and a path-scrubbed message. Never files, names, or account.

This is the same exhaustive list published for consumers under how your privacy works — and you can watch it yourself with Little Snitch, Wireshark, or Activity Monitor.

4. Recoverable-deletion safety model

A scan can never irreversibly destroy data:

• Review-and-confirm. The app shows what it proposes to remove and requires explicit confirmation before removing anything.
• Quarantine-first / OS Trash. Removed files move to the system Trash (macOS) / Recycle Bin (Windows) or a restorable quarantine — not erased in place.
• Recoverable until the bin is emptied. Deletion is permanent only once the user empties the Trash / Recycle Bin. System-file exclusion is always on, including on the free tier.

For a fleet, the worst-case action is a recoverable move, not an unrecoverable delete.

5. Build integrity — signing & notarization chain

• macOS. Universal builds (Intel + Apple Silicon) are Developer ID Application–signed, notarized by Apple, and the ticket is stapled to the DMG; the hardened runtime is enabled. The release pipeline validates the notarization staple and runs a Gatekeeper assessment — a build that fails either check is not published.
• Windows. Builds are Authenticode-signed via Microsoft Azure Trusted Signing.
• Consequence. A copy of Vaulith your OS flags as unsigned or un-notarized did not come from us. Gatekeeper and SmartScreen verify the signature at launch — which is what makes signed MDM distribution trustworthy.

6. Identity, access, and data protection

• Authentication. OAuth with PKCE; sessions stored in the OS keychain, not plaintext on disk.
• Backend isolation. Account, licensing, and scan-summary data live in Supabase Postgres with row-level security per user, and per-organization isolation via RLS predicates. Encrypted in transit (TLS 1.2+) and at rest.
• Secrets. API keys the app holds are stored in the OS keychain.
• Payments. Handled entirely by Stripe; card numbers never touch Vaulith systems.

7. Subprocessors

A small number of vetted providers run the account, licensing, billing, and distribution parts of the service. The cleaning engine and AI run on the endpoint and involve no subprocessor.

Not a subprocessor: on-device AI (Ollama). It runs locally and receives no data from us.

8. Incident response

• Reporting. support@vaulith.com with subject SECURITY REPORT, or the machine-readable /.well-known/security.txt (RFC 9116).
• Timelines. Acknowledge within 48 hours; triage target 5 business days.
• Safe harbor. Good-faith research is protected under our security & disclosure policy.
• Breach notification. For the limited account/licensing data we hold, we commit to notify affected controllers without undue delay on becoming aware of a personal-data breach.

9. What is roadmap stated honestly

Vaulith does not overstate its assurance posture. The following are not in place today:

• Vaulith’s own SOC 2 report. We do not hold one. We rely on our subprocessors’ certifications (Supabase SOC 2, Stripe PCI DSS Level 1) for the parts they run. Our own SOC 2 is a roadmap item.
• Independent third-party penetration test. Not yet conducted; on the roadmap.
• Self-serve volume provisioning, admin console, and MDM headless activation. The organization / pooled-seat backbone schema is built; the operator-facing flows are in development and offered via pilot.
• Stripe Invoicing for POs / annual seat billing. Roadmap; pilots are handled directly today.

We do not claim SOC 2, ISO 27001, HIPAA, FedRAMP, or any certification Vaulith does not hold.

Built by a founder with a security and governance/risk/compliance background — holding the CRISC and GSLC certifications. The architecture is the point: it was designed to be the tool a security reviewer would actually approve.