Verified Infrastructure Response Protocol (VIRP) Specification

Internet-Draft	VIRP	March 2026
Howard	Expires 21 September 2026	[Page]

Abstract

This document specifies the Verified Infrastructure Response Protocol (VIRP), a cryptographic trust framework for AI-managed network infrastructure. VIRP provides structural guarantees that observations of network state are authentic and that proposed changes are authorized, through channel-separated key binding and tiered approval enforcement.¶

VIRP addresses the emerging threat of AI fabrication in network automation, where language model-based systems generate plausible but false device output, configuration state, or security findings. The protocol makes fabrication structurally impossible by requiring cryptographic proof of observation at the point of collection.¶

This revision introduces the Observation Gate, a post-response structural enforcement mechanism that verifies every device reference in an AI agent's output against the session's signed observation chain. Device claims without corresponding HMAC-signed observations are flagged before reaching the operator, closing the gap between cryptographic signing at collection and trust at the point of consumption.¶

▲

1. Introduction

1.1. Motivation

The introduction of AI reasoning systems into network infrastructure management creates a novel threat class: AI fabrication. Unlike traditional attack vectors (unauthorized access, man-in-the-middle, denial of service), AI fabrication occurs when a trusted automation system generates synthetic device output that is internally consistent and technically plausible but does not correspond to actual device state.¶

During development of the TLI AI Operations Center, the following fabrication events were observed in production:¶

An AI system generated three complete firewall policies with syntactically valid UUIDs, correct vendor syntax, and proper structural formatting. None of these policies existed on any managed device. The AI labeled this output "Confidence: HIGH."¶
An AI system reported security alerts originating from IP addresses in the 192.0.2.0/24 and 198.51.100.0/24 ranges (RFC 5737 documentation addresses). These addresses do not exist on the production network. The AI presented these as active threats requiring immediate remediation.¶
An AI system proposed BGP route changes referencing OSPF adjacency states that did not match any observed device output. The supporting evidence was fabricated.¶

Existing mitigations (prompt engineering, output validation, HMAC signing of executor output) proved insufficient. In case (a), the AI bypassed HMAC verification by generating fabricated output directly in its response text, never invoking the signed execution path. The HMAC protected the channel but not the consumer.¶

VIRP addresses this by making the AI a protocol participant with structural constraints, rather than a trusted black box with advisory guardrails.¶

1.2. Design Principles

VIRP is built on four principles:¶

OBSERVATION PRIMACY: All reasoning about network state MUST be grounded in cryptographically signed observations. Unsigned assertions about device state carry no protocol weight.¶
CHANNEL SEPARATION: The path for collecting facts (Observation Channel) and the path for proposing changes (Intent Channel) are cryptographically isolated. Keys are bound to their channel at the code level.¶
STRUCTURAL ENFORCEMENT: Security properties are enforced by code, not policy. BLACK tier operations do not have a "deny" handler — they do not exist in the wire format.¶
MINIMUM VIABLE TRUST: The verification path contains no AI, no inference, no probabilistic computation. Signing and verification are deterministic operations on fixed-size buffers using HMAC-SHA256.¶

1.3. Scope

VIRP is designed for AI-managed network infrastructure but is applicable to any system where automated decision-makers consume observations of physical or logical state. The protocol is transport-agnostic; this specification defines Unix domain socket and REST API bindings. TCP transport with TLS 1.3 is planned for peer-to-peer operation.¶

1.4. Applicability Beyond Networking

While this specification uses network infrastructure examples throughout, the VIRP architecture applies to any domain where AI agents consume telemetry and propose actions:¶

SECURITY OPERATIONS: SIEM and SOAR platforms where AI assistants analyze logs and propose incident responses. Signed log origin prevents fabricated attack traces.¶
COMPLIANCE AND AUDIT: Frameworks such as CMMC, SOC 2, and FedRAMP require evidence integrity. Signed telemetry provides cryptographically verifiable audit trails.¶
CLOUD INFRASTRUCTURE: AI agents managing AWS, Azure, or GCP resources. Signed API observations prevent fabricated resource state reports.¶
AUTONOMOUS SYSTEMS: Any future system where AI performs planning, reasoning, and remediation over physical or logical infrastructure requires machine-verifiable truth about the current state of that infrastructure.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.¶

O-Node: Observation Node. A process that connects to network devices, collects output, and signs observations. The O-Node holds an O-Key and operates exclusively on the Observation Channel for signing purposes.¶

