System Context

Where InvarOS sits

InvarOS operates as infrastructure beneath AI agent systems, not as a proxy in front of them. It captures, verifies, and attests — without routing every agent call through a cloud gateway.

InvarOS system context diagram AI Agent LangChain / MCP / AutoGPT / Custom executes on InvarOS Enterprise Platform Math Core · Policy · TBoM · K8s C++20 / Python · Proprietary core InvarOS Authority Governance Engine · Enterprise Math Provider Sole issuer of Decisions · Receipts · Leases InvarOS Runtime Plugin host · topology.so · evidence.so Dell x86_64 + GL-MT3000 deployed emits Evidence Store TBoM · Receipts CBOM · in-toto async Control Plane TBoM Explorer Direction / Roadmap — air-gap boundary — async transport optional — Kubernetes ValidatingWebhook Policy Author CANONICAL_POLICY compiles to ZK

Component boundary: InvarOS Runtime (invaros-runtime) is the native plugin and local-service host. It enforces and forwards; it never decides. InvarOS Authority (invaros-authority) is the sole governance decision service: it hosts the Governance Engine, calls the Enterprise Math Provider when a Snapshot declares a constraint, and issues every Decision Receipt and Authorization Lease. Runtime reaches Authority through the Authority Client over the versioned Governance Protocol.

MCP deployment boundary: InvarOS MCP Gateway is the separate Python FastMCP/ASGI integration service used for /mcp, /health, and optional /k8s/admission endpoints. Its Helm chart and image are invaros-mcp-gateway. It is not the native InvarOS Runtime plugin host and it is not the Authority.

Governed authorization path

Where the decision actually happens.

Beneath the agent, an interception point asks the Governance Engine for a decision before a tool call executes. Governance is the sole authority; the mathematical core is a required evaluator; the Runtime Authorization API is transport and lifecycle, never authority.

Agent tool call

OpenClaw before_tool_call hook

framed AF_UNIX request

Runtime Authorization API

InvarOS Runtime · transport · lifecycle

Authority Client · Governance Protocol

InvarOS Authority — sole authority

Governance Engine · Snapshot → Decision → Receipt → Lease

only when the Snapshot declares a constraint

Enterprise Math Provider

structural_legality · evaluates, never authorizes

DENY → 403 · ALLOW → 200 (exactly one execution)

signed evidence for every decision

Governance in depth How it is deployed The evidence it produces
Deployment Architecture

Server and edge deployments

InvarOS Runtime has been compiled and run on two hardware targets with different system configurations. Edge Network Topology Profile 4.0.0 (Internal Full and Public Minimal projections, shown below) was captured live on the native Runtime in an air-gapped environment, and again directly on a physical GL-MT3000 in the field — the current Runtime generation's first on-device Profile 4.0.0 capture. The earlier on-device captures in the diagrams below are the frozen legacy Profile 3.0.0 of the open TBoM standard, produced before the component was renamed; the recorded artifacts name it invarosd, which is the legacy name at time of evidence, and their bytes are unchanged. A separately loadable Runtime Evidence Plugin generates ES256-signed evidence records for the standalone Runtime's topology output.

Dell x86_64 Linux Server

Dell x86_64 deployment architecture HOST — Dell x86_64 Linux Container A (e.g. AI agent) veth43d2eca Container B (e.g. AI agent) vethacb583e docker0 — container bridge 172.17.x.x · node_bridge · MTU 1500 InvarOS Runtime topology.so · evidence.so host: 044eb029… · topo: 93c9dec0… Discovers: wlp3s0 · tailscale0 · enp2s0 edge_network_topology 3.0.0 (legacy) network · async receipts

GL-MT3000 OpenWrt Edge Router

GL-MT3000 OpenWrt deployment architecture HOST — GL-MT3000 / OpenWrt (MediaTek MT7981, aarch64) ra0 UP · radio → br-lan rax0 UP · ext → br-lan eth1 DOWN → br-lan br-lan — LAN bridge 192.168.x.1 · node_bridge · VLAN 800 InvarOS Runtime topology.so · evidence.so host: ca1d805c… · topo: a92137f8… Discovers: ra0 · rax0 · apcli0 · br-guest edge_network_topology 3.0.0 (legacy) nodes: 14 edges: 3 WAN · async receipts

