Registry-Trust Boundary

InterGenOS draws a single, auditable line between what it will do on its own and what requires your explicit authorization. That line is the trust boundary, and it governs two things that are often confused: the packages that make up the system, and the local AI assistant that can act on the system on your behalf.

This page explains where the boundary sits, how it is enforced, and why it is shaped the way it is. The goal is a machine you understand, can modify, and can trust.

Two boundaries, one principle

There are two distinct trust surfaces in InterGenOS:

1. The package boundary — how software gets onto the machine, and how its integrity is proven before and after it lands.
2. The AI action boundary — what the local assistant is permitted to do without asking, what it must ask to do, and what it will never do at all.

Both follow the same principle: do not invent a new gate, inherit the one the operating system already has. A person at a terminal can freely touch their own files and needs sudo or PolicyKit for system-level changes. Mirroring that model keeps the machine understandable, because you already know how it works.

The package boundary

InterGenOS is built from source. The build pipeline runs in 20 phases (from validate through iso, with an optional publish step), producing the tiered package set that makes up the system. The package set spans six tiers — toolchain, core, base, desktop, ai, and extra — for a total in the neighborhood of 850 packages. These counts drift as the system evolves; derive the live figures from the repository rather than treating any number as fixed.

The package manager, pkm, is the consumer side of that pipeline. It installs, removes, queries, and verifies pre-compiled binary archives (.igos.tar.gz) on the live filesystem. Its trust model rests on three layers.

Provenance: the archive trust check

Before installation, pkm can verify an incoming archive against a trusted index synced from the central repository. The pkm install command exposes an --archive-trust flag that accepts three values: strict (the default when the flag is omitted), loose, and repo-only. In its strict and repo-only modes the archive’s SHA-256 hash is computed and checked against the trusted available index (synced via pkm sync) before the package is allowed to install. This is the inbound side of the boundary: an archive that does not match the repository’s recorded hash does not cross it.

Auditability: the hybrid data model

pkm keeps two parallel records of system state so that nothing about what is installed is hidden:

• A SQLite database at /var/lib/igos/pkm.db is the fast source of truth for queries and transactions. It records installed packages, every deployed file with its SHA-256 checksum, dependencies, an append-only history log of every install, removal, and supersede, and specialized tracking for /etc configuration files.
• Human-readable text manifests at /var/lib/igos/packages/ are generated alongside the database records so you can inspect what a package owns without any special tooling.

This duality gives you performance without giving up the ability to read the ledger yourself. Reads of this state are free; you never need to authorize asking the system what it has installed.

Integrity: content-hash verification after install

The boundary does not stop at install time. pkm verify recalculates the SHA-256 hash of every installed file on disk and compares it against the hash recorded in the database. This detects both accidental corruption and unauthorized modification of installed binaries after the fact. The archive check proves what came in; pkm verify proves it has not changed since.

Hardened deployment

Installation extracts to a staging directory using hardened tar flags (--no-same-owner, --no-same-permissions), checks invariants such as directory collisions and SUPERSEDES ordering, then deploys to the root filesystem. Setuid and setgid bits are dropped during extraction and only explicitly restored from the package’s own manifest metadata, so an archive cannot smuggle in unexpected privileged binaries. The database record is then written in a single atomic transaction.

The boot and integrity chain

The package boundary sits inside a broader signed chain. InterGenOS ships a signed Secure Boot chain, UKI (Unified Kernel Image) signing, and dm-verity integrity for the live system image. Together these establish that what boots is what was built and signed, before pkm ever runs on the live system.

The AI action boundary

InterGenOS ships InterGen, a tiered, hardware-detected, offline-first local assistant built on Qwen models, with zero telemetry. Because the assistant can act on the machine, it sits behind the strictest version of the trust boundary.

InterGen evaluates every action on two orthogonal axes that are never conflated:

Keeping these separate matters. The privilege axis decides whether an action is allowed; the content axis independently watches what a read returns or what an outbound message contains. A read of your own files is free on the privilege axis even while the content axis still inspects what that read returned.

Zones: where the action lands

The privilege axis classifies every target into one of three zones, mirroring what a human would need sudo to write:

Operations and outcomes

Actions are classified as R (read/inspect), W (write/modify), or X (execute/state-change). Each combination of zone and operation resolves to one of three outcomes:

• FREE — InterGen acts immediately, no prompt. All reads of non-secret data, and everything in your own space.
• AUTH-PROMPT — InterGen triggers the operating system’s real authorization (pkexec/PolicyKit), phrased plainly, for example: “InterGen wants to restart Bluetooth. That needs admin rights. Authorize?” Your password is the gate and the OS enforces it. There is no opaque internal “governance card.”
• FORBIDDEN — InterGen will not do it, and says so transparently (see below).

Reads are free even of system state: asking “what’s my system status?” or running pkm list never requires authorization. A parallel “autonomy tier” that blocks benign reads is exactly the anti-pattern this model exists to replace.

Reading a secret such as /etc/shadow is AUTH-PROMPT, not forbidden, because a human can sudo cat their own shadow file. InterGen does not pretend to be stricter than the operating system. Whether that content may then leave the machine is the separate content-trust axis.

The self-protection keystone

InterGen’s own files are classified Z3, which means InterGen may never modify its own substrate. This closes one of the most dangerous attack surfaces: a capable adversary’s whole goal is to talk the assistant into rewriting its own gate, model, manifest, or guardrails. If InterGen’s substrate is write-forbidden to InterGen, then even a flawless prompt injection cannot make InterGen weaken InterGen. Only you, acting manually and outside the assistant, can change those files.

The forbidden-to-self substrate includes InterGen’s code, its GNOME Shell panel extension, its signed model pins (models-manifest.json), the verified root-owned model store, its daemon units and PolicyKit policy, and its privileged runner. Reading this code is fine; changing it is not.

Transparent refusal

When InterGen refuses a Z3 action, it is open about it and hands control back to you. It states plainly what it will not do and why — it protects the boot and security trust chain, including its own integrity — and confirms that you can do it yourself. There is never a silent failure, a hidden refusal, or internal jargon. The intent is captured by its own wording: “I won’t modify the system’s boot and security files. That’s the trust chain that keeps this machine yours. It’s your machine, so you can do it yourself with sudo if you intend to; I just won’t be the one to touch it.”

InterGen Sentinel and the content axis

The content-trust axis is handled by a separate mechanism, InterGen Sentinel, a pluggable security scanner. By default it runs on Local-Rules and a Local-Qwen model, keeping scanning offline. It can additionally use six opt-in cloud providers — Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek — none of which are engaged unless you choose to enable them.

This opt-in escalation path is Phone-A-Friend (Frontier/Cloud Escalation): when local scanning wants a stronger second opinion, and only with your consent, it can consult a frontier model. The default posture is fully local with zero telemetry; the boundary to any cloud provider is one you cross deliberately, not one InterGenOS crosses for you.

Where the code and the model disagree

The gating model is the authoritative specification, and the code is held to it: where the implementation and the model diverge, the model is the reference and the implementation is corrected to match it. A single zone classifier and operation classifier feed one outcome resolver, giving one place to audit every decision, and FORBIDDEN is always checked before any authorization prompt is ever raised.

See also

• Package manager
• FAQ
• Forge installer guide