Open Source AI Trust Infrastructure

VIRP — Verified Infrastructure Response Protocol Nothing more dangerous than an AI
in production we think can't lie.

VIRP is the BGP of AI trust — an open protocol anyone can implement. Built by Third Level IT. Apache 2.0.

VIRP on GitHub
virp — live session
ops>
how is the network looking?
Scanning 12 devices across 3 vendors...
FortiGate-200G
✓ HMAC verified 606ms
Firmware v7.6.5 | CPU 4% | 2,841 active sessions
R1–R35 (Cisco IOS, BGP across AS 100–700)
✓ 10/10 HMAC verified avg 340ms
47 BGP neighbors established | 0 down | 312 prefixes
Wazuh SIEM
✓ HMAC verified 890ms
0 critical alerts | 3 medium (reviewed) | 142 low
ASSESSMENT: Network healthy. All observations cryptographically
verified. No fabricated data in this response.
VIRP Framework

Seven Trust Primitives
for Agentic Operations

Every AI agent operating on real infrastructure needs seven things to be trustworthy. We built all seven. Installed, tested, running in production. Nobody else has started.

Observation ✓ Authorization ✓ Baseline ✓ Intent ✓ Outcome ✓ Chain ✓ Federation ✓
01 Done

Verified Observation

Solves: AI fabrication of device telemetry

The AI never touches the device. A separate C process collects raw output via SSH, signs it with HMAC-SHA256 at the point of collection, and serves pre-signed data to the AI layer. The signing key exists only in O-Node process memory. Fabricated data has no valid signature.

The AI is a consumer of signed facts, not the collector. 6,800 lines of C. 87 tests passing.
02 Done

Tiered Authorization

Solves: Uncontrolled AI action on infrastructure

Every command is classified at the O-Node level — not by the AI. The AI has full admin credentials to every device. It structurally cannot misuse them. BLACK tier commands have no message type, no approval path, no override. You cannot bypass a rule that was never written.

GreenAuto-execute
YellowOne approval
Redm-of-n approval
BlackNo code path
03 Done

Verified Intent

Solves: Unstructured, unauditable change proposals

Every proposed change becomes a formal, signed object — referencing specific observations by HMAC, including impact assessment and a pre-planned rollback. No verified evidence, no proposal accepted. Stale evidence is rejected. Every change is traceable to the signed observations that triggered it.

Installed and tested. Every proposal references signed observations by HMAC.
04 Done

Verified Outcome

Solves: Open-loop operations with no post-change verification

After every approved change, the system automatically re-observes affected devices and compares before/after state. Both signed. If the outcome doesn't match the intent, the pre-planned rollback triggers automatically. Observe → Propose → Approve → Execute → Verify. Every step signed.

Installed and tested. Automatic before/after verification on every change.
05 Done

Baseline Memory

Solves: Alert fatigue and reactive-only monitoring

The AI learns what "normal" looks like from accumulated signed observations over time. No thresholds. No rules. Verified history. The baseline is built from HMAC-signed data — the AI cannot hallucinate what normal looks like. Silence means health. A message means something actually changed.

Live. Detecting BGP and interface deviations from signed baselines across 35 devices.
06 Done

Trust Chain

Solves: Fragmented audit trails and untraceable change history

Every action produces a signed artifact referencing the previous by HMAC. Observation → Intent → Approval → Execution → Outcome. Tampering with any link breaks the chain. Blockchain-grade integrity without blockchain. No consensus. No tokens. Just signed artifacts in sequence.

Installed and tested. Full HMAC chain from observation through outcome.
07 Done

Trust Federation

Solves: Single-tenant trust boundaries

Ed25519 asymmetric signatures for multi-tenant deployments. Each O-Node holds its own private key. Verifiers hold only public keys. An MSP manages 15 clients — verifying everything, forging nothing. Compromise of one node doesn't compromise others. Multi-tenant AI operations with cryptographic tenant isolation.

Installed and tested. Ed25519 multi-tenant isolation with per-node keys.

The protocol specification and reference implementation are open source. All seven trust primitives — installed, tested, running.

How it works

Three layers. One source of truth.

The AI never talks to your devices directly. A hardened observation node sits between the AI and your infrastructure, signing everything it collects.

01

You ask a question

Natural language. "How's the network looking?" or "Why is R6 dropping BGP peers?" No CLI knowledge needed.

02

The O-Node collects facts

A hardened C daemon connects to your devices via SSH and API, collects raw output, and signs every observation with HMAC-SHA256 at the point of collection.

03

AI reasons, you verify

The AI interprets signed observations and presents findings. Every data point carries a cryptographic signature you can verify. No signature, no assertion.

Security architecture

The AI can read.
It cannot fabricate.

Every observation is signed at the point of collection — before the AI sees it. The AI receives facts. It cannot produce them.
Channel-separated cryptographic keys mean the system that collects data and the system that reasons about it are structurally isolated.
Four trust tiers govern what's allowed. Read-only monitoring runs automatically. Configuration changes require human approval. Destructive operations don't exist in the wire format.
The verification badge in the UI isn't cosmetic. It represents a real HMAC-SHA256 signature computed over real device output by a process the AI cannot access.
SSH
Your infrastructure
Routers, firewalls, servers, SIEM
↓ signed
O
O-Node (Hardened C daemon)
Collects output → HMAC signs → serves
↓ signed
AI
AI reasoning layer
Reads signed data — cannot forge signatures
TRUST TIERS
GREEN — auto-execute YELLOW — flag operator RED — human required BLACK — doesn't exist
Open Source

