The Internet-Draft
VIRP is specified as draft-howard-virp-06, an individual Internet-Draft at the IETF. Six revisions (drafts -01 through -06) have been submitted. It is an individual submission, not a working-group document, and carries no IETF endorsement. The -06 revision, submitted August 2026, narrows the specification's claims to match the implementation and the language used across this site; the I-D has its own revision process and is not edited here.
Normative and companion documents
The authoritative documents live in the open repository:
- Protocol specification (RFC-style, v2): message types, session handshake, trust tiers, threat model, and conformance requirements.
- Wire format: the byte-level message layout.
- Claim Verification Layer (VIRP-CLAIMS): binds AI-generated assertions to specific authenticated observations. It does not guarantee that AI reasoning is correct; it makes assertions traceable, bounded, and auditable.
- The seven trust primitives: the explicit collector trust model, with per-primitive status.
- Observation flow and approval flow: end-to-end walkthroughs of the two paths.
Separate observation and intent authority
The requesting system never holds observation, chain, or approval keys. A protocol R-Node may hold an R-Key that authenticates intent requests, but that key cannot authenticate observations and does not authorize execution.
The authentication authority is the O-Node: a separate, hardened C daemon that talks to your devices over SSH, authenticates raw output with HMAC-SHA256 at the point of collection, and serves pre-authenticated data. If the O-Node can't reach a device, you get a verified “connection failed”, never a guess. No data means no assertion.
One precision for the careful reader: observations and approvals are protected differently. Observations carry HMAC-SHA256 authentication tags, a symmetric check verified by the O-Node that holds the key, which is why this site says “authenticated” rather than “signed” for them. Approvals are Ed25519 digital signatures; anyone holding the public key can verify one, no secret required. Both bind the record; only the approval side carries public-key non-repudiation.
The seven trust primitives, with honest status
| Primitive | Status | What it provides |
|---|---|---|
| Verified Observation | demonstrated live | Authenticated at collection; fabricated output carries no valid authentication tag. Independently validated 9/9 on production Cisco hardware. |
| Tiered Authorization | demonstrated live | GREEN / YELLOW / RED / BLACK, classified by the O-Node, never the AI. Approval flow demonstrated on a live switch. |
| Verified Intent | demonstrated live | Proposals are chained records referencing authenticated evidence; propose → approve → apply with TTL and single-use approvals. |
| Verified Outcome | demonstrated live | Authenticated before/after outcome records, chained to the proposal and approval that caused them. |
| Trust Chain | tested | Keyed, hash-linked, tamper-evident chain. Internal modification of presented records is detectable. Truncation and key-holder rewriting require trusted checkpoints or external anchoring to detect. Genesis, linking, tamper detection, and crash recovery are covered by tests. |
| Baseline Memory | implemented | Deviation detection from authenticated baselines. Not yet validated end-to-end. |
| Trust Federation | implemented | Per-node Ed25519 keys for multi-tenant isolation. Crypto is tested; no multi-tenant deployment exists yet. |
What an approval actually is
When a RED command is blocked, the gate files a proposal record on the chain and returns its ID. A human approver signs that specific proposal with a dedicated Ed25519 key, binding the exact command hash, the exact device, and a 300-second window. The approval works once. Reuse is refused with a typed error. Expiry is refused. Approval of a different command doesn't transfer. All of it lands on the chain.
Target compatibility
Precise per-target status, in place of “supports X” language. Demonstrated means shown working against real equipment with evidence; implemented means the driver exists with unit tests but no live demonstration. Exact tested target versions beyond those listed are not yet published; that gap is deliberate rather than papered over.
| Target | Transport | Read evidence | Tiered writes | Status |
|---|---|---|---|---|
| Cisco IOS | SSH | Yes | Yes, with signed approval | Demonstrated live (July 23 transcript; driver, gate tests) |
| FortiGate (FortiOS) | SSH | Yes | Not demonstrated | Lab-demonstrated reads (driver, tests) |
| Linux hosts | SSH | Yes | Not demonstrated | Lab-demonstrated reads (driver) |
| Proxmox Backup Server | API (typed operations) | Yes (v3.4) | No; closed read-only operation table | Demonstrated read path (walkthrough session) |
| Wazuh | API | Yes | No | Monitored, read-only mode (driver, tests) |
| Cisco ASA | SSH | Driver implemented | Not demonstrated | Implemented, unit-tested (tests); no live demonstration |
| Juniper Junos | SSH | Driver implemented | Not demonstrated | Implemented, unit-tested (tests); no live demonstration |
| Palo Alto PAN-OS | SSH | Driver implemented | Not demonstrated | Implemented, unit-tested (tests); no live demonstration |
Tests and formal work
- Test suites: core and per-driver adversarial assertions that pin protocol behavior, including the typed-error paths (replay, expiry, reuse).
- Formal verification artifacts: a ProVerif model of the v2 observation path with checked-in output. Scope and restrictions are stated on the security page.
Reference implementation
The reference O-Node and validator are C implementations under Apache 2.0 in the repository. The implementation demonstrates the specification; where the two disagree, that is a bug in one of them, and reconciling them is part of the draft-06 work.