R-Node: Reasoning Node. A process that consumes signed observations and proposes changes. Typically an AI/LLM-based system. The R-Node holds an R-Key and operates exclusively on the Intent Channel for signing purposes.¶

O-Key: Observation Key. A 256-bit symmetric key used for HMAC-SHA256 signing of Observation Channel messages. An O-Key MUST NOT be used to sign Intent Channel messages.¶

R-Key: Reasoning Key. A 256-bit symmetric key used for HMAC-SHA256 signing of Intent Channel messages. An R-Key MUST NOT be used to sign Observation Channel messages.¶

Observation: A signed record of device output collected by an O-Node. Contains the raw command output, a timestamp, sequence number, and HMAC-SHA256 signature.¶

Proposal: A signed request for network state change, generated by an R-Node. MUST reference one or more supporting Observations.¶

Approval: A signed authorization for a Proposal, generated by a human operator or automated approval system meeting the tier requirements.¶

Trust Tier: A classification of operations by risk level (GREEN, YELLOW, RED, BLACK) that determines the approval requirements before execution.¶

Channel: One of two cryptographically isolated communication paths. The Observation Channel (OC) carries signed facts. The Intent Channel (IC) carries signed proposals and approvals.¶

Wire Format: The binary serialization of VIRP messages as transmitted between nodes.¶

Freshness Window: The maximum age of an observation (measured from its timestamp) before it is considered stale and unsuitable for use as evidence in proposals.¶

Observation TTL: Time-to-live value indicating the maximum duration an observation may be cached and served as current.¶

Conformant Implementation: An implementation that satisfies all MUST-level requirements in this specification and passes the conformance test suite defined in Section 22.¶

3. Protocol Overview

3.1. Architecture

A VIRP deployment consists of one or more O-Nodes, one or more R-Nodes, and the managed devices they observe and control.¶

       ┌──────────────────────────────────────────┐
       │            Managed Device                  │
       │  (Router, Firewall, Switch, Server)        │
       └────────────────┬─────────────────────────┘
                        │ SSH / API / SNMP
                        ▼
       ┌──────────────────────────────────────────┐
       │              O-Node                        │
       │                                            │
       │  Collects device output                    │
       │  Signs with O-Key (HMAC-SHA256)            │
       │  Serves signed observations via socket     │
       │                                            │
       │  O-Key is NEVER accessible to R-Node       │
       └────────────────┬─────────────────────────┘
                        │ Signed VIRP Messages
                        ▼
       ┌──────────────────────────────────────────┐
       │              R-Node                        │
       │                                            │
       │  Consumes signed observations              │
       │  Reasons about network state               │
       │  Proposes changes (signed with R-Key)      │
       │  CANNOT forge observations                 │
       └──────────────────────────────────────────┘

Figure 1

3.2. Message Flow

A typical observation flow proceeds as follows:¶

R-Node sends an EXECUTE request to O-Node via socket¶
O-Node authenticates to the target device via SSH/API¶
O-Node executes the requested command¶
O-Node constructs an OBSERVATION message containing:¶

- The raw device output as payload - Current timestamp (nanosecond precision) - Monotonically increasing sequence number - Source node identifier¶

O-Node computes HMAC-SHA256 over the message¶
O-Node returns the signed message to the requestor¶

A typical intent flow proceeds as follows:¶

R-Node constructs a PROPOSAL referencing signed observations¶
R-Node signs the PROPOSAL with its R-Key¶
PROPOSAL is presented to human operators for approval¶
Operators generate APPROVAL messages (signed)¶
Upon sufficient approvals (per tier), execution proceeds¶
O-Node collects post-change observations for verification¶

4. Channel Architecture

4.1. Observation Channel (OC)

The Observation Channel carries messages representing measured network state. All OC messages are signed with O-Keys.¶

The following message types are valid on the Observation Channel:¶

Type Code Direction¶

       ─────────────────────────────────────
       OBSERVATION       0x01    O-Node → Consumer
       HELLO             0x02    Bidirectional
       HEARTBEAT         0x30    O-Node → Consumer
       TEARDOWN          0xF0    Bidirectional

   An attempt to sign an Intent Channel message type (PROPOSAL,
   APPROVAL, INTENT_ADVERTISE, INTENT_WITHDRAW) with an O-Key
   MUST return VIRP_ERR_CHANNEL_VIOLATION (error code 0x0003)
   without computing the HMAC.

