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 Attestation · Federation · Trust SDK C++20 / Python · Proprietary core invarosd Native daemon · C ABI plugin host topology.so · receipts.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
Deployment Architecture

Server and edge deployments

invarosd has been deployed on two hardware targets with different system configurations. Both produce authentic TBoM 3.0.0 artifacts and cryptographic receipts.

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 invarosd topology.so · receipts.so host: 044eb029… · topo: 93c9dec0… Discovers: wlp3s0 · tailscale0 · enp2s0 TBoM 3.0.0 · epoch: 1782690885 network · async receipts

GL-MT3000 OpenWrt Edge Router

GL-MT3000 OpenWrt deployment architecture HOST — GL-MT3000 / OpenWrt (mips_24kc) 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 invarosd topology.so · receipts.so host: ca1d805c… · topo: a92137f8… Discovers: ra0 · rax0 · apcli0 · br-guest TBoM 3.0.0 · epoch: 1782691017 nodes: 14 edges: 3 WAN · async receipts
Evidence Pipeline

From physical node to verifiable receipt

Every topology observation flows through a deterministic pipeline, producing cryptographically linked artifacts at each stage.

01

Topology Discovery

invarosd topology plugin scans host interfaces. Nodes classified as bridge, physical, logical, tunnel, or neighbor. Edges inferred from bridge membership.

tbom_v3.0.0 · topology_fingerprint
02

Receipt Generation

Receipts plugin emits HMAC-SHA256 signed evidence per execution event. Each receipt references the host fingerprint and observation epoch.

receipt · host_fingerprint
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
Authentic Topology Evidence

TBoM 3.0.0 artifacts from live deployments

The following JSON structure represents the schema of topology artifacts produced by invarosd. Node IDs, fingerprints, and epochs are authentic. MACs and final IP octets are masked for publication.

Dell x86_64 TBoM fragment

dell-topology.json — TBoM 3.0.0
"tbom_version": "3.0.0",
"topology_fingerprint": "93c9dec0c9dea70b
0fd8392d0a9322d8
8281e875627e080f…"
,
"subsystem_identity": {
"host_fingerprint": "044eb029…",
"observed_at_epoch": 1782690885
},
"graph": {
"nodes": [
{ "name": "docker0", "type": "node_bridge",
"status": "UP", "ip": "172.17.x.x" },
{ "name": "veth43d2eca", "type": "node_logical" },
{ "name": "wlp3s0", "type": "node_physical" },
{ "name": "tailscale0", "type": "node_tunnel" }
],
"edges": [
{ "source": "veth43d2eca", "target": "docker0",
"relation": "bridge_member" }
]
}

GL-MT3000 TBoM fragment

router-topology.json — TBoM 3.0.0
"tbom_version": "3.0.0",
"topology_fingerprint": "a92137f8a9d4161c
d8e4f604cc140ee3
cdbda4dd0f24d9fc…"
,
"subsystem_identity": {
"host_fingerprint": "ca1d805c…",
"observed_at_epoch": 1782691017
},
"graph": {
"nodes": [
{ "name": "br-lan", "type": "node_bridge",
"status": "UP", "ip": "192.168.x.1" },
{ "name": "ra0", "type": "node_physical" },
{ "name": "rax0", "type": "node_physical" },
{ "name": "apcli0", "status": "UP" }
],
"edges": [
{ "source": "ra0", "target": "br-lan",
"relation": "bridge_member" }
]
}

These fragments are derived from authentic deployment artifacts. Complete TBoM JSON files (with MAC addresses and internal IPs masked) are available on request during pilot and consulting engagements.

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 invarosd generates topology evidence and receipts locally and autonomously, the runtime does not require a persistent connection to any control plane. Evidence batches can be physically transported across air-gaps. The federation model was designed specifically for classified, sovereign, and highly regulated environments where always-on cloud connections are architecturally prohibited.

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