On this page: Abstract · The problem · Design principle · Architecture · Trust tiers · Evidence model · The trust model · Assurance status · Deployment · References

Abstract

VIRP is a protocol for producing authenticated, request-linked evidence about automated infrastructure operations, under an explicit collector trust model. It places a trusted collection boundary between a requesting system (an AI agent, a script, a controller, or a human operator) and infrastructure targets. A designated collector classifies each requested operation, executes or refuses it, and authenticates the resulting record before the requester consumes it. Elevated operations require a signed human approval bound to the exact command and device.

VIRP establishes one thing: that a designated collector authenticated a particular operation record under a defined trust boundary. It does not establish that the target device was honest, uncompromised, or current, and it does not establish that every statement an AI makes about the evidence is itself evidence-backed. That boundary is stated here precisely because the protocol's value depends on it being understood, not obscured.

VIRP is an open protocol, published as an active individual Internet-Draft (draft-howard-virp-06, an individual submission carrying no IETF endorsement), with a reference implementation under Apache 2.0. The implementation is a research prototype. It requires independent evaluation before production use.

1. The problem: the reporter is not a trustworthy witness

Automated systems report on their own behavior. A script reports that the backup job succeeded. A monitoring agent reports that the interface is up. An AI agent reports the output of a command it says it ran. In each case, the component making the claim is also the authority the operator consults to check the claim.

This was tolerable when automation was deterministic and its failure modes were crashes and error codes. It stops being tolerable when the reporting component can produce plausible falsehoods. A language model generates statistically likely text; when it lacks real data, the most likely completion for “what is the status of this router” is a healthy status, correctly formatted. The project's origin incident was exactly this: an agent produced fabricated command output, indistinguishable in form from real output, for commands it never ran. The details are documented in the public walkthrough.

The failure class is broader than AI. A buggy script that reports success on a failed job, a compromised monitoring host, and an operator transcribing the wrong output into a change ticket all present the same structural problem: the record of what happened is produced by, or passes through, a party with no independent accountability for its accuracy.

Prompt engineering, policies, and validation layers reduce the frequency of the AI-specific version of this problem. They do not change its structure, because they ask the untrusted component to police itself. VIRP's position is that the fix must be architectural.

2. The design principle

The whole protocol follows from a single principle:

The component making a claim must not be the sole authority for verifying that claim.

Execution evidence has to come from a trust boundary the requesting system cannot control. In VIRP, the requesting system never touches infrastructure directly. A separate process, the collector (the O-Node in protocol terms), holds the device credentials, executes or refuses each operation, and authenticates the resulting record with key material the requester is not provisioned with. The requester can read and reason about the evidence. It cannot manufacture evidence that verifies.

Everything else in the architecture is engineering in service of that principle, and every limitation in Section 7 is a place where the engineering has not yet caught up to it.

3. Architecture

3.1 Roles

Requesting system. Any originator of operations: an AI agent, a script, an orchestration platform, or a human using a submission client. VIRP is deliberately indifferent to which; the protocol behaves identically with no AI in the loop.

Collector (O-Node). A process-separated daemon that holds device credentials and the observation key. It receives requested operations, classifies them, executes the allowed ones against configured targets over the appropriate transport (SSH for network devices, HTTP APIs for platforms that expose them), refuses the rest, and emits an authenticated record either way. The collector is deployed separately from the requesting system. It is the concentrated point of trust in the design, deliberately, in the same sense that an HSM or a credential vault concentrates trust.

Targets. The infrastructure the collector communicates with: routers, firewalls, hypervisors, backup platforms, hosts. Targets are outside the trust boundary. VIRP records what the collector received from a configured target; it does not certify that the target told the truth.

Approvers. Humans (or systems acting for them) enrolled in an approver registry, holding private signing keys the collector never possesses. Approvers authorize elevated operations.

Verifiers. Components that check records after the fact. Because observation authentication is currently symmetric, verifiers of observations and the chain sit inside the trusted key boundary (Section 6). Approval signatures can be verified with public keys alone.

3.2 Operation lifecycle