Figure 2

4.2. Intent Channel (IC)

The Intent Channel carries messages representing proposed or authorized changes to network state. All IC messages are signed with R-Keys.¶

The following message types are valid on the Intent Channel:¶

Type Code Direction¶

       ─────────────────────────────────────
       PROPOSAL          0x10    R-Node → Approver
       APPROVAL          0x11    Approver → Executor
       INTENT_ADVERTISE  0x20    R-Node → Peers
       INTENT_WITHDRAW   0x21    R-Node → Peers
       HELLO             0x02    Bidirectional
       HEARTBEAT         0x30    Bidirectional
       TEARDOWN          0xF0    Bidirectional

   An attempt to sign an Observation Channel message type
   (OBSERVATION) with an R-Key MUST return
   VIRP_ERR_CHANNEL_VIOLATION (error code 0x0003) without
   computing the HMAC.

Figure 3

4.3. Channel-Key Binding

Channel-key binding is the core security property of VIRP. The binding is enforced at the function level in the signing implementation:¶

       virp_error_t virp_message_sign(
           virp_message_t *msg,
           const virp_key_t *key
       ) {
           // Channel-key binding check BEFORE HMAC computation
           if (key->channel == VIRP_CHANNEL_OC) {
               if (msg->header.type == VIRP_TYPE_PROPOSAL ||
                   msg->header.type == VIRP_TYPE_APPROVAL ||
                   msg->header.type == VIRP_TYPE_INTENT_ADV ||
                   msg->header.type == VIRP_TYPE_INTENT_WD) {
                   return VIRP_ERR_CHANNEL_VIOLATION;
               }
           }
           if (key->channel == VIRP_CHANNEL_IC) {
               if (msg->header.type == VIRP_TYPE_OBSERVATION) {
                   return VIRP_ERR_CHANNEL_VIOLATION;
               }
           }
           // HMAC computation proceeds only after binding check
           ...
       }

   This is not a policy decision. It is a code path. The HMAC
   function is never reached for cross-channel signing attempts.

Figure 4

5. Key Management

5.1. Key Structure

A VIRP key is a 256-bit (32-byte) symmetric key with associated metadata:¶

       struct virp_key_t {
           uint8_t     material[32];   // 256-bit key
           uint8_t     channel;        // VIRP_CHANNEL_OC or _IC
           uint32_t    node_id;        // Owning node identifier
           uint8_t     fingerprint[32]; // SHA-256 of material
       };

   Key material MUST be generated from a cryptographically secure
   random number generator (e.g., /dev/urandom, OpenSSL RAND_bytes).

Figure 5

5.2. Key File Format

Keys are stored as raw 32-byte binary files with no header, no encoding, and no metadata. The file contains exactly 32 bytes of key material.¶

Offset Length Field¶

       ──────────────────────────
       0       32      Key material (raw bytes)

   File permissions MUST be set to 0600 (owner read/write only).
   The channel association and node ID are maintained by the
   application, not stored in the key file.

Figure 6

5.3. Key Fingerprint

The key fingerprint is computed as:¶

fingerprint = SHA-256(key_material)¶

Fingerprints are used for key identification in HELLO messages and for human verification. Key material MUST NOT be transmitted over the network or exposed via API endpoints.¶

5.4. Key Lifecycle

GENERATION: Keys are generated locally on the node that will use them. O-Keys are generated on O-Nodes. R-Keys are generated on R-Nodes. Keys SHOULD NOT be transmitted between nodes.¶
STORAGE: Keys are stored in files with 0600 permissions. In production deployments, keys SHOULD be stored in a Trusted Platform Module (TPM) or Hardware Security Module (HSM).¶
ROTATION: Key rotation is performed by generating a new key, distributing the new fingerprint, and retiring the old key. Messages signed with the old key remain verifiable as long as the old key is retained for verification purposes.¶
DESTRUCTION: Key material MUST be securely zeroed using a function that cannot be optimized away by the compiler (e.g., explicit_bzero, memset_s, or volatile-qualified memory writes).¶

5.5. Key Rotation Procedure

Key rotation SHOULD be performed at regular intervals. The RECOMMENDED rotation period is 90 days for production deployments.¶

The rotation procedure is:¶

