Platform concepts.

The prevailing approach to AI security treats governance as an application-layer concern: an API proxy inserted before the model, a prompt filter on the input pipeline, or a dashboard aggregating post-hoc telemetry. These approaches share a structural weakness — they operate on voluntary cooperation. An autonomous agent is not obligated to route its traffic through your proxy.

InvarOS starts from a different premise. Governance belongs in the same category as networking, storage, and compute — it is a property of the infrastructure, not a policy applied on top of it. The invarosd daemon runs directly on host network interfaces. Evidence is generated at the hardware level. The enforcement surface is the substrate on which agents run, not a wrapper around them.

Infrastructure-layer governance produces evidence that is structurally more difficult to circumvent, because circumventing it requires circumventing the underlying operating environment. Application-layer governance produces advice that a sufficiently sophisticated agent can route around.

A Topology Bill of Materials is a formal, machine-readable artifact that represents the operational topology of an AI system — not merely its network configuration. A TBoM may span multiple layers of an AI deployment: physical and logical infrastructure, execution topology, agent and tool composition, capability registrations, governance boundaries, data paths, trust relationships, active commitments, recognition records, receipts, and evidence chains.

The scope of a TBoM is determined by the deployment context. At minimum, the TBoM produced by invarosd's topology discovery plugin contains a graph of discovered network interfaces, bridges, tunnels, and physical links, together with their operational state and a cryptographic fingerprint. In a full enterprise deployment, the TBoM extends to model the entire AI operational environment: which agents are present, what tools and capabilities they have access to, what policies govern their operation, and what evidence has been produced.

Governance cannot be meaningful if it is blind to what it is governing. A TBoM that captures only the network layer cannot reason about whether a particular AI agent has access to an unauthorised capability. A TBoM that captures the full operational topology can. The TBoM is not a configuration file, not a CMDB entry, and not a discovery scan. It is a formal representation of what is present and how it is connected, at a measured instant.

Each TBoM carries a host fingerprint and an observation epoch. Two TBoMs with different fingerprints represent topologically distinct environments, regardless of whether the difference was intended. TBoMs are durable governance objects — they persist as verifiable artifacts, can be compared across epochs to detect drift, and serve as anchors for downstream evidence. Receipts, attestations, and recognition records all reference the TBoM that was current when they were produced.

A Proof of Excluded Functionality is a cryptographic or mathematical statement that demonstrates the absence of a capability in a running system. It is the inverse of a capability claim. Where a capability claim says "this agent can do X," a Proof of Excluded Functionality says "this agent provably cannot do Y, and here is the structural evidence."

Conventional software verification focuses on what code does. Proof of Excluded Functionality addresses what code cannot do. In AI governance, this matters because the safety-critical property is often a negative: the agent must not be able to exfiltrate data over unauthorised channels, initiate unapproved network connections, or invoke capabilities that were not present at policy compilation time.

InvarOS constructs Proofs of Excluded Functionality through the combination of topology observation and policy verification. If a governance policy states that a particular network path must not exist, the TBoM from invarosd provides evidence that the path is or is not present. If the mathematical verification layer certifies a set of permitted state transitions, that certification is an implicit proof that all other transitions are excluded. The TBoM and the policy fingerprint together constitute a structured, verifiable claim about what the system cannot do.

In most AI systems, a refusal is an ephemeral event — a negative response that disappears into logs, if it is recorded at all. The agent declined to act, an error was returned, and the system moved on. This approach discards information that is structurally important for governance.

InvarOS treats refusals as first-class governance artifacts. When the governance system declines to authorise an operation — whether due to policy violation, failed attestation, unverified topology, or missing commitment — that refusal is not discarded. It becomes a structured, classified record: a durable governance object that can be inspected, cryptographically linked to the evidence that produced it, compared against prior refusals, audited, and referenced by future policy decisions.

Refusals belong to defined governance classes. A refusal produced by a policy evaluation is categorically distinct from one produced by a failed attestation check, which is in turn distinct from one produced by a topology mismatch. These classes are not arbitrary error codes — they represent different failure modes of the governance model, each with different implications for what corrective action is appropriate and what evidence should accompany the record.

A deployment's refusal history becomes an auditable corpus. An auditor examining past refusal records can determine not just that operations were declined, but under which class of governance rule, at what epoch, against what topology, and correlated with what other evidence. This is the difference between a governance system that enforces policy and one that can demonstrate that it enforced policy.

Deterministic governance produces a binary verdict — compliant or non-compliant — based on structural evidence rather than probabilistic scoring. It does not produce a confidence level, a risk score, or an anomaly threshold that requires calibration. A given topology either satisfies the policy or it does not.

Probabilistic approaches are suited to detection tasks where the signal is statistical — intrusion detection, fraud scoring, spam filtering. They are poorly suited to governance tasks where the requirement is categorical: the agent is or is not operating within its permitted boundary. A 94% confidence that an agent is compliant is not a governance guarantee.

InvarOS achieves deterministic governance through mathematical verification of structural properties. The governance policy defines permitted state transitions. The verification layer determines whether observed behaviour satisfies those structural constraints. There is no threshold to tune and no base rate problem — the verdict is derived, not inferred.

