How Vaulith is built to be safe to run

A public, honest mapping from architecture to controls. The core property is a design choice, not a policy. All sensitive work happens on the endpoint. File content never leaves the machine, so there is no server-side copy to breach. This page states what is true today and what is still roadmap.

Public version · Last updated August 2026 · support@vaulith.com

1. The core control: no egress of file content

File enumeration, hashing, and duplicate detection all run locally, on the user’s own hardware. So does the optional AI analysis (LLaVA for images, Mistral for documents), which runs through Ollama and only on machines where the user has already installed Ollama and a model themselves. There is no cloud AI call. File names, paths, contents, thumbnails, and photos never appear in any network request, in 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 two things. One is the launch-time version check. The other is an anonymous, path-scrubbed crash report, sent only if the app itself errors. 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.
• AI model download (only if the user sets Ollama up themselves). Ollama fetches model weights inbound from its registry (ollama.com) during the one-time guided setup. Nothing about your files or account is sent; after the download, all AI inference is local and needs no network at all.

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. The one exception, since v1.1.0, is the plaintext original of a file the user locks in the Vault: it is removed only after its encrypted copy has been decrypted back and verified against it, and Restore brings it back. System-file exclusion is always on, including on the free tier.
• Append-only deletion manifest. Every custody change (quarantine, send-to-Trash, restore, cache reclaim) is written to an on-device, append-only log before anything moves. So “what did it remove?” always has an auditable answer, even after the Trash is emptied. Version-controlled project trees are refused for deletion outright.

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

5. Sensitive-data detection — on the device, for protection

Vaulith detects sensitive documents so it can protect them from bulk deletion. Detection runs entirely on the endpoint, like everything else. Three mechanisms:

• Filename shield. Recognizes files named like tax returns, bank statements, passports, IDs, medical records, and legal filings.
• Content check (model-free). A local classifier reads a bounded portion of each document. It looks for SSN-shaped numbers, labelled account and routing numbers, and strong medical, legal, financial, and identity vocabulary. A file is marked sensitive only on two independent signals — never a single weak match.
• Optional local AI, where the user already runs it. If the user has installed Ollama and a model themselves, that model re-checks documents in the background. It runs on the user’s hardware and calls no cloud. Vaulith does not ship the model, and the two mechanisms above do not depend on it.

In professional terms: the shield covers personally identifiable information (PII), protected health information (PHI), financial account data, and legal or client-confidential documents. A flagged file is excluded from bulk deletion and requires individual review. Detection is best-effort; the exclusion after detection is structural. Nothing about a match ever leaves the machine. The plain-words-to-professional-terms mapping, and the disproving test, are on the claims ledger.

6. Build integrity — signing & notarization chain

• macOS. Universal builds (Intel + Apple Silicon) are Developer ID–signed and notarized by Apple, with the ticket stapled to the DMG and the hardened runtime enabled. The release pipeline validates the staple and runs a Gatekeeper assessment. A build that fails either check is not published.
• Windows. Builds are Authenticode-signed as CN=Vaulith LLC 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. That is what makes signed MDM distribution trustworthy.

7. 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.

8. Subprocessors

A small number of vetted providers run the account, licensing, billing, and distribution parts of the service. The cleaning engine runs on the endpoint and involves no subprocessor, and so does any local AI the user has set up themselves.

Not a subprocessor: on-device AI (Ollama), where the user has installed it themselves. It runs locally and receives no data from us.

9. 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.

10. 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 multiple industry-leading security and risk certifications, including CRISC. The architecture is the point. It was designed to be the tool a security reviewer would approve.