Generate new key material on the node¶
Compute fingerprint of the new key¶
Send a TEARDOWN message (reason: 0x01, Key rotation) signed¶

with the current key¶

Load the new key into the signing path¶
Send a HELLO message with the new key fingerprint¶
Peers update their fingerprint tables¶
Retain the old key in a read-only verification-only store¶

for the duration of the Observation TTL (Section 16) to allow verification of in-flight messages¶

During the transition window (between steps 3 and 6), peers MUST accept messages signed with either the old or new key. The transition window MUST NOT exceed 600 seconds.¶

5.6. Key Revocation

If a key is believed compromised, the following emergency procedure applies:¶

Generate a new key immediately¶
Send a TEARDOWN message (reason: 0x03, Error condition)¶

with the compromised key (if still held)¶

Load the new key¶
Send HELLO with new fingerprint¶
Notify all peers out-of-band that the old fingerprint¶

is revoked¶

Destroy the compromised key material (Section 5.4d)¶
All peers MUST immediately cease accepting messages signed¶

with the revoked key fingerprint¶

Observations signed with the compromised key that are still within the Observation TTL SHOULD be flagged as VERIFICATION_SUSPECT and re-collected using the new key before being used as evidence in proposals.¶

5.7. Key Compromise Detection

Implementations SHOULD monitor for anomalous signing patterns that may indicate key compromise:¶

Observations from devices that are known to be powered off or physically disconnected¶
Observations with timestamps significantly ahead of the local clock¶
Sequence number gaps larger than expected given the observation rate¶
Observations containing output that contradicts physical topology constraints (e.g., a device reporting an interface that does not exist in the device registry)¶

6. Trust Tier System

6.1. Tier Definitions

VIRP defines four trust tiers that govern the approval requirements for operations:¶

Tier Value Name Approval Required¶

       ──────────────────────────────────────────────────
       GREEN    0x01    Passive      None (auto-execute)
       YELLOW   0x02    Active       Single operator
       RED      0x03    Critical     m-of-n operators
       BLACK    0xFF    Forbidden    Structurally impossible

Figure 7

6.2. Tier Assignment

Tiers are assigned based on the operation's potential impact:¶

GREEN (0x01) - Passive observation, no state change: - show ip bgp summary - show ip route - show ip interface brief - show access-lists - show ip ospf neighbor - show running-config (read-only) - show logging - show version - get system status (FortiOS) - get system performance status (FortiOS) - Get-Process, Get-Service (Windows)¶

YELLOW (0x02) - Active diagnostics, minimal state change: - debug ip bgp updates (temporary) - show tech-support (resource intensive) - test ip route - ping / traceroute (generates traffic) - diagnose sys session stat (FortiOS)¶

RED (0x03) - Configuration changes, state modification: - configure terminal (any config mode entry) - ip route (static route changes) - router bgp / router ospf (protocol changes) - interface shutdown / no shutdown - access-list modifications - write memory / copy running startup - config firewall policy (FortiOS)¶

BLACK (0xFF) - Destructive, irreversible, or trust-breaking: - Key deletion or modification - Approval bypass - Factory reset - Disabling the observation channel - Modifying the trust tier assignments - execute factoryreset (FortiOS) - erase startup-config (Cisco IOS)¶

6.3. BLACK Tier Enforcement

BLACK tier operations are not denied at runtime. They do not exist in the protocol. There is no message type for key deletion. There is no approval workflow for disabling observers. The absence is structural, not procedural.¶

An implementation MUST NOT provide any mechanism — including administrative override, emergency mode, or debug interface — that allows BLACK tier operations to be performed through the VIRP protocol. Such operations, if required, MUST be performed through out-of-band mechanisms (physical console access, direct file system manipulation) that are outside the protocol's scope.¶

6.4. Tier Validation

The O-Node MUST validate the trust tier of each requested command before execution. Tier assignment is performed by pattern matching against a command classification table.¶

Commands not matching any tier pattern MUST default to RED (requiring explicit approval).¶

6.5. Tier Assignment Context

Tier assignment MAY be context-dependent. An implementation MAY assign different tiers to the same command based on:¶

TARGET DEVICE: "show running-config" on a lab router may be GREEN; on a production border router, YELLOW.¶
TIME OF DAY: Configuration changes during maintenance windows may be RED; outside maintenance windows, they require additional approval (m-of-n with higher m).¶
CUMULATIVE IMPACT: The first "interface shutdown" in a session may be RED; the tenth may escalate to require additional approval.¶

