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:
- 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.
- The organization’s cloud-AI opt-in. An explicit per-organization setting, off by default.
- The
cloud_aiplan 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:
| Removed | Retained |
|---|---|
API keys and access-key ids, sk-/rk- style keys, provider tokens | Command text and terminal output |
| PEM private keys | SQL and query text |
| JWTs | Internal 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 password | File paths |
| Email addresses | Customer and person names |
| IPv4 addresses | Business 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
| Guard | What it does |
|---|---|
| Injection guard | Sanitizes untrusted input before it reaches the model. Attempted secret exfiltration is blocked outright; other suspicious patterns are flagged and audited. |
| Egress guard | Blocks 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 guard | Classifies 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:
| Variable | Role |
|---|---|
AI_PROVIDER | Selects the assistance provider. Set to ollama for a self-hosted LAN model. Empty disables AI. |
OLLAMA_URL | URL of your Ollama host on the LAN. Required for the self-hosted path. |
AI_MODEL | The model name used for local assistance. |
ANTHROPIC_API_KEY | The cloud (Claude) API key. Leave unset for a fully local install with no cloud path. |
CLOUD_AI_MODEL | The cloud model name used when the opted-in cloud path is taken. |
Where to go next
- Self-hosted setup — point AI at your own network with no cloud path.
- AI and egress configuration — the full configuration reference.
- Security model — how the AI guards fit the broader posture.