Keeping AI assistance on your own network

Command-line AI is one of those features that’s obviously helpful and quietly dangerous. Helpful, because explaining a gnarly error or drafting a one-liner is exactly the kind of thing a model is good at. Dangerous, because the input is your terminal output — which routinely contains hostnames, tokens, and the occasional pasted secret. Most tools ship that straight to a cloud model by default.

Kutrion inverts the default.

Self-hosted first

AI assistance runs against a self-hosted model by default, not a cloud one. An organization can opt in to a cloud fallback, and that needs a configured key, the organization’s own switch and the cloud_ai entitlement. There is no configuration in which your terminal output is quietly handed to a third-party model API because nobody changed a setting. For a lot of teams that is the whole requirement: useful assistance, nothing handed to a vendor, nothing to explain in a review.

Be precise about what that default is, though, because it is the part people get wrong when they cite it. It says which kind of model answers — one we run, not one we call. It does not by itself say whose network the model sits on:

• Self-host Kutrion and the answer is unambiguous. You enable AI by pointing the server at an Ollama host you run, so prompts and terminal output are answered on your own network and there is nothing to opt out of. Fully air-gapped is a first-class case here, not a workaround.
• On the hosted service, the default model is the one our deployment runs. That keeps your output away from a third-party model, which is the exfiltration risk this post is about — but it is our infrastructure, not your network. Moving inference onto your network is a configuration step, and it comes with conditions: an organization admin points Kutrion at an endpoint you operate, and because a hosted server can only reach a publicly addressable one, that traffic runs behind the same per-organization opt-in as cloud assist does.

If your requirement is “no third-party model”, the default meets it. If your requirement is “nothing leaves our premises”, self-hosting is the honest answer, and the AI privacy model doc spells out both cases rather than letting one stand in for the other.

Cloud is an exception, not a default

If you do opt into a cloud model — per organization, as an explicit policy — secrets don’t go out with it. A redaction step strips keys, tokens, passwords and PII, a guard checks for prompt-injection, and every send is written to the audit trail. Be clear about what that step is, though: it removes values that have a recognizable shape, not the operational content around them. On a measured transcript about 90% of the text still reaches the model — command text, hostnames, query text. The thing keeping that content out of a cloud model is the self-hosted default and the opt-in, and enabling cloud assist is a decision you make rather than a default you have to discover and turn off.

And whether a cloud model is allowed at all is an org-level switch you hold, not one we flip for you. For a team whose requirement is that terminal output never leaves its own network, the deployment that delivers that is a self-hosted install.

Catching leaks, not just preventing them

The same pipeline that brokers your sessions also scans command output for credential exposure. A careless paste that drops an API key into a log doesn’t go unnoticed — it’s flagged and audited, so you can rotate before it matters.

That’s the principle across Kutrion: assistance that never defaults to someone else’s model, cloud only behind a gate you control, a self-hosted deployment for teams that need the work to stay on their own network, and a record of what happened either way. More on the model on the Security & Trust page.