VIRP: Verified Infrastructure Response Protocol

3.1. Current State

Existing infrastructure management tools assume a trusted operator. SNMP polling trusts that the collector reports what it received. Ansible playbooks trust that tasks executed as written. SIEM correlation trusts that log sources are authentic. These trust assumptions are reasonable when humans are in the loop at every step.¶

AI agents break these assumptions. An agent running in an autonomous loop may execute hundreds of commands per session. Human review of every action is impractical. The operational benefit of AI autonomy is inseparable from reduced per-action oversight -- which means the integrity guarantees that relied on human review must be replaced with cryptographic equivalents. This shift is consistent with the Zero Trust Architecture principles articulated in [NIST-ZTA]: trust is established per-operation through verification, not inherited from an authenticated session.¶

3.2. The Fabrication Problem

The most significant risk in AI-driven infrastructure management is not malicious action -- it is undetectable error. An AI agent that misreads output, hallucinates a device state, or generates plausible-looking but incorrect telemetry can drive remediation actions based on false premises. Without cryptographic evidence that an observation was collected from a real device at a real timestamp, there is no mechanism to distinguish a genuine observation from a fabricated one.¶

3.3. The Accountability Gap

When an AI agent takes an action on infrastructure, current tooling records what the agent reported it did. VIRP records what the collection boundary observed the device return, with a chain of custody linking the intent to the observation to the outcome. This distinction is operationally significant: in an incident, the difference between what an agent said it did and what the device actually experienced may be the entire root cause.¶

5.1. Primitive 1: Observation Integrity

Every device observation is authenticated at collection time within the O-Node using HMAC-SHA256. In session-bound mode (Section 6.4) the authenticated header covers the device identifier, timestamp, per-session sequence number, session identifier, a digest of the canonical command, and the payload length, and the authenticated bytes include the raw output. In the legacy format (Section 6.3) the authenticated bytes cover the header and output but carry no session, device, or command binding. Observations that fail verification are rejected. A party that does not hold the relevant key cannot produce an observation that verifies; a party that does hold it can (Section 6.1).¶

Failure mode addressed: fabricated or replayed telemetry originating outside the collection boundary. An agent that holds no observation-authentication key cannot report a device state that the boundary did not collect.¶

5.2. Primitive 2: Two-Channel Separation

VIRP enforces strict separation between Observation (read) and Intent (write) channels. Observations flow from device to O-Node to chain. Intents flow from the requesting party to the tier classifier to the O-Node to the device. The channels are architecturally separate and are additionally bound to distinct key roles: the implementation refuses to authenticate an Observation Channel message with an Intent Channel key or the reverse.¶

Failure mode addressed: an agent that reads device state and takes action within the same unmonitored channel, bypassing authorization controls.¶

5.3. Primitive 3: Intent Gating

Before any write operation reaches a device, an Intent must be filed with the O-Node specifying the target device, command class, and justification. The tier classifier evaluates the intent against the trust tier framework. GREEN tier intents may execute immediately. YELLOW tier intents require human acknowledgment. RED tier intents require explicit approval carrying an Ed25519 signature from an enrolled approver, bound to the command digest, the target device, and an expiry. BLACK tier intents are rejected unconditionally. Commands that match no classification rule are treated as RED and are refused by default.¶

Failure mode addressed: unauthorized state changes. An agent cannot modify device configuration without a prior authorized intent on record.¶

5.4. Primitive 4: Outcome Verification

Following every authorized action, VIRP collects a post-action observation and compares the resulting device state against the expected outcome of the intent. Divergence between expected and actual state generates a trust tier escalation. Outcomes are authenticated and chained alongside the original intent.¶

Failure mode addressed: actions that execute but produce unexpected results, which would otherwise be invisible in the audit trail.¶

5.5. Primitive 5: Baseline Memory

VIRP maintains an authenticated baseline of known-good device state derived from a verified observation sweep. Subsequent observations are compared against the baseline. Deviations -- new BGP peers, changed interface states, modified firewall policies -- generate alerts and may trigger tier escalation. The baseline itself is a chain of authenticated observations and is verifiable by any holder of the relevant key.¶

