-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
AI agents operating on network infrastructure have a fabrication problem. When an AI tells you a BGP session is established, or a firewall policy is misconfigured, or an interface is down — did it actually check? Or did it generate a plausible answer from training data?
During development of IronClaw, we observed an AI system generating firewall policies with valid UUIDs that did not exist on any device, reporting threats from RFC 5737 documentation address space, and proposing routing changes based on fabricated OSPF state. Every output was technically plausible. None of it was real.
VIRP solves this by signing every device observation at the point of collection, before the AI sees it. The AI cannot forge, modify, or fabricate observations because it never holds the signing key.
Logging records what the AI said. VIRP proves what the device returned.
A log can be tampered with. A log can be fabricated. A log does not prove the AI actually queried a device — it proves the AI claimed to query a device.
VIRP's HMAC signatures are produced by the O-Node at collection time using a key the AI never holds. If the signature verifies, the observation came from the O-Node. The AI could not have produced it.
VIRP prevents the AI from lying about what it observed.
Trust Tier enforcement (Primitive 2) prevents the AI from executing dangerous commands — BLACK tier commands are rejected in C before reaching the network. RED tier commands require human approval.
But VIRP is not a general-purpose AI safety system. It is a trust primitive for infrastructure operations. It solves the evidence problem — every claim the AI makes about device state is backed by a cryptographically verifiable observation.
It cannot produce a valid HMAC without the signing key. Any fabricated observation will fail verification at virp_ctypes_verify_observation(). The AI-side bridge rejects it before it reaches the AI layer.
The AI receives only observations that passed through the O-Node's signing path during an active session.
The O-Node (Observation Node) is the VIRP component that:
- Connects to managed devices via SSH or API
- Collects raw device output
- Signs it with HMAC-SHA256
- Maintains the tamper-evident chain database
- Manages the session handshake
The O-Node runs as a separate process (and in production, a separate VM) from the AI layer. It holds signing keys and device credentials. The AI node holds neither.
For local trust (Primitives 1-5), HMAC-SHA256 is appropriate because both signing and verification happen within the VIRP deployment. The O-Node signs, the bridge verifies using the same key.
For federation (Primitive 7), Ed25519 asymmetric signatures are used. This allows external parties (customers, auditors, remote NOCs) to verify observations using only the O-Node's public key, without ever having access to the private key.
Trust Federation (Primitive 7) allows verification of VIRP observations across organizational boundaries.
With local trust, only the O-Node and the AI bridge (which share the HMAC key) can verify observations. With federation, the O-Node signs with an Ed25519 private key. The public key can be distributed to anyone. Customers can verify that observations came from a specific O-Node without trusting the operator.
Yes. VIRP signs observations, not packets. The transport layer is irrelevant to the trust model.
Current drivers use SSH and REST. The same architecture applies to:
- AWS API calls (IAM audit logs, CloudTrail)
- Kubernetes API server responses
- Azure/GCP infrastructure APIs
If an AI agent claims an S3 bucket is public, VIRP can sign the API response that proves or disproves it. The trust guarantee is identical to the network case.
The C library compiles clean with -Wall -Wextra -Werror -pedantic -std=c11. It has 46 passing tests covering positive and negative paths. It has been tested on real hardware with 40 devices.
The session handshake JSON framing layer (wiring the C state machine to the actual socket protocol) is still in development. Until that is complete, the handshake operates with zeroed session IDs on the observation path.
The observation signing, chain storage, and federation primitives are production-grade.
draft-howard-virp-02 has been submitted to the IETF RATS (Remote ATtestation ProcedureS) working group. A Zenodo DOI is registered for the specification. The RFC is not yet an adopted IETF standard — it is an individual submission.
Apache 2.0. Use it freely. Contributions welcome.
Nathan M. Howard — founder of Third Level IT LLC, 15+ years of enterprise network engineering (Presidio, Sentinel Technologies), Fortinet NSE3.
VIRP was built by directing AI (Claude, ChatGPT) with deep infrastructure domain expertise. The architecture, design decisions, and protocol insights are human. The implementation was produced through human-AI collaboration.
See the Contributing section in the README.
Priority contributions:
- Driver authors — Juniper, Arista, Meraki, AWS, Azure, GCP
- Security researchers — audit the crypto, find weaknesses, open issues
-
Protocol designers — review
VIRP-SPEC-RFC-v2.md, comment on the IETF draft - Infrastructure engineers — deploy VIRP on your devices and report what you find
Contact: nhoward@thirdlevelit.com