Know which infrastructure actions left real evidence.

The specification defines VIRP. The implementation demonstrates it. The security page states what has and has not been established.

Run it yourself

Clone, install the build dependencies, run. No hardware, no credentials, no network access. The demo runs the reference collector against a deterministic simulated target and observes nine security behaviors end to end. On an independent verifier machine with the dependencies already installed, clone to pass took 15 seconds; a first run that also installs dependencies and compiles takes about two minutes. The bundle it produced is published and browsable.

# clone and run (Debian/Ubuntu)
git clone https://github.com/nhowardtli/virp
cd virp
sudo apt install -y build-essential libssl-dev libsodium-dev libsqlite3-dev libssh2-1-dev libcurl4-openssl-dev libjson-c-dev
./demo/run.sh

Containerized alternative, if your Docker ships the compose plugin (not all apt-packaged builds do): docker compose -f demo/docker-compose.yml run --rm demo. If that errors, the native path above is the reliable one.

New to this? Read what each step means — a plain-language companion to the run.

What it observes, each one asserted rather than narrated:

1. A GREEN operation executes.
2. Its record verifies against the collector's key.
3. Modifying that record causes verification to fail (and the intact one still passes).
4. A RED operation is blocked, and a proposal is filed.
5. An Ed25519 approval is signed with a key the collector does not hold.
6. The exact approved operation executes, on the collector's own verified-approval linkage.
7. Reusing that approval is refused.
8. An unrecognized operation fails closed.
9. Every session in the evidence chain links from its own genesis, and the approval session carries the proposal, approval, and outcome entries this run produced.

VIRP DEMO PASSED
9/9 security behaviors observed
Evidence bundle: ./demo/output/session-<timestamp>

The run writes an evidence bundle: the per-step records, the collector log, the chain database, and a summary stamped with the commit it was produced from. Replay the chain afterwards with ./build/virp-tool chain tail --db <bundle>/run/chain.db.

How it fits together

 requesting system             designated collector           configured targets
 (AI, script, or operator)     (O-Node)                       (routers, firewalls,
                                                               hypervisors, backup)
      |  typed operation       +-----------------------+
      +---------------------->|  tier gate: classify,  |  SSH / API
      |                        |  deny by default       +--------------------->
      |  authenticated,        |  execute or refuse     |
      |<----------------------+  authenticate record   |<---------------------
      |  request-linked        +-----------+-----------+   response
      |  record (HMAC)                     |  append
      |                                    v
      |  RED changes need a     +-----------------------+
      |  signed approval        |  tamper-evident        |
      |  (Ed25519, held by      |  evidence chain        |
      |  human approvers)       +-----------------------+
        

• The requester holds no device credentials and no observation key.
• Approvers hold separate Ed25519 private keys the collector never possesses.
• The O-Node is the trusted component; collector compromise is outside the present guarantee.
• The target response is authenticated as received, not certified as truthful.

What you can use it for

• Evidence that the collector authenticated a recorded read. An authenticated, request-linked record establishes that the collector authenticated this recorded command-and-response association for this device.
• Evidence that a proposed change was blocked, or specifically approved. The typed rejection, the proposal, the Ed25519 approval, and the outcome are linked entries in the chain.
• Reconstruct what automation requested, attempted, and received. The chain replays the full history without trusting the requester's account of its own behavior.

The safety model, in two commands

A read runs. A change is blocked.

AUTHENTICATED here means the record's authentication tag checked out against the collector's key. It does not mean the content has been verified as true.

• GREEN: read-only. Auto-executes, authenticated.
• YELLOW: diagnostic. Flags an operator.
• RED: config change. Signed human approval.
• BLACK: destructive. No message type, by design.

BLACK operations have no message type, so there is nothing to approve: factory resets, key deletion, disabling the observation channel. The protocol gives them no way to be said, and the classifier that assigns tiers fails closed; a command it doesn't recognize escalates to blocked rather than slipping through. Call that what it is: a design property that removes the paths we know how to remove, not a guarantee that nothing destructive can ever be mis-tiered.

Not only for AI

Nothing above requires a model. A shell script, a runbook, an engineer at a terminal: each goes through the same gate and leaves the same authenticated record. Strip the AI away and what remains is what VIRP actually provides: authenticated evidence of what was requested, attempted, and recorded. Not “the change was authorized, trust us,” but a record you can check. AI safety is one application of that, not the definition.

Because the protocol runs with no AI in the loop, OT and air-gapped environments are a promising fit. That positioning, including offline verification behavior and its current limits, lives on the Potential applications page.

Questions you're probably asking

How is this different from just signing API responses?

Signing an API response can authenticate a response object, but it does not by itself establish who executed the underlying operation, how it was classified, whether it was refused, or how the response was linked to the request. VIRP defines that collection, authorization, and evidence boundary as part of the protocol. The requesting agent does not hold the observation key. The key remains inside the trusted collection-and-verification boundary; because it is symmetric, every holder must be treated as trusted.

Can the AI change my network?

Only through the gate. GREEN reads auto-execute. YELLOW flags an operator. RED requires a signed human approval bound to the exact command and device, valid once, for 300 seconds. BLACK has no message type at all. Devices can also run in a log-only shadow mode during rollout, and host/SIEM integrations currently run monitored rather than fully gated; see the limits noted above.

What happens when a device is unreachable?

You get a verified “connection failed”: an authenticated error from the O-Node, not an AI guess about what the device might be doing. There is no unauthenticated fallback path. No data means no assertion.

Who is this for?

First, infrastructure automation and agent developers who want their tools to emit evidence instead of assertions. Second, security researchers and protocol reviewers; the spec is public, the findings list is honest, and hostile questions are welcome. Third, operators evaluating authenticated automation evidence, including environments that run no AI at all (see potential applications). The reference implementation is Apache 2.0.

Roadmap

Four milestones, each with a completion test, tracked in the open repository:

• External chain anchoring. Done when chain heads are published to an independent witness and an older-prefix replay is detected by the adversarial test suite.
• Verification parity. Done when the client-side verifier applies the same checks as the daemon and passes the same test battery.
• Full tier gating. Done when host and SIEM integrations run behind tiered classification instead of monitored, read-only mode.
• Operation-to-response correlation. Done when the open correlation finding class is closed, with a regression test pinning each case.

Build on it. Break it. Tell us.

VIRP is at the IETF as draft-howard-virp-06 and Apache 2.0 licensed. It was reviewed by an independent network engineer against production Cisco hardware; this was not an independent security audit or production evaluation. Pick your level of commitment:

• Run the demo: one command, no hardware; nine security behaviors observed against a simulated target.
• Interrogate the evidence: tamper with a record in your browser and watch verification fail, then read the real-session walkthrough and the pinned transcripts in the repository.
• Deploy in a lab: the reference O-Node, drivers, and deployment unit are in the repo; start with a simulated or lab target, never production.
• Report a vulnerability: disclosure instructions are on the security page.
• Request an evaluation or contribute a driver: hostile review is the most useful contact of all.