Failure mode addressed: undetected configuration drift. The system knows what normal looks like and can detect when it changes.¶

5.6. Primitive 6: Multi-Vendor Normalization

VIRP defines a normalized observation schema that abstracts vendor-specific output formats. Cisco IOS show commands, FortiOS get commands, and Linux system calls are mapped to a common observation structure. This enables consistent chain integrity verification across heterogeneous infrastructure.¶

Failure mode addressed: trust model fragmentation across vendors. A single chain can represent observations from any supported device type.¶

5.7. Primitive 7: Agent Containment

The requesting process must be treated as an untrusted principal. Process containment must be enforced externally -- at the hypervisor layer, at the network boundary, and at the filesystem level. The requesting process must not have access to observation, chain, or approval key material, to device credentials, or to direct network paths to managed devices.¶

This primitive was identified during live adversarial testing when the agent under test self-reported that it could bypass VIRP's observation chain by going around it entirely -- accessing credentials directly, connecting to devices without chain entries, or spawning unsupervised inference sessions. The primitive formalizes the architectural response: containment is not policy, it is structure.¶

Failure mode addressed: a requesting process that circumvents the observation chain entirely. VIRP protects the chain -- Primitive 7 ensures the requester cannot go around it.¶

7.1. Containment Layers

• Hypervisor layer: virtual-machine firewall rules enforce network policy outside guest control.¶
• Network layer: host firewalling restricts outbound traffic on the requesting host and inbound traffic on the O-Node.¶
• Process layer: an unprivileged service user with no-new-privileges, a strict read-only system view, and a private temporary directory.¶
• Filesystem layer: credential files owned by root with mode 0600, inaccessible to the service user.¶
• Cryptographic layer: the requesting host holds no observation-authentication key, so a compromise of that host does not confer the ability to produce an observation that verifies. This is a property of key placement, not of asymmetric cryptography; see Section 6.1 for the precise scope.¶

10.1. Architectural Motivation

In the current design, a compromised O-Node can forge observations, approve intents, and execute actions on devices. While chain integrity makes tampering with presented history detectable to a party that holds an independently retained chain head, a live compromise grants the attacker control over future operations for the duration of the compromise window.¶

The three-role architecture addresses this concentration of trust by decomposing the O-Node into three distinct principals, each with a narrow set of capabilities and its own keying material. The design goal is that compromise of any single node is insufficient to both fabricate state and act on that fabrication.¶

10.2. Observer Node

The Observer Node is responsible for device telemetry collection and observation authentication. It holds read-only credentials for managed devices and the observation key material. The Observer Node listens on a read-only socket and MUST NOT accept or process write intents.¶

The Observer Node authenticates each observation at collection time, covering the fields specified in Section 6.4. The authenticated observation is referenced from the chain and made available to other nodes over the read-only socket.¶

The Observer Node holds no policy state, no approval authority, and no write credentials. It cannot authorize or execute configuration changes on any managed device.¶

10.3. Executor Node

The Executor Node holds write credentials for managed devices. It receives command bundles that have been signed by the Policy Node and executes them against the specified targets. The Executor Node MUST refuse execution of any command bundle that does not carry a valid Policy Node signature.¶

The Executor Node holds no chain key, no observation key, and no policy or constraint state. It does not evaluate whether a command is appropriate; it verifies only that the command bundle bears a valid signature from a known Policy Node. The Executor Node makes no autonomous decisions.¶

Upon completing execution, the Executor Node reports the result to the Observer Node, which independently collects a post-action observation for outcome verification. The Executor Node does not self-report success or failure into the observation chain.¶

10.4. Policy Node

The Policy Node holds the constraint ledger, operator preferences, trust tier definitions, and the approval queue. It receives intent requests, evaluates them against policy, and -- if approved -- signs a command bundle with its own Ed25519 private key and forwards it to the Executor Node.¶

The Policy Node MUST NOT hold device credentials of any kind. It never communicates directly with managed devices. Its sole output is signed command bundles delivered to the Executor Node. The Policy Node consumes observations from the Observer Node for situational awareness but cannot influence or alter the observation chain.¶