Governance that is unaware of topology cannot reason about connectivity, exposure, capability composition, or lateral movement. Most AI governance tools operate at the application layer — they see API calls, prompts, and responses. They have no visibility into which network interfaces are present, which agents have access to which tools, or whether an unexpected capability has been registered.

Topology-aware governance grounds policy in the actual structure of the environment. A policy that says "agents may not communicate outside the private subnet" can only be enforced — rather than merely monitored — if the governance layer has verified knowledge of what the subnet actually contains. A TBoM provides exactly this: a fingerprinted, epoch-stamped record of the actual operational graph.

When topology changes — a new interface appears, a capability is registered, an agent is scheduled, a trust relationship is modified — the topology fingerprint changes. This change can be detected, attested, and correlated against the expected topology derived from policy. Topology-aware governance makes the operational substrate a first-class input to policy evaluation.

Cryptographic evidence is a claim about system state that can be independently verified without trusting the party who produced it. InvarOS generates cryptographic evidence at each stage of the governance pipeline. Each stage produces a distinct governance object: topology observation produces a fingerprinted TBoM; execution events produce HMAC-signed receipts; the attestation pipeline produces CycloneDX CBOM records and in-toto statement envelopes; policy compilation produces deterministic policy fingerprints; governance decisions produce classified refusal records or signed recognition packets.

The value of cryptographic evidence over assertion or logging is auditability under adversarial conditions. An assertion can be falsified. A log can be tampered with. A cryptographically signed artifact produced by a known key at a known time is structurally difficult to repudiate. When an auditor asks whether a particular governance policy was in effect at a particular time, the policy fingerprint in the evidence artifact provides a verifiable answer.

InvarOS aligns its evidence formats with established standards: CycloneDX 1.6 for CBOM, in-toto v0.1 statements in optional DSSE signed envelopes, and ZK compliance claim envelopes. Alignment with standards allows evidence to be consumed by third-party audit tooling without proprietary integration work.

Federation in InvarOS is the process by which a governance authority recognises that a remote deployment is operating within the bounds of a shared governance policy. Conventional federation is typically solved with consensus protocols — mechanisms that require all participating nodes to agree on state before any transition is recognised. This approach is incompatible with air-gapped environments where network connectivity between participants cannot be assumed.

InvarOS uses an asynchronous, non-consensus model. Recognition is local and offline: a governance authority processes cryptographic evidence packages — receipts, TBoM artifacts, commitment arcs — and issues recognition without requiring a live connection to the remote deployment. The remote deployment does not need to know that recognition has occurred. Transport of evidence is the operator's responsibility, which permits physically-mediated transport (removable media, courier) as well as network transport.

The model is structured around three pillars: Governance (Rule), Commitment (Proof), and Federation (Recognition). A rule defines the permitted space. A proof demonstrates that an action was taken within that space. A recognition record is the governance authority's cryptographic acknowledgement of the proof — a durable governance object that persists independently of the connection state between parties. No pillar requires a live connection to either of the other two.

A native runtime operates at the operating system level, compiled to native machine code for the target architecture, without an intermediate interpreter, virtual machine, or managed language runtime. The invarosd daemon is a native C binary. This allows it to operate across the full deployment continuum — from enterprise server environments to constrained edge and micro-edge hardware — without architectural modification.

This matters for AI governance at the edge. Constrained hardware — network routers, embedded controllers, IoT gateways — is increasingly present in AI deployment environments. These devices cannot run a JVM or a Node.js process. A governance runtime that cannot operate on constrained hardware cannot enforce governance at the network boundary where it is most relevant.

Native runtime architecture also enables the C ABI plugin boundary. Capabilities are packaged as shared objects (.so files) loaded dynamically by the daemon without recompilation or service restart. This boundary allows proprietary mathematical solvers to be distributed as compiled plugins without exposing their implementation. The daemon remains open and auditable while the mathematical core remains confidential.

Plugin-based governance is the principle that governance capabilities should be modular, independently deployable, and capable of being updated without restarting the host process. InvarOS implements this through the C ABI plugin boundary in invarosd. The daemon is the host; capabilities are plugins loaded as shared objects at runtime.

The current operational plugins are topology discovery and receipt generation. Future plugins will implement local policy evaluation, MCP protocol interception, and additional transport layers. Each capability can be updated independently — a new topology plugin with support for additional interface types does not require modifying or recompiling the daemon.

The practical consequence is that governance infrastructure can evolve in production without service disruption. New capabilities can be added to a running system. In constrained environments where system updates carry operational risk, this granularity of update management is architecturally significant.

A Unified Control Plane is the single point of policy authority, evidence aggregation, and governance verification for an InvarOS deployment — regardless of how many physical nodes, hardware targets, or deployment environments it spans. There is no requirement for direct connectivity between the control plane and every governed node. Each node produces governance objects locally; the control plane processes them when they arrive.

The control plane holds the canonical policy — the single source of truth for permitted behaviour across the deployment. When policy changes, the change is compiled to ZK schemas and policy fingerprints that flow to governed nodes as plugin updates. When evidence arrives from governed nodes, it is evaluated against the current policy to determine recognition status.

A Unified Control Plane ensures that governance boundaries are set once, consistently, without per-node divergence. In deployments spanning diverse hardware — enterprise servers, edge routers, micro-edge devices — policy consistency does not emerge automatically. The control plane is the mechanism that maintains it across heterogeneous infrastructure.