Runtime integrity: InvarOS Runtime enforces that exactly one daemon instance governs a machine's invaros.topology namespace, network configuration, and Profile 4 identity store at any time, verified before any plugin loads or any UBus object registers. The Runtime also publishes live diagnostics over UBus — including per-method availability for Profile 3 (discover) and Profile 4 (discover_v4) topology discovery — so an operator can see exactly what a deployment is running.

Evidence Pipeline

From physical node to verifiable receipt

Topology observation and evidence generation are each deterministic, but today they are separate, independently-invoked stages — not a single chained pipeline.

01

Topology Discovery

The Runtime Topology Plugin scans host interfaces via netlink. Nodes classified as bridge, physical, logical, tunnel, or neighbor. Edges inferred from bridge membership.

topology_tbom.v1 · topology_fingerprint
02

Runtime Evidence Generation (standalone)

The Runtime Evidence Plugin generates and verifies ES256 (ECDSA P-256 + SHA-256) signed ContractEvent evidence records. It is loadable today but not yet orchestrated by the Runtime into an automatic per-observation flow. These are operational Runtime Evidence Records; Decision Receipts are issued only by InvarOS Authority.

ContractEvent · ES256
03

Attestation Pipeline

Enterprise platform Continuous Attestation Pipeline generates CycloneDX 1.6 CBOM, in-toto DSSE envelope, and ZK compliance claim from orchestrator results.

CBOM · in-toto · ZK claim
04

Federation Recognition

Recognition packets aggregate receipts and topology fingerprints asynchronously. Local/offline — no peer discovery, no consensus protocol. Transport is the operator's responsibility.

recognition_packet · chain_fingerprint
Captured Topology Evidence

Real Profile 4.0.0 artifacts — two disclosure projections

These are excerpts from validated, live Edge Network Topology Profile 4.0.0 TBoM artifacts captured by the native InvarOS Runtime in an air-gapped environment (evidence set profile4-20260714). Profile 4 emits the same observation as two projections: an Internal Full artifact that stays inside the deployment, and a Public Minimal artifact that is selectively disclosed and independently verifiable. This is the current profile of the open TBoM standard.

Internal Full · local

The complete observed topology — interface kinds, addresses, neighbours, and routes. Detailed, and kept inside the deployment boundary.

Public Minimal · selectively disclosed

Only hashed interface subject IDs and dataset counts cross the boundary — enough to independently verify the observation, not enough to expose the network.

Internal Full projection

edge-network-topology-v4-internal-full.json
"profile_id": "invaros.tbom.profile.edge_network_topology",
"profile_version": "4.0.0",
"intent_status": "absent",
"observation": {
"disclosure_profile_id": "…/disclosure-profiles/1/internal-full",
"interfaces": [
{ "interface_name_observed": { "value": "br-guest" },
"interface_kind_observed": "bridge",
"kind_state": { "kind": "bridge", "stp_state": 0, "vlan_filtering": false },
"mtu": 1500, "carrier": false, "link_status": "down",
"current_link_address": { "value": "‹redacted-mac›" },
"addresses": [ { "family": 4, "prefix_length": 24,
"address": { "value": "‹redacted-ipv4›" } } ],
"observation_subject_id": "sha256:52092b35…e23bfeb8" },
{ "interface_name_observed": { "value": "ra0" },
"link_status": "up", "mtu": 1500,
"master_observed": "sha256:c0d12711…61a26e84",
"observation_subject_id": "sha256:51b455ec…8c134c705" }
// … 11 interfaces · 87 neighbours · 45 routes (addresses redacted)
]
},
"fingerprints": {
"observation": { "availability": "available",
"value": "sha256:aeed97dd…186e2e72" },
"topology": { "availability": "unavailable",
"reason_codes": ["…/declared_intent_absent"], "value": null }
}