Human approval workflows, trust tier escalation, and operator overrides are mediated through the Policy Node. Tier classification (as defined in Section 8) is performed by the Policy Node rather than by a co-located intent router.¶

10.5. Separation-of-Duties Property

The three-role architecture enforces a strict separation-of-duties property: no single node can observe device state, approve an action, and execute that action. Each of these three capabilities is held by a different principal with independent keying material.¶

Observation requires the observation key (held only by the Observer Node). Approval requires the Policy Node signing key (held only by the Policy Node). Execution requires device write credentials (held only by the Executor Node). An attacker who compromises any single node obtains exactly one of these three capabilities.¶

This property MUST be enforced at the protocol layer. Implementations MUST NOT permit a single process or host to hold the keying material of more than one role in a production deployment of the three-role architecture.¶

10.6. Compromise and Blast Radius Analysis

The following analysis considers the impact of compromising each node individually and in combination.¶

Observer Node compromise. An attacker gains the observation key material and read-only device credentials, and can forge or fabricate observations and read device state passively. The attacker cannot approve intents and cannot execute write operations. Blast radius: observation forgery and passive reconnaissance.¶

Executor Node compromise. An attacker gains device write credentials, but the Executor Node only processes command bundles carrying a valid Policy Node signature. The attacker may attempt to replay previously received, validly signed bundles. Implementations SHOULD include replay protections such as nonces or expiring timestamps in command bundles. Blast radius: replay of previously approved commands, bounded by those protections.¶

Policy Node compromise. An attacker gains the ability to sign arbitrary command bundles, but the Policy Node holds no device credentials and has no network path to managed devices. Blast radius: unauthorized approvals and signed bundles that remain inert unless delivered to a compromised Executor Node.¶

Observer and Executor compromise. The attacker can forge observations and holds write credentials, but cannot generate validly signed command bundles. The attacker could bypass the Executor's signature check through local code modification, effectively using the write credentials directly. This is equivalent to raw device access plus observation forgery; the Policy Node's approval record will show no corresponding approval, subject to the retention and anchoring qualification in Section 9.¶

Policy and Executor compromise. The attacker can sign arbitrary command bundles and execute them. This is the most operationally dangerous two-node scenario. The attacker cannot forge observations: post-action observations collected by the uncompromised Observer Node record the resulting device state.¶

Observer and Policy compromise. The attacker can forge observations and sign bundles, but cannot execute commands. Blast radius: fabricated state and pre-signed malicious bundles, with no execution capability.¶

Full three-node compromise. Equivalent to a compromised single O-Node in the current architecture. The three-role architecture does not defend against simultaneous compromise of all principals; its value lies in requiring the attacker to breach three independent trust boundaries rather than one.¶

10.7. Migration Roadmap

Stage 1: Single O-Node (current). The existing single-process O-Node handles observation, policy evaluation, and execution. This is the deployment baseline described throughout this document. The blast radius of an O-Node compromise is the full set of managed devices.¶

Stage 2: Observer-Executor separation. The O-Node is split into an Observer process and an Executor process, each with its own socket and credentials. This separation can be achieved on a single host using process isolation.¶

Stage 3: Policy Node extraction. Policy evaluation, the constraint ledger, and the approval queue are extracted into a dedicated Policy Node process with its own signing key. The Executor Node is modified to require a valid Policy Node signature on all command bundles.¶

Stage 4: Physical separation. The three nodes are deployed on separate hosts with independent network policies. The Policy Node may be placed on an air-gapped host or backed by a hardware security module for its signing key. Inter-node communication is authenticated using mutual TLS or a comparable mechanism.¶

10.8. Security Considerations for Role Separation

The three-role architecture introduces inter-node communication paths that do not exist in the single O-Node design. Each path represents an attack surface that MUST be protected by authenticated and encrypted transport. Implementations MUST NOT rely on network topology alone for inter-node authentication.¶

Key management complexity increases with role separation. Key rotation procedures MUST be defined for each role independently, and public keys MUST be distributed to the nodes that verify signatures.¶