Every operation follows the same path:

  1. Request. The requesting system submits a named operation for a named device. For API-backed targets, requests are typed operation identifiers (for example, a read of a backup platform's version), not raw URLs or methods; the driver resolves what a typed operation means, so a requester cannot smuggle in a request the gate has not classified.
  2. Classification. The tier gate classifies the operation against a per-driver table (Section 4). Classification is deny-by-default: an operation the classifier does not recognize escalates to blocked rather than slipping through.
  3. Decision. The gate allows, flags, or blocks. The decision itself is recorded; an allowed operation carries evidence that an explicit classify-and-decide step happened, not merely that nothing stopped it.
  4. Execution or refusal. Allowed operations execute against the target. Blocked operations never touch the target, and the refusal is emitted as an authenticated, typed error record, distinct at the type level from a successful observation, so a rejection cannot later be re-presented as a successful read without failing verification.
  5. Record. The collector authenticates the operation record, binding it to the session, the device, and the exact command, and appends it to the evidence chain (Section 5.2). The record preserves the request the collector actually issued alongside the response, so the two cannot be silently re-paired afterward.

3.3 Elevated operations: propose, approve, apply

Operations classified as configuration changes are not merely blocked; the block files a proposal. The lifecycle is:

  1. Propose. The blocked request creates a proposal record carrying the exact command and target device, and the rejection returned to the requester includes the proposal identifier.
  2. Approve. An enrolled approver reviews the proposal and signs an approval with a private key held outside the collector. The approval is bound to the proposal's command hash and device, is valid for a limited time window (300 seconds in the reference implementation), and is consumable exactly once. The collector holds only public keys for approvers and refuses to load approval secret keys.
  3. Apply. The approved operation executes, and the outcome, success or failure, is recorded and linked to the proposal and approval. A failed execution still consumes the approval; re-running requires a fresh cycle. Reuse, expiry, and missing approvals are each refused with distinct typed errors, and the refusals are themselves authenticated records.

The proposal, the approval, and the outcome land in the chain as linked entries, so the full history of an elevated change, who asked, who authorized, what happened, is reconstructable from evidence rather than from anyone's account of it.

4. Trust tiers

  • GREEN. Read-only. Executes automatically; the observation is authenticated at collection.
  • YELLOW. Diagnostic operations with side effects worth an operator's attention. Executes and flags.
  • RED. Configuration changes. Blocked pending the signed approval flow above.
  • BLACK. Destructive operations: factory resets, key deletion, disabling the observation channel. BLACK has no message type in the protocol. There is nothing to approve because there is no way to say it.

Two honest qualifications. First, classification tables are per-driver and finite; the safety property is that the classifier fails closed, escalating unrecognized commands to blocked, not that every conceivable destructive operation has been enumerated. BLACK is a design constraint that removes the paths the project knows how to remove, not a guarantee that nothing destructive can ever be mis-tiered. Second, not every integrated device class sits behind the full tiered gate yet: host and SIEM integrations currently run in a monitored, read-only mode.

5. The evidence model

5.1 Observation records

Each record binds the response material to the session, the target device identity, and a hash of the exact command, and carries a sequence number checked against a persistent per-session high-water store so a genuine old record cannot be replayed as a new one. Records are typed: a successful observation and a gate rejection carry different type values, and error paths emit typed error records with their true tier rather than defaulting into the success path. Authentication is HMAC-SHA256 with a key the collector holds and the requester does not.

The terminology on this point is deliberate. Observation records are authenticated, not signed. HMAC is a symmetric mechanism: any holder of the key can produce a valid record. The word “signed” is reserved, throughout the project, for Ed25519 approval and federation material, where a public key can verify what only a private key holder could have produced. Section 6 states what the symmetric choice means for the trust model.

5.2 The chain

Every observation and every rejection is appended to a keyed, hash-linked chain: each entry carries an authenticated digest of the previous entry. An actor without the chain key cannot alter a middle entry, remove one, or insert one and produce a replacement chain that still verifies; unauthorized modification of the records presented to a verifier is detectable.

The chain is tamper-evident within the collector trust boundary, and the project does not describe it as append-only or immutable. A holder of the chain key can rewrite history and recompute the authentication values, and an older valid prefix can be presented as current. Detecting those attacks requires trusted checkpoints or external anchoring, publishing chain heads to an independent witness. That work is designed, not done.

5.3 Accountability at the AI boundary

For deployments with an AI in the loop, a claim-verification layer checks the agent's statements against the evidence: device references in agent output without a matching authenticated record are flagged as unverified. This is an accountability mechanism, not a completeness guarantee. It relies in part on the agent declaring which statements need backing, which means the untrusted model participates in enumerating what gets checked. VIRP's honest boundary is that it authenticates evidence; controlling what unverified prose reaches a human is a separate layer's job.

6. The trust model, stated exactly

What VIRP establishes. A designated collector authenticated this operation record: this operation was requested, it was classified and allowed or refused, this is the request the collector issued, this is the material it received or the error it encountered, and the record has not been modified since, within the boundary below.

What VIRP does not establish. That the target device was honest, uncompromised, or reporting current rather than cached state. That the response corresponds in every case to the intended command: the project's own security documentation records a live instance where a collector authenticated output that did not correspond to the command it was labeled with, and treats the problem class as wider than the closed cases until shown otherwise. That every AI statement about the evidence is itself evidence-backed.

The boundary. Security depends on the isolation of the collector process, its host, and its keys. Because observation and chain authentication are symmetric, every key holder must be treated as trusted, and components that verify observations either hold the key or delegate to a trusted component that does. There is no security against a compromised collector: a compromised collector can fabricate records and rewrite the chain, and the protocol as implemented today will not detect it. Hardening the collector, hardware-backed keys, and external anchoring are the open work items that shrink this exposure; they do not yet exist in the reference implementation.

A protocol document that hid this paragraph would be describing a different and better system than the one that exists. The claim VIRP actually supports is narrower than “cryptographically verified reality,” and the project has deliberately stopped using that phrase.

7. Assurance status

Demonstrated live. On production-class network hardware: authenticated reads; blocked configuration changes with authenticated, typed rejections carrying proposal identifiers; an approved change executed under a signed Ed25519 approval; refusal of approval reuse, expiry, and absence, each with a distinct typed error; and the linked proposal-approval-outcome triple reconstructable from the chain. Transcripts and hashes are pinned in the repository.

Independently reviewed. An independent network engineer exercised the implementation against production Cisco hardware; the findings filed during that review were fixed with regression tests. This was a technical review, not an independent security audit or production evaluation.

Formally verified, with scope stated exactly. ProVerif results cover the current observation path: secrecy of the master observation key, secrecy of derived session keys, and injective agreement (every accepted observation corresponds to exactly one authentication by the collector). The results hold under a documented trace restriction encoding the replay store's contract, because the symbolic model cannot natively represent the mutable high-water counter; the counter's behavior is demonstrated separately by negative tests. Earlier protocol versions are not covered, and no Tamarin model exists. This section is the only place this document uses “proof” in its formal sense.

Implemented but not battle-tested. Baseline deviation detection and cross-tenant federation are built and unit-tested with no production hours; no multi-tenant federation deployment exists. Client-side verification currently differs in depth from the daemon's while a consumer upgrade is pending.

Not established. Everything in Section 6's second and third paragraphs, and independent production evaluation of any part of the system.

8. Deployment characteristics

No AI required. The gate does not know or care what submits the command. Scripts, controllers, and human operators produce the same authenticated records through the same lifecycle. Environments that cannot or will not put an AI on their networks can run VIRP purely as a governed-automation evidence layer: what was requested, what the collector attempted, what came back, what was approved, and that the presented records were not modified within the stated boundary.

Regulated and high-assurance environments. That no-AI property is why audited environments are a natural fit: the protocol produces examiner-facing evidence of change control without requiring trust in any reporting component's self-account. Offline verification is possible for an authorized verifier holding the required verification material, with the symmetric-key consequence stated in Section 6. OT and air-gapped environments are a promising fit for the same reasons, with a clear caveat: the read-only evidence path is the most exercised capability, and write governance on live OT equipment is design-complete but not demonstrated with any client.

Rollout. Devices can run in a log-only shadow mode during adoption, recording what the gate would have decided before enforcement is switched on, and enforcement is configurable per device class.

9. Direction

The near-term work is the honest closure of the gaps this document names: external anchoring of chain checkpoints, hardware-backed keys, complete operation-to-response correlation, client-side verification parity, and full gating for the remaining device classes, alongside the draft-06 specification revision, submitted August 2026, which narrows the spec's claims to the language used here and reconciles it with what the code implements.

The longer bet is that the pattern generalizes. The gate recently governed its first non-network domain, a backup platform, through the same machinery unchanged, using typed operations rather than raw commands. The project's view is that “produce authenticated evidence of what an automated system requested, what a trusted collector attempted, and what came back” is a primitive the field will need broadly as automation arrives faster than accountability for it, and that the layer should exist before everyone needs it.

10. References and status

  • Specification: draft-howard-virp-06, an active individual Internet-Draft. Individual submission; not a working-group document; no IETF endorsement. See the Specification page.
  • Reference implementation, formal-verification artifacts, live-demonstration transcripts, and the open findings list: the public repository, Apache 2.0.
  • Current security status, including what has and has not been established: the security page, which controls over this document where assurance status is concerned.
  • The origin incident and a live protocol walkthrough with real session output: the walkthrough.

VIRP is an open protocol developed by Third Level IT, LLC. Hostile review is invited: if you can break the protocol or find where this document overstates it, that is exactly the contact the project is looking for.