Know exactly what your
AI can do — and prove it.
AI agents are starting to act on their own inside real systems — calling tools, moving data, and making changes without a human in the loop. InvarOS is the layer underneath them that decides what they are allowed to do, enforces it as part of the infrastructure itself, and keeps cryptographic proof of every decision. It runs wherever your systems run — from a developer laptop to a data center, an edge router, or a disconnected network with no cloud at all.
authority=governance decision=DENY reason=prohibited_marker
http=403 tool_call_blocked protected_body=0 bytes // not executed
request probe-allow-002 tool=invaros_probe_touch
authority=governance decision=ALLOW receipt=signed lease=single-use
lifecycle=CLAIM → COMPLETE http=200 executions=1 // exactly once
daemon=unavailable → http=403 fail-closed executions=0
A real captured decision from InvarOS governing agent tool calls at the OpenClaw gateway. InvarOS Authority is the sole authority: it denies before the tool body can execute, allows only with a signed Decision Receipt and single-use Authorization Lease, and the Runtime fails closed if Authority is unavailable. No cloud connection required. See the evidence →
Stop watching AI. Start governing it.
Most AI safety tools sit in front of the AI and inspect what it asks for. InvarOS changes where governance lives: it moves it underneath the AI, into the infrastructure the AI runs on.
Conventional AI security is like a security guard checking faces against a watchlist. It stands in front of the model, examines each request, and hopes the AI cooperates. A determined agent can simply take another door — a direct connection, a different socket, a second channel — and the guard never sees it.
InvarOS is like a border where the gate is the only path that physically exists. The rules are built into the structure of the environment, not bolted on in front of it. Because governance lives in the substrate the AI runs on, there is no other door to take — and every crossing leaves a signed, verifiable record.
What is Infrastructure Governance?
Governance treated like networking, storage, or compute — a property of the infrastructure itself, not an application you place in front of the AI and hope it respects. The control lives in the layer the AI cannot route around.
Why is it different?
A filter can be rephrased around. A proxy can be bypassed. An audit log arrives after the fact. Infrastructure Governance decides before execution, enforces deterministically, and produces cryptographic evidence — not a probability score.
Deterministic governance — decided, then deployed, then proven.
InvarOS authorizes what agentic AI can do before execution, evaluates policy with real mathematics, and ships that governance to hardware through a deterministic deployment lifecycle. Each capability produces evidence you can inspect.
Deterministic governance
A native Governance Engine authorizes agent tool calls before execution — categorical ALLOW / DENY / DEFER / ERROR, signed Decision Receipts, and single-use Authorization Leases. Deterministic DENY and ALLOW have been runtime-verified at the OpenClaw gateway.
How decisions are made →Mathematical authorization
When a policy snapshot declares a constraint, a deterministic Level-2 sparse-graph evaluator runs on the authorization path. Governance decides; mathematics evaluates and never authorizes.
The two authorities →Deterministic deployment
Governance ships through an immutable release, offline qualification, activation, health verification, and reconciliation. The first fully governed deployment reached DEPLOYMENT_HEALTHY and CANDIDATE_ACTIVE.
See the deployment →It starts with a bill of materials for your AI.
A software bill of materials (SBOM) lists the components inside a piece of software. A Topology Bill of Materials (TBoM) declares the topology of an AI system — what can talk to what, which tools and capabilities exist, and which pathways were deliberately excluded — as a deterministic, fingerprinted, machine-readable artifact. You cannot govern what you cannot describe. TBoM is how the system describes itself.
Topology Bill of Materials (TBoM)
The open topology standard for Infrastructure Governance. A public specification, Apache-2.0 licensed, with JSON Schemas, a reference validator, and conformance vectors. Anyone can produce, validate, and build on a TBoM — with or without InvarOS.
InvarOS
The infrastructure that produces TBoMs at the hardware layer, verifies them with a deterministic mathematical core, enforces policy before execution, and generates cryptographic evidence — from a developer workstation to air-gapped and sovereign deployments.
Application-layer tools vs. infrastructure.
The enterprise AI security market is built on API proxies, prompt filters, and post-hoc observability dashboards. They operate above the execution layer, where a sufficiently capable agent can route around them. InvarOS operates beneath it.
- API proxy — bypass with a direct connection
- Probabilistic prompt filter — bypass by rephrasing
- Post-hoc log aggregator — governance after the fact
- Cloud-dependent — offline environments unsupported
- Application tier — sits above the execution layer
- Deterministic — mathematical verification, not heuristics
- Infrastructure layer — beneath applications and agents
- Air-gap capable — operates autonomously, no cloud required
- Evidence-generating — cryptographic evidence for every governed decision
- One model from laptop to edge to sovereign deployment
Agentic AI is arriving faster than the controls for it.
Organizations are moving from AI that answers questions to AI that takes actions — autonomous agents wired into tools, data, and other agents through protocols like MCP. The governance tooling built for the previous era assumes a human approves each step and a cloud is always reachable. Neither assumption holds for autonomous agents at the edge, in regulated networks, or in air-gapped environments. Infrastructure Governance is built for the systems that are actually being deployed now.
One platform. Two implementation layers.
InvarOS is a single, coherent platform built in two complementary layers. Neither replaces the other — the native runtime grounds the enterprise platform in physical reality.
InvarOS Enterprise
The governance platform. A native C++ Governance Engine authorizes agent actions (Snapshots, Decisions, signed Decision Receipts, Authorization Leases) with the proprietary mathematical verification core as a required evaluator. Adds policy compilation to ZK-ready compliance schemas, Topology Bill of Materials (TBoM) generation, commitment arcs, evidence pipelines, Kubernetes ValidatingAdmissionWebhook enforcement, and asynchronous air-gapped federation.
InvarOS Runtime
The portable native plugin and local-service host. Designed to deploy across enterprise, server, edge, and micro-edge environments without architectural modification. Loads capabilities dynamically via a C ABI plugin boundary, produces TBoM artifacts locally without a cloud connection, and carries the Runtime Authorization API that asks InvarOS Authority for a decision before a tool call executes. The Runtime holds no policy evaluator of its own: the deployed system decides through Authority or not at all.
What InvarOS does today.
The following capabilities are implemented, tested, and operational. Where a capability is loadable but not yet wired into the automatic runtime path, we say so.
Governance Engine
A native C++ Governance Engine authorizes agent actions before execution. Immutable Snapshots bind policy, capabilities, and topology; a Session resolves a categorical Decision (ALLOW / DENY / DEFER / ERROR); every transaction carries a signed Decision Receipt, and ALLOW issues a single-use Authorization Lease. Deterministic DENY and ALLOW, fail-closed behavior, and recovery are runtime-verified at the OpenClaw agent gateway. How decisions are made →
Deterministic Deployment
An immutable release manifest, offline artifact qualification, side-by-side install, activation, health verification, and read-only reconciliation. The first fully governed deployment reached DEPLOYMENT_HEALTHY / CANDIDATE_ACTIVE. See the deployment →
Topology Bill of Materials (TBoM)
A formal representation of the operational topology of an AI system — infrastructure, execution topology, agents, tools, capabilities, trust relationships, evidence, and governance boundaries. InvarOS Runtime emits Edge Network Topology Profile TBoM artifacts per observation epoch, with topology and host fingerprints. See the open standard →
Cryptographic Receipts
Decision Receipts and single-use Authorization Leases are issued by InvarOS Authority for every governed decision. Runtime Evidence Records use sha256 fingerprints and ES256/ECDSA signing, with an optional HMAC-authenticated DSSE envelope for in-toto statements. CycloneDX 1.6 CBOM and ZK compliance claim wrappers are produced by the enterprise attestation pipeline. On the Runtime, the Evidence Plugin is loadable and functional but not yet orchestrated into the Runtime's automatic request path.
Mathematical Verification
A proprietary C++20 verification core built on continuous-time Markov chain (CTMC) methods, organized as a three-level architecture. It produces deterministic verdicts about structural and trajectory properties. The architecture is published; the solver implementation is confidential.
Native Plugin Architecture
InvarOS Runtime loads capabilities dynamically at runtime via a strict C ABI isolation boundary. Shared objects (.so files) attach to the Runtime without recompilation or service restart. The topology discovery plugin is operational; the Runtime Evidence Plugin (ES256 ContractEvent generation/verification) is loadable and functional but not yet orchestrated into the Runtime's automatic request path. This boundary enables proprietary mathematical solvers to be distributed as protected compiled plugins while the host Runtime remains separately deployable.
Kubernetes Admission
ValidatingAdmissionWebhook handler with SLSA annotation validation, attestation descriptor checks (structural, not live TPM/SGX/SEV verification), and cross-tenant namespace trust contract enforcement. Fail-closed posture.
Air-Gapped Federation
Asynchronous recognition model. Governance (Rule), Commitment (Proof), Federation (Recognition). No consensus protocol. No WAN broadcast. Cross-tenant trust via cryptographic fingerprints only. Live multi-tenant network federation is on the roadmap.
Policy-to-ZK Compiler
Canonical policy set dynamically compiled to ZK-ready compliance JSON schemas. Policy fingerprints generated deterministically. Schema correctness verified in CI with zero-drift compile gates. "ZK-ready" describes the schema format, not a production zero-knowledge proving system.
Integrations
Nine offline evidence adapters (including OpenTelemetry, Kubernetes, and LangChain) map platform events to local spans, manifests, and plan-only summaries — no live credentials or network calls in verified test paths. MCP stdio plus InvarOS MCP Gateway — the separate Python FastMCP HTTP service and invaros-mcp-gateway Helm chart — round out the integration surface without occupying the native Runtime identity.
The architecture changes in scale, not in principle.
The same governance model runs everywhere — a developer workstation, a Dell AI-in-a-Box, an enterprise cluster, an edge device, or a network with no path to the internet. Nothing about the approach depends on the cloud being reachable.
Real artifacts from real hardware.
The topology maps below are committed captures from real hardware deployments — not mock data or synthetic fixtures, captured under the frozen legacy Edge Network Topology Profile 3.0.0. InvarOS Runtime has since produced a live Edge Network Topology Profile 4.0.0 artifact directly on a GL-MT3000 in the field — see the Architecture page for the current Profile 4.0.0 artifacts, their two disclosure projections, and the physical hardware capture.
Dell x86_64 Linux Server
GL-MT3000 OpenWrt Edge Router
MAC addresses and final IP octets have been masked for publication. Node IDs and fingerprints are truncated. Structural composition and interface types are unmodified from the committed topology artifact.
What you can engage with today.
Available now
- The open TBoM specification, schemas, and reference validator (Apache-2.0)
- Pilot design and scoping conversations
- Architecture assessments and topology extraction engagements
- Consulting on AI governance infrastructure requirements
- Research and academic collaboration
- Integration design for MCP, LangChain, and Kubernetes environments
- Regulated and disconnected deployment planning
Coming shortly
- Public software packaging and distribution
- Self-service download portal
- Community edition release
- Documentation site and developer portal
The platform exists and substantial engineering has been completed. Public packaging is in progress. Contact us to discuss early access.