Public Minimal projection

edge-network-topology-v4-public-minimal.json
"profile_id": "invaros.tbom.profile.edge_network_topology",
"profile_version": "4.0.0",
"intent_status": "absent",
"observation": {
"disclosure_profile_id": "…/disclosure-profiles/1/public-minimal",
"datasets": [
{ "dataset": "addresses", "records_emitted": 12 },
{ "dataset": "links", "records_emitted": 11 },
{ "dataset": "neighbors", "records_emitted": 87 },
{ "dataset": "routes", "records_emitted": 45 }
],
"interfaces": [
{ "namespace_key": "root",
"observation_subject_id": "sha256:0098f030…dea66aa1" },
{ "namespace_key": "root",
"observation_subject_id": "sha256:1d66d2c9…bbbcf142" }
// … 11 interfaces; neighbours & routes disclosed as counts only
],
"neighbors": [], "routes": []
},
"fingerprints": {
"observation": { "availability": "available",
"value": "sha256:755e42c0…ac5861e7" },
"topology": { "availability": "unavailable",
"reason_codes": ["…/declared_intent_absent"], "value": null }
}

Derived from validated live Profile 4.0.0 artifacts. Network address and link-layer (MAC) values are redacted for publication; interface names, structural metadata, subject-ID hashes, and fingerprints are shown as captured and truncated only for display. In this capture no declared-intent manifest was supplied, so per Profile 4 the artifact is a valid observation-only projection: the observation fingerprint is available and independently reproducible, while the structural topology fingerprint is deliberately null with reason declared_intent_absent — structure comes only from declared intent, never from observed behaviour. Note that the two projections carry different observation fingerprints: each is bound to exactly the state that projection discloses.

Live from a physical GL-MT3000: On 2026-08-06, InvarOS Runtime produced a Public Minimal Edge Network Topology Profile 4.0.0 artifact directly on a GL.iNet GL-MT3000 router in the field — 12 addresses, 11 links, 104 neighbours, and 45 routes observed, fingerprinted with sha256:2374a920…dc7559. This is live-device network data, not synthetic or lab data — the first on-device Profile 4.0.0 capture from the current Runtime generation.

Historical note: earlier artifacts on this site were captured under the frozen legacy Edge Network Topology Profile 3.0.0, which remains supported for byte-compatible fingerprint continuity. Profile 4.0.0 is the current profile.

Federation Model

Air-gapped, asynchronous federation

InvarOS federation does not require a persistent cloud connection. It uses a three-pillar trust model based on cryptographic fingerprints alone.

Pillar 1

Governance (Rule)

Canonical policies define boundary conditions. Policy-to-ZK compiler generates deterministic, fingerprinted schemas. Rules are the authority that other pillars reference — they do not change per-tenant.

Pillar 2

Commitment (Proof)

Tenants generate commitment arcs progressing Intent → Consent → Settlement. Each transition is cryptographically witnessed. Commitment C ABI and Temporal Micro-Chain provide native-layer proof generation.

Pillar 3

Federation (Recognition)

Structural acceptance of commitments across boundaries. No consensus protocol. No WAN broadcast. The FederationRecognitionAdapter processes recognition asynchronously via thread pool, returning futures immediately.

Air-gap operation: Because InvarOS Runtime generates topology evidence locally, and its evidence-signing primitives run without any network dependency, the Runtime does not require a persistent connection to any control plane. InvarOS Authority decides locally over the Governance Protocol on the same host. Evidence batches can be physically transported across air-gaps. Core governance paths are offline/local-first by design; the federation model targets classified, sovereign, and highly regulated environments where always-on cloud connections are architecturally prohibited. End-to-end air-gapped operation is architecturally supported — a full disconnected deployment demonstration is on the roadmap.

Ready to plan a deployment?

Architecture assessments, topology extraction engagements, and pilot design are available now. Contact us to discuss your environment.

Discuss Architecture View Use Cases