VIRP: Verified Infrastructure Response Protocol

We built VIRP to solve a problem no one else was addressing: AI systems fabricating infrastructure data and acting on it. It's the BGP of AI trust — an open protocol anyone can implement. Apache 2.0.

Two isolated channels

Observations and intent travel on cryptographically separated channels. The Observation Channel uses O-Keys to sign raw device output at the point of collection. The Intent Channel uses R-Keys for AI reasoning and proposals. The AI never holds the keys that certify facts.

Signatures before AI

HMAC-SHA256 signatures are computed by a hardened C daemon (the O-Node) the moment data is collected from a device. The AI receives pre-signed observations. It cannot retroactively sign its own output or forge a measurement it never made.

Four structural trust tiers

GREEN operations (monitoring) auto-execute. YELLOW (diagnostics) flag an operator. RED (configuration changes) require human sign-off. BLACK operations like factory resets are structurally absent — there is no message type for them in the protocol.

Evidence-based proposals

Every remediation proposal must reference signed observations. The protocol rejects proposals that cite unverified data. No signature chain, no action — enforced at the wire format level, not by policy.

Protocol Architecture

Two-Channel Trust Architecture

Observation Channel collects and signs. Intent Channel proposes and verifies. The AI never touches the device directly.

Observation Channel
🖧
Physical Device
Router • Firewall • Switch
Cisco FortiGate Palo Alto
🛡️
O-Node Collector
Separate process • Isolated key space
SSH → collect → sign → emit
🔐
HMAC-SHA256 Signing
Cryptographic boundary seal
device_id + timestamp + output
→ channel-bound HMAC signature
AI cannot forge or modify
🔒 HMAC-SHA256
Signed observation crosses trust boundary
🔒 HMAC-SHA256
Intent Channel
🧠
AI Reasoning Layer
Reasons about signed facts only
✓ Verified data → full analysis
✗ Unverified → refuses conclusions
⚖️
Trust Tier Gate
Structural authority limits
GREEN auto-execute (read only)
YELLOW one human approves
RED multiple humans approve
BLACK no code path exists
👤
Human Approval
Required for YELLOW and above
✓ Approve
✗ Reject
Verified Outcome
Post-change observation proves result
before: signed state A
action: signed intent executed
after: signed state B
proof: A → B cryptographically linked
🔄 Outcome feeds back into Baseline Memory → continuous trust loop
Observation Channel
Collect & sign device data
Trust Boundary
HMAC-verified handoff
Intent Channel
Propose, approve & execute
VIRP — draft-howard-virp-01 — Apache 2.0
Open source on GitHub

VIRP is Apache 2.0-licensed. The protocol spec, O-Node reference implementation, and full test suite (27 tests covering structural guarantees) are available for anyone building AI systems that interact with real infrastructure.

View on GitHub
FAQ

Questions you're probably asking.

What do you mean the AI "fabricates" data?

When AI systems have command execution authority over infrastructure, they sometimes generate plausible-looking device output that never came from an actual device. We documented cases where the AI fabricated firewall policies with valid UUIDs, reported security threats from documentation IP addresses, and proposed routing changes based on invented OSPF data. All labeled "Confidence: HIGH." This isn't a theoretical risk — it happened to us in production.

How is the verification different from just signing API responses?

Standard HMAC signing protects the transport — it proves data wasn't tampered with in transit. VIRP signs at the observation point, before the AI sees the data. The AI cannot bypass the signature by generating output in its own response because it doesn't hold the signing key. The key only exists in a hardened C process the AI has no access to.

What happens if the AI can't reach a device?

It says so. There's no unsigned fallback path. If the observation node can't connect to a device, the response is a verified "connection failed" message, not an AI-generated guess about what the device might be doing. No data means no assertion.

Can the AI make configuration changes to my network?

Only with explicit human approval. Read-only monitoring commands (GREEN tier) execute automatically. Diagnostic commands (YELLOW) flag an operator. Configuration changes (RED) require human authorization before execution. Destructive operations (BLACK) — factory resets, key deletion, disabling the observation channel — are structurally absent from the protocol. There is no message type for them.

What does the demo environment look like?

A live network lab with 35 Cisco routers running BGP across 13 autonomous systems, a FortiGate firewall, a Proxmox hypervisor, Windows domain controllers, and a Wazuh SIEM. VIRP running against all of it. Real devices, real traffic, real observations. Reach out and we'll walk you through it.

Who is this built for?

Anyone running AI agents against real infrastructure. The MSP managing 15 client networks who needs cryptographic proof their AI isn't fabricating data. The security team that wants verified facts, not AI opinions. The infrastructure team that needs AI-powered monitoring they can actually trust. And anyone who wants to implement VIRP in their own stack — the protocol is open, the spec is public, the code is Apache 2.0.

Get in touch

Want to see it on a live network?

If you'd like a demo, call or email me. I'll walk you through the platform on real infrastructure.

Nate Howard
Third Level IT LLC
nhoward@thirdlevelit.com (313) 765-0039