What Leaves the Machine
This page answers one question precisely: under what circumstances does anything you say to InterGen leave your computer, and what exactly goes?
The short answer is that by default nothing does, and the only path that sends anything is one you configure, arm, and then approve request by request while looking at the exact text being sent.
The default: nothing leaves
InterGen runs on your own CPU and GPU. There is no cloud account, no API key, no telemetry, and no background upload. After the first-run model download, the assistant needs no network connection at all. This is covered in Privacy & Data Locality; this page assumes it and goes on to the exception.
The exception is phone-a-friend — an optional feature that lets InterGen ask a cloud model you have configured for help on a request. It has no default provider. With none configured, escalation cannot run: the offer degrades to a note saying a provider would have to be configured, and no content is transmitted. A machine on which you have not done the setup in Setting Up a Frontier Model Provider has no egress path for conversation content.
The consent gate: show-before-send
When escalation is in its default ask mode and InterGen offers to escalate, consenting does not hand the assistant a blank cheque. It opens a show-before-send dialog: you are shown the content that would be transmitted, and you choose Send or Cancel.
The important property is that the view is not a summary and not a preview. A truncated view is forbidden. If the interface cannot display the full content, it says so and does not offer a partial rendering as though it were the whole thing. You are looking at what goes, or you are not being asked to consent.
This is what makes the consent meaningful. A dialog that says “send this conversation?” while showing you three lines of a forty-line payload is asking you to approve something you have not seen.
What is scanned, and when
There is a second protection behind the consent gate, for the traffic consent does not individually cover.
- The initial send you explicitly approved is trusted at its source. You looked at it and authorized it; it is not second-guessed.
- Every subsequent egress in the same flow — follow-on requests, agentic continuations, anything that was not individually shown to you and approved — is scanned through the same policy that guards tool execution. A block verdict refuses the send.
The reasoning is specific: the danger is not the message you read and approved, it is the fourth message in a chain you approved the first of. Scanning derived egress is what stops a credential, a key, or a file’s contents from being carried outward by a step you never individually saw.
When a scan blocks, the flow does not fail silently or send anyway. It stops and tells you review is required.
How the credential is handled
Two properties are worth knowing because they bound the damage if something else goes wrong:
- The API key is fetched from the system keyring per call, not held in process memory for the lifetime of the daemon, and it is never written into a configuration file — the configuration stores only the keyring entry’s identifier.
- Transmission over a non-TLS connection is refused. A
base_urlpointing at a plaintext endpoint fails closed.
What the assistant may not change
InterGen cannot modify the escalation:, providers: or sentinel: configuration sections. They are structurally immutable to the assistant; only a human edits them, by hand or through an authenticated path in the graphical interface.
This is the load-bearing guarantee on this page. Every other statement here describes a policy — and a policy the assistant could rewrite would be a description of its current mood, not a control. Because the assistant cannot reach these sections, the answer to “could it decide to send more?” is no, at the level of what it is able to do rather than what it is inclined to do.
Local documentation, local citations
One more thing does not leave the machine, and it surprises people: when InterGen cites documentation, it is citing the copy on your disk.
The full wiki is installed at /usr/share/doc/intergenos/wiki. Citations resolve to a file:// link into that local copy first and the online page second, so the primary link works with networking down. Looking something up in the manual is not a network event.
InterGen also refuses to cite a page that fails its integrity check. Every page is pinned by SHA-256 in a manifest that is signed with the operator’s release key; before a citation is emitted, the page’s bytes on disk are hashed and compared against that pinned value. If the page is not in the signed manifest, or its bytes no longer match, no citation is produced — the assistant answers without one rather than pointing you at documentation whose provenance it cannot stand behind. See Using InterGenOS Offline for the mechanism in full.
Summary
| Question | Answer |
|---|---|
| Does anything leave by default? | No. There is no provider configured out of the box. |
| Can the assistant enable egress itself? | No. The relevant configuration is immutable to it. |
| Do I see what is sent? | Yes, in full. A truncated view is forbidden. |
| What about follow-on sends I did not individually approve? | Scanned; a block refuses the send. |
| Where does the API key live? | The system keyring, fetched per call, never in a config file. |
| Plaintext transport? | Refused. |
| Do documentation citations touch the network? | No. They resolve to the local installed copy first. |