AI privacy model

Kutrion’s AI is privacy-first by design: the model that answers by default is a self-hosted one, not a cloud one, and the route to a cloud model is narrow and opt-in. Whether that default model also sits on your network is a separate question, and the answer depends on how Kutrion is deployed and configured. This page keeps the two apart, because they are the two different things a security review usually needs to know: what reaches a third party, and what leaves your premises.

Self-hosted by default — and where that model runs

By default, assistance runs against a self-hosted model using Ollama, not a cloud model. With no cloud key configured there is no cloud path at all. Which machine answers the prompt depends on the deployment:

Deployment	What answers by default	What it takes to put inference on your own network
Self-hosted Kutrion	Nothing — AI is off until an operator sets AI_PROVIDER=ollama and points OLLAMA_URL at an Ollama host. Once set, that host is yours.	Already the case: the endpoint you configure is the one you run. See Self-hosted setup.
Hosted Kutrion	The instance’s own Ollama endpoint — infrastructure the operator of the deployment runs, not your network.	An organization admin sets the org’s AI provider to ollama and supplies an endpoint URL you operate. Saving that setting needs no entitlement, but a hosted server can only reach a publicly addressable endpoint, and those run on the cloud-gated path — see If you supply your own endpoint.

So the accurate statement of the default is self-hosted rather than cloud, not on your premises. On the hosted service, “self-hosted” means the deployment runs the model itself rather than calling a third party’s model API. If your requirement is that prompts and terminal output never leave your own network, meet it by self-hosting Kutrion or by pointing the organization at your own endpoint — not by relying on the default.

If you supply your own endpoint

Kutrion treats an organization-supplied endpoint as on-network only when it can prove that from the URL: the host must be localhost or a private IP literal (for example 10.x, 172.16-31.x, 192.168.x, ::1, fc00::/7, fe80::/10). An endpoint addressed by DNS name — ollama.internal.example.com — cannot be proved private, so it is classified conservatively as cloud egress: it runs behind the same per-organization opt-in and cloud_ai entitlement as a third-party model, and every request to it is redacted and written to the audit trail as a cloud send, even though the machine answering is yours.

On the hosted service that has a consequence worth knowing before you plan around it. A hosted server cannot reach an address inside your network, and the egress guard rejects a private-literal or localhost endpoint when you try to save it, so a hosted organization’s own endpoint is in practice always a public hostname — and therefore always on the cloud-gated path. Pointing hosted Kutrion at a model you run is possible; it is not a way around the cloud opt-in and the cloud_ai entitlement.

On a self-hosted install neither constraint applies. The operator points OLLAMA_URL at a host on the same network, and inference never leaves that network. The operator’s OLLAMA_URL does not pass through the egress guard, so no extra setting is needed for it; an organization-level endpoint on a private address additionally needs EGRESS_ALLOW_PRIVATE=1 (see AI and egress configuration).

What keeps output away from a cloud model

The control that keeps terminal output out of a third-party model 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 self-hosted provider, or is answered by nothing at all if no self-hosted 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 (AI_CLOUD_EGRESS), followed by a second entry recording whether the call completed or failed (AI_CLOUD_EGRESS_RESULT).

By default the audit entry records a fingerprint, not the text. It stores a SHA-256 hash and the length of the redacted request, so you can prove what size of request left and match it against a copy you hold, without the audit log becoming a second store of your terminal output. An organization admin can opt in to keeping the text as well: in the web app’s organization settings, under Policies, turn on Keep the text of each cloud AI request in the audit log (the ai_egress_audit_text setting on PATCH /org). The entry then also keeps the first 2,000 characters of the redacted request. Changing the setting is itself audited (ORG_UPDATED), and it applies to requests sent after the change: the audit log is append-only, so text already recorded stays recorded.

It is a secret-and-PII filter, not a transcript filter. It removes values that have a recognizable 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 recognized 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. If your requirement is that it does not leave your own network, the default alone does not meet it on the hosted service — self-host Kutrion, or point the organization at an endpoint you run, as described above. The redaction step is defense in depth behind either 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 behavior is driven by these settings — full details in AI and egress configuration:

Variable	Role
AI_PROVIDER	Selects the assistance provider. Empty — the shipped default — disables AI entirely. Set it to ollama for a self-hosted model. There is no value that selects a cloud model here.
OLLAMA_URL	URL of the Ollama host. Required when AI_PROVIDER=ollama; empty by default. On a self-hosted install this is your own host.
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 — run the model on 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.