On this page: The Internet-Draft · Documents · Observation and intent authority · The seven trust primitives · What an approval is · Target compatibility · Tests and formal work · Reference implementation
The Internet-Draft
VIRP is specified as draft-howard-virp-06, an individual Internet-Draft at the IETF. Seven revisions (-00 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 |
|---|---|---|
| 1. Observation Integrity | demonstrated live | Every observation authenticated at collection (HMAC-SHA256); fabricated output carries no valid authentication tag. Independently validated 9/9 in the reproducible demo against its simulated target; run live against a GNS3-emulated Cisco IOS 7200 instance on July 23. |
| 2. Two-Channel Separation | implemented, tested | Observation (read) and Intent (write) channels are architecturally separate and bound to distinct key roles; a message authenticated with the other channel’s key is refused. |
| 3. Intent Gating | demonstrated live | GREEN / YELLOW / RED / BLACK, classified by the O-Node, never the AI; commands matching no rule are treated as RED and refused by default. Propose → approve → apply with TTL and single-use Ed25519 approvals, demonstrated in the July 23 GNS3 run. |
| 4. Outcome Verification | demonstrated live | Authenticated before/after outcome records, chained to the proposal and approval that caused them. |
| 5. Baseline Memory | implemented | Deviation detection from authenticated baselines. Not yet validated end-to-end. |
| 6. Multi-Vendor Normalization | implemented, tested | A normalized observation schema across vendor drivers (Cisco IOS, FortiOS, Linux, and others) with per-driver unit tests. No published cross-vendor live transcript. |
| 7. Agent Containment | specified; enforced externally | The requesting process is treated as an untrusted principal with no access to key material, device credentials, or direct device paths. The draft requires containment to be enforced outside the protocol (hypervisor, network, filesystem); structural enforcement is in progress and not yet demonstrated. |
Primitive names and numbering follow section 5 of draft-howard-virp-06, which is authoritative. Two implementation mechanisms support these primitives without being primitives themselves: the trust chain (keyed, hash-linked, tamper-evident; internal modification of presented records is detectable, while truncation and key-holder rewriting require trusted checkpoints or external anchoring; genesis, linking, tamper detection, and crash recovery are covered by tests) and per-node Ed25519 federation keys for multi-tenant isolation (crypto tested; no multi-tenant deployment exists yet). The archived March 2026 page preserves an earlier, historical version of this list.
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 end to end with published evidence — the July 23 Cisco demonstration ran against a GNS3-emulated IOS 7200 instance, not physical hardware. Implemented means the driver exists with unit tests but no published 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 on a GNS3-emulated IOS 7200 instance (July 23 transcript; driver, gate tests) |
| FortiGate (FortiOS) | SSH | Yes | Not demonstrated | Implemented, tested; lab reads ran without a published transcript (driver, tests) |
| Linux hosts | SSH | Yes | Not demonstrated | Implemented, tested; lab reads ran without a published transcript (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.