Privacy & Data Locality
InterGenOS is built so that the data on your machine stays on your machine. The AI assistant, InterGen, runs locally by default and sends nothing off the box unless you explicitly opt in, on a single request, to a cloud provider you have chosen. There is no cloud account, no API key, no telemetry, and no background “improve the service” exfiltration. Security is not first. It is only.
This page documents the data-locality guarantees that hold today in InterGenOS 1.0-dev (build id v1.0-dev1).
The guarantee in one sentence
Every model InterGen uses runs on your own CPU and GPU, and nothing about your prompts, your files, your configuration, or your machine identity ever leaves the local network unless you deliberately escalate a single request to a cloud provider.
Local-only by default
InterGen is the system assistant that ships with InterGenOS. It is hardware-detected, offline-first, and runs entirely on the local machine using Qwen models. Its job is to know your machine, not the whole world.
- No cloud account. InterGen requires no sign-in, no license server, and no remote identity to function.
- No API key. The default assistant needs no credentials to a remote service.
- No telemetry. InterGen does not phone home with usage statistics, crash reports, prompt contents, or machine fingerprints.
- No silent escalation. There is no “we just send it to improve the service” loophole. Off-box communication only happens through one explicit, opt-in path, described below.
After the first-run model download, no network connection is needed for InterGen to work. The model is fetched once (roughly 1.5 to 21 GB depending on your hardware tier) and then runs offline.
The tiered models are selected automatically from your RAM and GPU. Smaller tiers serve machines with less memory; larger tiers unlock on machines with more RAM and a discrete GPU. Tier selection is a local hardware inspection — it sends nothing anywhere.
InterGen is off by default
InterGen does not run until you turn it on. You opt in either at install time, through the “Enable the InterGen AI assistant?” toggle in Forge’s package-selection screen, or at any later time by running:
intergen setup
This downloads the model and enables intergen.service, which ships enabled globally (system-wide via systemctl --global enable), then starts the assistant. To opt out, use the InterGen toggle in the desktop, or disable the unit globally:
systemctl --global disable intergen.service
A per-user systemctl --user disable does not undo the global enable, so use the global disable above or the in-app toggle.
The model files remain on disk under /var/lib/intergen/models/ in case you want to re-enable later without re-downloading. To reclaim that space, remove the directory as root:
sudo rm -rf /var/lib/intergen/models/
See the Forge installation guide for the install-time toggle, and the assistant overview for a wider tour of InterGen.
The one path off the box: Phone-A-Friend (Frontier/Cloud Escalation)
For the cases where you want the depth of a larger frontier model, InterGen offers an optional feature called Phone-A-Friend (Frontier/Cloud Escalation). It lets you opt in to a cloud provider of your choice on a per-request basis. It is off by default and never silent. You decide, for that single request, that the prompt may leave the machine. Nothing is sent without that explicit choice, and what leaves is scoped to that request — your current prompt and the context you give it for it, not your files, your wider conversation history, or your machine identity.
This is the only mechanism by which any prompt or data leaves the local network, and it is entirely under your control.
A jurisdiction note, stated plainly: the available providers — Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek — are operated by companies subject to the laws of their home jurisdictions; most are US-based and can receive lawful data requests. Phone-A-Friend never sends anything on its own, but once you escalate a request, that provider’s privacy policy and legal jurisdiction govern what you sent. For sensitive material, keep the request local.
Two separate axes: privilege and content trust
InterGen evaluates every action on two independent axes, kept deliberately separate.
| Axis | Question it answers |
|---|---|
| Privilege | Would a human need sudo for this, and what does it touch? |
| Content trust | Does data crossing a boundary carry an injected instruction (inbound) or leak a secret (outbound)? |
The privilege axis decides whether InterGen acts freely, asks for authorization, or refuses. The content-trust axis independently watches what the data carries — inbound scanning for injected instructions, outbound scanning to keep secrets from leaking. The pluggable scanner that handles content trust is InterGen Sentinel, which defaults to Local-Rules plus a Local-Qwen model. Its cloud providers (Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek) are opt-in only.
Keeping the two axes separate matters for privacy. A read of your own files is free on the privilege axis, while the content axis independently governs whether anything from that read may then leave the machine.
Reads are free; your data is not pre-shared
InterGen mirrors the privilege model the operating system already has. A read of non-secret data — your status, your file listings, most of /etc — runs immediately and locally, with no prompt and no off-box transmission. Reading is a local operation; the answer is computed on your machine.
Secrets such as /etc/shadow or key material are treated the way the OS treats them. Because a user can sudo cat their own shadow file, InterGen reading a secret triggers the OS’s real authorization prompt (pkexec/PolicyKit) rather than being forbidden. Whether the content of such a read may then leave the machine is governed separately by the content-trust axis. InterGen never pretends to be stricter than the OS, and it never pre-shares your data as a side effect of reading it.
InterGen cannot rewrite its own restraints
InterGen’s own files — its code, its panel extension, its model pins and signatures, its verified model store, its daemon units and PolicyKit policy, and its signing and provenance state — are treated as system-critical. InterGen may read them but may never modify them. Only you, acting manually and outside the assistant, can change them.
This closes a direct attack on your privacy: by design, a prompt injection cannot make InterGen rewrite its own gate, scanner, or guardrails, because those files are root-owned and write-forbidden to the unprivileged assistant. This is a deliberate defense-in-depth control, not a claim of perfect immunity — it removes the most direct coercion path (talking the assistant into weakening itself), so an assistant that will not edit its own restraints will not quietly open a channel off your machine either.
The local trust chain underneath
The data-locality guarantees rest on integrity guarantees that InterGenOS provides at the system level. The system ships with a signed Secure Boot chain, dm-verity integrity protection, and UKI signing, so the software making these promises is itself verified. Software is installed through the pkm package manager and the system is installed with Forge, the native installer. Together these give you a machine you understand, can modify, and can trust.
What this means in practice
- Your prompts, files, configuration, and machine identity stay local.
- The assistant is off until you enable it, and it can be fully disabled again.
- The only way anything leaves the box is a deliberate, per-request Phone-A-Friend (Frontier/Cloud Escalation) escalation that you initiate.
- No telemetry, no account, no API key, no silent channel.