Command bundle replay is a risk specific to the Executor Node. Implementations SHOULD include monotonic sequence numbers and expiration timestamps in signed command bundles, and the Executor Node SHOULD reject bundles already processed or exceeding a configurable staleness threshold.¶

The migration roadmap permits intermediate states where two roles share a host or process. Implementations operating in an intermediate state SHOULD document which separation-of-duties properties are enforced and which are deferred.¶

11.1. G1: Observation Non-Forgeability (symmetric, per key)

A party that does not hold the authenticating key for an observation cannot produce a record that verifies. For a v1 observation this is HMAC-SHA256 under K_obs; for a v2 observation it is HMAC-SHA256 under the HKDF session key. Without the relevant key it is computationally infeasible to produce a valid authentication code, under the standard PRF/MAC assumption on HMAC-SHA256. The property is relative to that key's secrecy and does not hold against a holder of the key.¶

Role separation limits cross-artifact forgery, with one explicit exception in the reference implementation: the O-Key directly authenticates v1 observations and also serves as the input keying material for v2 session-key derivation. An O-Key holder can therefore forge v1 observations and, when it possesses the required derivation context, derive keys capable of forging v2 observations. This reuse does not confer the ability to forge chain entries, Intent Channel messages, approvals, or federation records authenticated under separate keys.¶

Asymmetric non-forgeability -- origin verification without a forging-capable secret -- is future work (Section 17.3) and would still not bound signer compromise.¶

11.2. G2: Chain Integrity

Any modification to, deletion of, or insertion into the presented chain is detectable by a verifier holding K_chain, because the canonical entry encoding covers the predecessor's entry digest and is itself covered by an HMAC under K_chain (Section 6.5). Two qualifications are load-bearing. First, this property is relative to the secrecy of K_chain: a holder of K_chain can recompute a consistent history. Second, it establishes the integrity of the entries presented, not that the presented chain is complete; detecting truncation or a withheld suffix requires an independently retained chain head or an external checkpoint (Section 17.4).¶

11.3. G3: Intent Prior to Action

No write operation reaches a device through the gate without a prior authorized intent on record. The O-Node refuses execution for any action without a matching authorized intent, and for RED-tier actions without a valid approval bound to the command digest, device, and expiry. This property holds even if the requesting process is fully compromised. It does not hold against a party that possesses device credentials and a network path to the device outside the gate; that case is addressed by containment (Section 7) and by device-side authorization, not by this protocol.¶

11.4. G4: Two-Channel Non-Conflation

The Observation and Intent channels are architecturally separate and key-role separated. An observation cannot authorize an intent. An intent cannot substitute for an observation.¶

11.5. G5: Agent Non-Escalation

The requesting process cannot escalate its own trust tier. Tier classification is performed by a separate process outside that process's modification scope.¶

12.1. Component Summary

12.2. Test Coverage

The reference implementation carries C unit and integration suites, Python end-to-end and parity tests, a fuzzing harness, concurrency tests, negative tests for replay and approval reuse, live-hardware exercises across several vendor platforms, and a re-runnable formal proof target. Exact counts change with every revision of the code and are therefore not asserted here; they are reported by the test target in [VIRP-REPO]. Claims in this document that depend on implementation state are marked as such in Section 18.¶

13.1. BGP Daemon Hooks

The module registers four hook callbacks covering the primary BGP event classes:¶

Data captured per hook: peer_status_changed records peer IP, peer AS, local AS, old and new FSM state, router-id, and producer identifier. peer_backward_transition records peer IP, peer AS, local AS, last FSM state, last major event code, uptime, and router-id. bgp_process records prefix, peer IP, peer AS, AFI, SAFI, router-id, and the announce/withdraw flag. bgp_route_update records prefix, AFI, SAFI, router-id, and the old and new path attributes (peer, nexthop, AS path, MED, local-pref, origin).¶

Trust tier assignment happens at the source: the peer_backward_transition hook always emits YELLOW tier because loss of an Established session is operationally significant. The peer_status_changed hook conditionally escalates to YELLOW when it detects a transition away from Established. All other observations are GREEN tier.¶

All hooks are registered at module load and unregistered at module teardown, following the FRR module lifecycle pattern.¶

13.2. BGP Observation Wire Format

