Skip to content
VaultTerm
Browse docs

privacy-first-ai

AI privacy model

AI assistance defaults to a self-hosted model on your LAN. What keeps terminal output on your network is that default plus a per-organization opt-in, not the redaction step — and this page states plainly what the redaction step removes and what it sends.

Updated Aug 15, 2026

VaultTerm’s AI is privacy-first by design: prompts and terminal output do not leave your network by default, and the route to a cloud model is narrow and opt-in. This page explains what actually keeps output local, what the redaction step does and does not do, and the guards in front of the model.

LAN by default

By default, assistance runs against a self-hosted model on your own LAN using Ollama. Prompts — including any terminal output fed to the model — stay on the network, because the model answering them is on the network. With no cloud key configured, there is no cloud path at all; see Self-hosted setup.

What keeps output on your network

The control that keeps terminal output on the LAN is the self-hosted default plus the per-organization opt-in. Reaching a cloud model (Claude) requires all three of the following, and every one of them is off in a fresh install:

  1. A configured cloud key. With no instance key and no organization-supplied key, the cloud provider is inert and no cloud request can be constructed.
  2. The organization’s cloud-AI opt-in. An explicit per-organization setting, off by default.
  3. The cloud_ai plan entitlement. A plan without it never reaches the cloud, even if the opt-in flag is set.

All three are required together. Miss any one and the request stays on the LAN provider, or is answered by nothing at all if no LAN provider is configured.

The redaction step described below is not one of these conditions. It runs after the routing decision has already been made, and it transforms the payload rather than refusing it.

What the redaction step removes, and what it sends

Once a request is on its way to a cloud model, it passes a redaction step, and every cloud egress is written to the audit trail with a bounded preview of exactly what was sent.

It is a secret-and-PII filter, not a transcript filter. It removes values that have a recognisable shape:

RemovedRetained
API keys and access-key ids, sk-/rk- style keys, provider tokensCommand text and terminal output
PEM private keysSQL and query text
JWTsInternal hostnames and topology
Passwords embedded in URLs, in secret-named KEY=value assignments, and on the command-line flags of tools whose flag carries a passwordFile paths
Email addressesCustomer and person names
IPv4 addressesBusiness content, including commercial terms
Payment card numbers
High-entropy blobs that look like unlabelled tokens

Measured on a 40,000-character operations transcript, about 90 percent of the text passes through to the cloud model — the published figure is 89.84 percent. That is not a tuning gap that a future release closes. A token can be recognised by its shape; a sentence like select email, plan, mrr from customers cannot, because its sensitivity is entirely contextual. Pattern matching on free-form operational text has a ceiling, and this is roughly where it sits.

The figure is not marketing copy on a page. Your server publishes it on GET /ai/status, alongside the lists of what the step removes and retains, so a client can show it at the moment someone decides whether to opt an organization in. It is checked against the real measurement by a test that fails if the two ever diverge.

Read this as: if your requirement is that operational content does not reach a third-party model, the setting that meets it is leaving the organization on the self-hosted default. The redaction step is defence in depth behind that decision — it makes an accidental credential in the output much less likely to leave, and it does not make cloud egress equivalent to keeping the work local.

Guards in front of the model

GuardWhat it does
Injection guardSanitizes untrusted input before it reaches the model. Attempted secret exfiltration is blocked outright; other suspicious patterns are flagged and audited.
Egress guardBlocks server-side fetches to private or metadata targets (for example RFC 1918 ranges, loopback and cloud metadata endpoints), so the AI path cannot be turned into a server-side request forgery vector.
AI guardClassifies a proposed command and blocks dangerous ones pending a step-up, so a model suggestion never executes something destructive without an explicit confirmation.

Configuration

The privacy behaviour is driven by these settings — full details in AI and egress configuration:

VariableRole
AI_PROVIDERSelects the assistance provider. Set to ollama for a self-hosted LAN model. Empty disables AI.
OLLAMA_URLURL of your Ollama host on the LAN. Required for the self-hosted path.
AI_MODELThe model name used for local assistance.
ANTHROPIC_API_KEYThe cloud (Claude) API key. Leave unset for a fully local install with no cloud path.
CLOUD_AI_MODELThe cloud model name used when the opted-in cloud path is taken.

Where to go next