Context-dependent tier assignment MUST be documented in the deployment's configuration and MUST NOT reduce a tier below the default assignment for any command.¶

6.6. Tier Override Policy

Deployments MAY define a tier override policy that elevates (but never reduces) the default tier for specific commands on specific devices. The override policy MUST be:¶

Stored outside the R-Node's access (the AI cannot modify its own tier constraints)¶
Signed or integrity-protected to prevent tampering¶
Auditable — all overrides MUST be logged with timestamp, the identity of the administrator who configured them, and the justification¶

7. Message Format

7.1. Header Structure

All VIRP messages share a common 56-byte fixed header:¶

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Version    |     Type      |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Length (cont.)     |   Channel     |     Tier     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |   Reserved    |          Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                       Timestamp (64-bit)                      +
       |                       nanoseconds since epoch                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Source Node ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sequence Number                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     HMAC-SHA256 (256 bits)                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Total header size: 56 bytes (VIRP_HEADER_SIZE)

Figure 8

7.2. Header Fields

Version (8 bits): Protocol version. Current version is 0x01. Implementations MUST reject messages with unknown version numbers. See Section 18 for version negotiation.¶

Type (8 bits): Message type identifier. See Section 8 for defined types.¶

Length (32 bits, network byte order): Total message length in bytes, including header and payload. Minimum value is 56 (header only, no payload).¶

Channel (8 bits): Channel identifier:¶

           0x01 = Observation Channel (OC)
           0x02 = Intent Channel (IC)

   Tier (8 bits):
       Trust tier of the operation:
           0x01 = GREEN
           0x02 = YELLOW
           0x03 = RED
           0xFF = BLACK (MUST be rejected by implementations)

   Flags (8 bits):
       Bitfield for message flags:
           Bit 0: COMPRESSED - Payload is zlib-compressed
           Bit 1: FRAGMENTED - Message is part of a fragment set
           Bit 2: ENCRYPTED - Payload is encrypted
           Bit 3: STALE - Observation exceeds freshness window
                   (set by verifier, not originator)
           Bits 4-7: Reserved, MUST be zero

   Reserved (24 bits):
       Reserved for future use. MUST be set to zero on transmission.
       Implementations MUST reject messages with non-zero reserved
       fields to prevent protocol confusion attacks.

   Timestamp (64 bits, network byte order):
       Nanoseconds since Unix epoch (January 1, 1970 00:00:00 UTC).
       Implementations MUST reject observations with timestamps
       more than the configured freshness window (default: 300
       seconds) from the local clock to prevent replay attacks.
       See Section 16 for freshness semantics.

   Source Node ID (32 bits, network byte order):
       Unique identifier of the originating node. Assigned during
       node configuration. Node IDs MUST be unique within a VIRP
       deployment.

   Sequence Number (32 bits, network byte order):
       Monotonically increasing counter per source node. Wraps to
       zero at 2^32. Implementations SHOULD track the last seen
       sequence number per source and reject messages with sequence
       numbers more than 1000 behind the current value to detect
       replay attacks.

   HMAC-SHA256 (256 bits / 32 bytes):
       HMAC-SHA256 computed over the header (with HMAC field zeroed)
       and payload. See Section 10 for construction details.

Figure 9

7.3. Payload

The payload immediately follows the 56-byte header. Payload length is computed as:¶

payload_length = Length - VIRP_HEADER_SIZE¶

Payload contents are type-dependent. See Section 8 for per-type payload formats.¶

7.4. Maximum Message Size

Implementations MUST support messages up to 65,536 bytes (header + payload). Implementations MAY support larger messages using the FRAGMENTED flag.¶

7.5. Byte Order

All multi-byte integer fields are transmitted in network byte order (big-endian), as per Internet convention.¶

8. Message Types

8.1. OBSERVATION (0x01)

Channel: Observation Channel (OC) only Tier: GREEN (0x01) for read-only commands¶

Carries signed device output collected by an O-Node.¶

Payload: Observation sub-header (see Section 9) followed by raw device output as UTF-8 text.¶

An OBSERVATION message represents a single command execution on a single device. The payload contains the complete, unmodified output of the command as returned by the device.¶

O-Nodes MUST NOT modify, filter, or summarize device output before signing. The signed payload MUST be the exact byte sequence returned by the device driver.¶