Each observation is transmitted as a contiguous byte stream over the Unix domain socket: a packed binary header, a variable-length JSON payload, and an HMAC-SHA256 digest. All multi-byte integer fields in the header are in network byte order.¶

Bytes  Field          Encoding
-----  -------------  --------------------------------
 0-3   magic          0x56495250 "VIRP" (net order)
 4     version        uint8 (currently 1)
 5     obs_type       uint8 (1-4, see hook table)
 6     trust_tier     uint8 (0=GRN 1=YLW 2=RED 3=BLK)
 7     flags          uint8 (reserved, zero)
 8-15  timestamp_ns   uint64 ns epoch (net order)
16-19  sequence       uint32 monotonic (net order)
20-23  payload_len    uint32 (net order)
24-27  producer_id    uint32 from BGP router-id
28-N   payload        UTF-8 JSON (payload_len bytes)
N+0    hmac[32]       HMAC-SHA256(header || payload)

The wire header struct is packed so that no padding is inserted. The HMAC-SHA256 is computed over the concatenation of the 28-octet serialized header and the JSON payload, using a symmetric key shared between the bgpd module and the O-Node. Total wire size per observation is 28 + payload_len + 32 octets. Maximum payload size is 4096 octets. Minimum HMAC key length is 16 octets, maximum 256. The producer identifier is derived from the BGP router-id, providing a stable per-router identifier across observations.¶

This is a separate wire format from the O-Node observation formats of Section 6.3 and Section 6.4. It carries no session binding and is subject to the same qualification as v1: it is tamper-evident in transit under the shared key, and any holder of that key can produce records that verify.¶

13.3. JSON Payload Schema

All payloads share a common envelope with domain-specific fields. Every payload includes a "domain" field set to "bgp" and an "event" field identifying the observation type. A peer state change payload carries the peer name and address, peer and local AS, old and new state, router-id, and producer identifier. A best-path change payload carries the prefix, AFI, SAFI, router-id, producer identifier, and nested "old" and "new" objects each carrying peer, peer address, peer AS, nexthop, AS path, MED, local preference, and origin.¶

All string fields are escaped for control characters, backslashes, and quotes. Peer addresses are rendered to support both IPv4 and IPv6 peers. Because this payload is JSON produced by direct value insertion, it is subject to the same caution recorded in Section 6.5: it is an implementation transport format, not a canonical authenticated encoding, and the authenticated bytes are the octets as transmitted.¶

13.4. O-Node Receiver

The O-Node receives authenticated observations on a Unix domain socket. The receiver protocol is:¶

1. Read 28 octets of wire header. Validate the magic value and the version.¶
2. Extract payload_len. Reject if it exceeds the maximum payload size.¶
3. Read payload_len octets of JSON payload.¶
4. Read 32 octets of HMAC-SHA256.¶
5. Compute HMAC-SHA256 over (header || payload) using the shared key.¶
6. Compare computed against received using constant-time comparison. Reject on mismatch.¶
7. Validate that the sequence number is monotonically increasing. Flag gaps as potential observation loss.¶
8. Insert the verified observation into the chain.¶

The bgpd module performs automatic reconnection: if the O-Node socket is unavailable, observations are logged locally as a fallback and failure counters are incremented. Observations produced while the socket is unavailable are not chained; a consumer MUST NOT treat a local fallback log as chained evidence.¶

13.5. FRR VTY Configuration Commands

The module registers configuration commands under the BGP router node and show commands at the enable or view level: enabling and disabling authenticated observations, setting the O-Node socket path, and setting the HMAC key file path; plus show commands reporting state, key status, O-Node connectivity, producer identifier, and counters for records authenticated, delivered, and failed.¶

Enabling triggers HMAC key loading, if not already loaded, and initiates connection to the O-Node socket. The key-loading command validates the key immediately, rejecting keys shorter than 16 octets. Key material is zeroized on module shutdown.¶

13.6. Build and Deployment

The module can be built as a loadable shared object (recommended) or compiled directly into bgpd. As a loadable module it requires no modifications to the core FRR source. Build dependencies are OpenSSL for HMAC-SHA256. A standalone test harness validates authentication, verification, tamper detection, and sequence ordering without requiring the FRR build environment.¶

