Privacy — what leaves your machine

Each claim first, then the part that qualifies it. Nothing here is a promise the code does not keep.

A fresh clone holds zero credentials, zero lore, zero personal state. Source and templates only — see the next section for the file-by-file split.

Your documents never leave your machine as files. What travels per question is the text the prompt carries: your question, the clarifications that matched it, and your lore. → The caveat that matters: with the default folder source there is no per-question retrieval, so the whole parsed corpus goes into every prompt, truncated at a document boundary past 500,000 characters (KB_CHAR_LIMIT). The Obsidian source narrows, and only once a vault outgrows the budget. Assume your provider sees your campaign.

The dashboard binds to 127.0.0.1. Other devices on your LAN cannot reach it.

→ If you set HOST=0.0.0.0:

• The API does not authenticate requests.
• host-origin-guard.ts enforces its loopback Host check only while the bind is loopback — a non-loopback bind switches that check off rather than widening it.
• The cross-origin Origin check on writes still runs.
• The routes that act on the host — the Claude Code spawn, choosing a lore folder, updating, the diagnostics bundle, the log, approving an MCP pairing, and writing a persona's prompt — stay gated on the peer address by loopbackOnly().
• Two writes are not gated, on purpose: /api/keys and /api/discord. On a widened bind, anyone who can reach the dashboard can set an API key or the bot token. That is the trade HOST=0.0.0.0 asks you to accept, and it is why the recommendation is to widen it only on a network you control.

API keys are encrypted at rest — AES-256-GCM in your per-user config directory, key derived by scrypt from a machine identity. Masked in every response.

→ Honest framing, and keys/crypto.ts says the same: this is obfuscation with authenticated encryption, not high-grade cryptography. The salt sits beside the ciphertext, and anything running as you can derive the key. What it defeats is a backup client or support bundle scooping up a readable key file — a likelier path to a leaked key than a local attacker.

Embeddings run locally, via MiniLM-L6-v2. Your clarification text is never sent anywhere to be embedded — though a clarification that matches a question is then quoted into that question's prompt, and reaches your provider the way your lore does.

No telemetry, no analytics, no phone-home. Every host this app can reach is listed in the next section, so you can check the list against the code.

OpenRouter requests pin a zero-data-retention floor — zdr: true and data_collection: deny on every call, including model-probe.ts, or a model would test reachable and then fail every real question. It is why most :free variants are unavailable: they run on hosts that keep prompts. → The one way past it is deliberately awkward: an opt-in recorded per model id, visible everywhere that model is shown, revoked automatically when you pick a different model.

You can audit every byte. ~29,000 lines of TypeScript, plus ~9,700 of tests sitting next to the code they cover.

---

grep -rn 'fetch(' src/ finds every HTTP call in the app. The only one it misses is the updater, which goes out through git.

Two of those deserve a note.

• The grades feed exists so a model graded after your version shipped still shows a grade. If it fails you get the cached copy, then the grades your build shipped with — nothing breaks, nothing retries in the background.
• The fonts are a plain @import on the first line of src/index.css: the one third-party request the dashboard makes on its own, and it happens before you configure any provider. If that bothers you — reasonably — delete that line and the dashboard falls back to system fonts.

---

A fresh clone contains (~357 tracked files)

Source code, setup scripts, the launcher, and configuration templates only. Nothing in this list contains personal data or credentials:

• Source code (src/, server.ts)
• Installer, setup + launcher scripts (install-tusks-vault.bat / .sh, setup.bat, setup.sh, run.bat, run.sh) and the uninstaller (uninstall.bat, uninstall.ps1, uninstall.sh)
• The updater script (scripts/update.mjs)
• .env.example — env-var template, no values
• Lore/README.md — placeholder README explaining the lore folder (the actual documents go in a sibling Tusks-Lore/ directory; see How it's built for details)
• Standard files (license, README, docs, package files, tsconfig, etc.)

Verify the count yourself with git ls-files | wc -l; it moves with every release, so treat the figure as an order of magnitude rather than a checksum.

Files created at runtime, on your machine, gitignored

These files appear during use and never get pushed. They land in three places — the repo, your resolved lore folder, and your per-user config directory (env-paths' tusks-vault config location, overridable with TUSKS_VAULT_CONFIG_DIR). Which one a file lands in is a deliberate choice: campaign state follows the campaign, per-install state stays with the install.

In the repo:

In your lore folder — the sibling Tusks-Lore/ if you have one, otherwise <repo>/Lore/ — so campaign state survives a clean reinstall:

In your per-user config directory — per-install, machine-bound or rebuildable, and deliberately not carried around with a campaign folder:

Need to verify your setup?

Hit GET /api/diagnostics from the dashboard (or via curl) and you'll get a JSON report on the eight paths that hold your state — keys.enc, .env.local, settings.json, the two clarification files, lore_gaps.json, the resolved lore folder (with which resolution rule won), and the model cache — each with its absolute path, whether it exists, its size, and its last modified time. Useful for debugging "where did my settings go?" type questions.

---

The formal version lives in SECURITY.md — a STRIDE table of what Vault does for you and what you should do, per-feature addenda for Ollama, Claude Code, Obsidian, Foundry and personas, and the list of what is still open. It is one page rather than two because a second copy of a security posture is a copy that goes stale, and the stale one is the one somebody trusts.

The short version, for a GM deciding whether to install:

• Loopback is a machine boundary, not a user boundary. A second account on the same box is inside it.
• HOST=0.0.0.0 widens trust, not just reach. There is no auth in front of state-changing endpoints. Keep the default bind unless you trust every device on your network.
• Players can pull more than they have discovered. Vault answers from the whole corpus and has no notion of what your table has found. The allowPlayers ceiling is off by default, so a fresh install answers only the GM. See Foundry VTT.
• Document parsers are not sandboxed. Don't drop PDFs from strangers into your lore folder.

---

Nothing in this table is sent to a Tusk's-Vault-controlled server. We don't run one.

---

• 🐞 Known issues + active hardening backlog
• 🧠 How retrieval works under the hood
• 💸 What it costs — the pricing table that used to live on this page
• 🔌 Choosing a provider — what each one sees
• 📦 Dependencies and why each is here