Where your matter data goes, mode by mode 

Swipe horizontally to compare all three processing modes.

The active mode is shown beside the run action in the application. Enabling an external endpoint requires seeing what will be sent, and to whom, first.

Every stage below runs in the Vaultr process on your machine in local mode. The only stages that can open a network socket are marked.

import ──▶ OCR ──▶ index ──▶ embeddings ──▶ retrieval ──▶ inference ──▶ ledger ──▶ export
                                                              │
                                              local mode: in-process, no socket
                                    firm endpoint: HTTPS to the host you configure  [network]
                                  external provider: HTTPS to the provider you pick  [network]

side channels:  updater [network, on your action] · model download [network, on your action]
                crash reports [off by default] · telemetry [none]

this website (not the product): opt-in pageview analytics,
loads only after visitor consent — see the privacy notice

Six stages, in Local Mode. Expand a stage to inspect where the data exists, what handles it, whether the network is involved and what is retained.

Source files

Remain where you put them. Vaultr reads them; it does not copy them elsewhere.

Index and embeddings

Written to the local application directory per matter. Deleted with the matter.

Model outputs

Stored locally with the matter until deleted.

Evidence ledger

Persists locally by design. A ledger that persists is not zero retention — it is local retention you control.

Backups

Only whatever your own machine backup captures. Vaultr operates no backup service.

External provider

If you enable one, that provider's retention applies to what you send it.

Three separate statements that are often conflated: no vendor retention (we hold nothing), no model training on your work, and offline operation. Local mode supports all three. An external provider changes the first and possibly the second.

The unglamorous specifics, stated once. These are the facts a technical reviewer checks first — including the protections Vaultr deliberately inherits from your operating system rather than reimplements.

Where data lives

In the application's per-matter directory on the device's local disk. No Vaultr-operated cloud store exists for matter data.

Encryption

Vaultr does not add its own at-rest encryption layer. The local store is covered by your device's full-disk encryption (FileVault on the tested macOS target) when the device has it enabled.

Telemetry

None in the product. No analytics SDK, no usage reporting, no telemetry endpoint. (This website separately uses opt-in, consent-gated pageview analytics — see the privacy notice; it is not part of the product.)

Crash reports

Off by default. When enabled by you, reports are limited to technical diagnostics — matter content is excluded.

Network defaults

Matter processing in Local Mode requires no outbound connection. The two exceptions are actions you start: the updater and model downloads.

Listening services

Matter processing does not require Vaultr to open a listening service. Anything listening on the device is your own infrastructure, not Vaultr's.

Access control

Vaultr relies on the device's own accounts and authentication. It adds no second account layer.

Multi-tenancy

None in Local Mode — each device holds its own matters. There is no shared server for cross-firm data mixing to occur in.

What an update touches, and the checkable practices in the public repository. Every row below is verifiable in the repo — not a policy statement.

What an update fetches

Application updates are fetched on your explicit action, for the release channel you installed. Vaultr does not self-trigger updates while you work.

Update transparency

The repository carries the release history. What changed, and why, is checkable before you take an update.

Dependency lockfiles

The product repository commits dependency lockfiles, so builds are reproducible and every dependency version is pinned and reviewable.

Automated checks

The repository runs scripted schema-drift and workflow-freshness checks and a Playwright end-to-end suite on the supported flow.

Vulnerability management

Dependency lockfiles and automated checks are maintained in the public repository and can be inspected directly.

OpenChain self-certification

The open-source licence compliance programme is self-certified against OpenChain ISO/IEC 5230 — an officially supported conformance path, not an independent audit; the statement lives in the trust center.

Model unavailable

The run does not silently fall back to another model or to a hosted provider. The task stops with an explicit state, and nothing is sent anywhere in Local Mode.

Document cannot be parsed

The document is reported as unparseable with the reason. It is excluded from the index rather than guessed at.

Citation cannot be resolved

The finding reports not found rather than inventing a source. An answer without a resolvable span is not asserted as fact.

External endpoint unreachable

A configured endpoint that cannot be reached stops the run with an error. There is no automatic retry against a different provider.

Network-restricted operation

In Local Mode, operations that would need outbound access are the ones you started on purpose — updates and model downloads. Matter processing does not require a socket.

Stated conservatively: these describe the intended behaviour of the current build. Where behaviour is still being hardened, it is labelled as such in the trust register rather than promised here.

Most security pages leave a list like this out. We publish ours — because the rest of this page is only as credible as what we admit we have not done, and because a vendor that shows its gaps is one whose strengths you can actually weigh.

• 01No independent security audit has been commissioned.
• 02No formal third-party penetration test has been performed or published.
• 03No SOC 2 report exists. This product does not operate a cloud service that one would cover.
• 04No ISO/IEC 27001 certification exists, and none is claimed.
• 05No zero-egress verification has been independently published — the offline test procedure exists so you can produce that evidence yourself.

The quickest honest route is a scoped reproduction, not a slogan. Start with the helper below, record the release and hardware, then inspect the evidence it produces before drawing a conclusion.

1. 01Install the release you were given and note its build identifier; every claim here is tied to a specific build.
2. 02Disconnect the machine from every network, or block the Vaultr process at the firewall.
3. 03Index a sample bundle and run review, drafting and interrogation end to end.
4. 04Capture traffic for the process for the duration of the run and confirm no matter data appears.
5. 05Repeat with the updater and model download disabled, then again with them enabled, so you can see the difference.

We publish this procedure because we expect it to be run — that is the difference between asking for trust and earning it. The edges of the test, stated plainly: it covers the Vaultr process on one machine and one workload, not every configuration. The evidence ledger proves the provenance and history of a conclusion; the legal soundness of that conclusion remains counsel's judgement — by design, and by the product's own philosophy.

How to report

Send the details to the security contact below, or open a private security advisory on the public repository.

What to include

A description, the build identifier, and steps to reproduce. Do not include matter data or anything confidential to a firm.

What we commit to

Good-faith reports are acknowledged and answered. We will not pursue legal action over good-faith research that respects other people's data.

Coordinated disclosure

We ask for reasonable time to fix before public publication, and we will credit reporters who wish to be named.

Response commitment

Good-faith security reports are reviewed directly by the maintainers and prioritized according to severity and affected releases.

What an evaluating firm's IT and security team receives, in one packet, before any matter is touched.

Architecture document

The data-flow and mode-boundary description on this page and in the trust center, tied to a specific build identifier.

Repeatable boundary test

The offline / traffic-capture procedure in the verification section below — run it on your own machine.

Source access

The public repository under AGPL-3.0, with its licence, attribution and history.

Data lifecycle walkthrough

A guided session with the people who build Vaultr, covering import to deletion in the mode you intend to run.