Deployment requires distributing the same HMAC key to both the FRR host and the O-Node. The key file MUST be restricted to mode 0600 and owned by the FRR process user. Note that this shared key is held by both parties; per Section 6.1, both can produce records that verify.¶

13.7. Security Properties of BGP Integration

• Authentication at collection time: the HMAC is computed inside bgpd's process space at the moment the BGP event fires, not after the fact.¶
• Observation-only: the module registers read-only hooks. It cannot modify routes, peer state, or configuration.¶
• Protocol-agnostic framing: the observation structure and authentication are identical whether the source is BGP or another domain. Only the "domain" field in the payload changes.¶
• Trust tiers at the source: tier assignment happens at collection, not at analysis time.¶
• Tamper detection: any modification to an observation between bgpd and the O-Node is caught by HMAC verification, relative to the secrecy of the shared key.¶

14.1. Live Penetration Test (6 March 2026)

An adversarial exercise was conducted against the lab environment. The agent was given a single seed address and instructed to operate without destructive actions. It obtained initial access through passive discovery within five minutes and administrative credentials on the lab firewall within twenty-five minutes, exploiting no CVEs and attempting no brute force. The root cause was a plaintext environment file containing a full credential keyring on a host the agent could read. A live tunnel to a colocation environment was reachable with those credentials.¶

The exercise validated Primitive 7. The agent did not break VIRP's cryptographic controls; it went around them by finding credentials in a plaintext file. The fix is architectural: credentials must not exist on the requesting host.¶

This result is reported as an operational finding about a specific deployment, not as a protocol property. It illustrates the boundary stated in Section 9: VIRP constrains what flows through the gate and does not constrain a party that obtains device credentials and a network path outside it.¶

16.1. Verifiable Network Audit

Traditional network audits produce reports that must be trusted on the auditor's authority. VIRP-enabled audits produce reports where every finding references an authenticated observation. The strength of that evidence is scoped by Section 6.1: a client that holds the verification key can confirm that the recorded bytes were authenticated by a holder of that key, and can detect modification of the presented chain. It does not, by itself, establish origin against a party that also holds the key. Deployments where the auditor and the client must not share a forging capability require asymmetric observation signing (Section 17.3) or a third-party anchoring arrangement (Section 17.4).¶

16.2. AI-Assisted Penetration Testing

VIRP provides chain of custody for penetration test findings. Every probe is an authenticated observation. Every access attempt is intent-gated before execution. Scope is enforced at the gate: the agent cannot interact with out-of-scope devices without a matching authorized intent. The client receives the chain alongside the report.¶

16.3. Continuous Compliance Monitoring

Baseline Memory (Primitive 5) enables continuous comparison of live device state against an authenticated baseline. Configuration drift -- a new BGP peer, a modified firewall policy, an unexpected open port -- is detected and attributed to a specific change in the chain.¶

16.4. Field Audit Appliance

A self-contained appliance running the full stack enables plug-in network discovery and audit. An operator connects the device to a network port and issues audit commands remotely; the device produces an authenticated report and is removed when complete. No software installation is required on the target network.¶

16.5. Industrial and Air-Gapped Environments

ICS and SCADA environments require audit trails for regulatory compliance and incident investigation. VIRP's authenticated observation model provides tamper-evident records of every automated interaction with control system components, supporting NERC CIP, IEC 62443, and similar frameworks. Because the gate and the chain are independent of any inference component, the same governed-automation path can be operated by scripts alone in environments where an AI component is not permitted.¶

17.2. Multi-Node Coordination

The current specification defines single O-Node operation. draft-howard-virp-01 includes a Multi-Node Coordination section defining leader election, observation synchronization, and cross-node chain verification for distributed deployments.¶

17.8. IETF Standardization

VIRP is written in RFC format and is submitted as an individual Internet-Draft. Experimental results for the BGP integration of Section 13 are archived as a citable companion artifact at [VIRP-ZENODO]. Independent implementation by a second party is the prerequisite for standards track consideration; the open-source reference implementation is available for that purpose.¶