VOLT: A Verifiable Operations Ledger for the AI Agent Era

In February 2026, NIST launched its AI Agent Standards Initiative, calling for verifiable and accountable AI agent operations as a foundational requirement for trustworthy autonomous systems. The timing was not coincidental. Gravitee's State of AI Agent Security 2026 report found that 88% of organisations experienced AI-related security incidents in the past year, yet most lacked forensic evidence of what actually happened.

The agents acted. The logs said... something. But nobody could prove whether those logs were complete, unmodified, or even truthful.

This is the evidence gap, and it is growing wider with every AI agent deployed into production.

VOLT – the Verifiable Operations Ledger and Trace – is an open protocol designed to close that gap. It produces tamper-evident, portable, independently verifiable traces of what happened during an AI agent run, without requiring a blockchain, without adding meaningful latency, and without turning a system into a logging swamp.

The problem with audit logs

Traditional audit logs are a database table. Someone writes a row that says "User X did Y at time Z." This approach has served us reasonably well for human-operated systems, where the principal actor is a person with a login, and the actions are infrequent enough that a relational table can capture them.

AI agents break this model in three ways.

First, volume. A single agent run might execute dozens of tool calls, policy evaluations, and inter-agent messages in seconds. Traditional audit tables were not designed for this event density.

Second, mutability. A conventional log stored in a database can be edited. An administrator with database access can update a row, delete a record, or insert a fabricated entry. There is no inherent mechanism to detect these modifications after the fact. For human-scale operations with segregation of duties, this risk was manageable. For autonomous agents making consequential decisions at machine speed, it is not.

Third, portability. When a SOC 2 Type II auditor asks for "evidence of controls operating effectively over time," you need to hand them something they can independently examine. A database query result is not evidence – it is a claim. The auditor has no way to verify that the rows were not modified between the time they were written and the time they were exported.

Learning from Certificate Transparency

Google's Certificate Transparency (CT) project solved an analogous problem for TLS certificates. Before CT, a certificate authority could issue a fraudulent certificate and nobody would know until the damage was done. CT introduced append-only Merkle tree logs that provide cryptographic proof of certificate issuance, allowing anyone to verify that a certificate was legitimately issued without relying on trust in any single authority.

The key insight from CT is that you do not need a blockchain to achieve tamper evidence. You need three things: cryptographic hashing to detect modifications, chaining to detect deletions and insertions, and independent verifiability so that a third party can confirm integrity without trusting the system that produced the log.

VOLT follows this philosophy directly. Every event is hashed. Every event includes the hash of the previous event, forming an append-only chain. And the entire chain can be exported as a portable Evidence Bundle that anyone can verify with a standalone tool. No distributed consensus required. Just cryptography applied where it matters.

How VOLT works

VOLT's architecture is built around three operations: Record, Bundle, and Verify.

Record: hash-chained events

Every meaningful action in an AI agent run becomes a VOLT event. An event might represent a message received, a policy decision evaluated, a tool call requested, a human approval granted, or a file written. Each event contains a standard set of fields.

Two fields make this more than a log entry: prev_hash and hash. The hash field is the SHA-256 digest of the event's canonical JSON representation (with the hash field itself removed before hashing). The prev_hash field contains the hash of the immediately preceding event. The first event – the genesis event – uses 64 zeros as its prev_hash, establishing the chain's anchor point.

Simplified blog example. The full specification includes additional fields such as attachment_refs for tool output references.

Digital signatures with Ed25519

VOLT supports optional Ed25519 digital signatures over event chains. Ed25519 was chosen for specific technical reasons: it is fast (tens of thousands of signatures per second on commodity hardware), deterministic (the same message always produces the same signature, eliminating a class of implementation bugs), and provides 128-bit security – well beyond what is computationally feasible to break with current or near-term hardware.

Signatures in VOLT operate at the bundle level. A signer attests to the run ID, bundle ID, first event hash, last event hash, and event count. This means a single compact signature covers the integrity of the entire chain. If any event in the chain is modified, the last event hash changes, and the signature becomes invalid.

For organisations that need external timestamp verification, the VOLT roadmap includes support for RFC 3161 trusted timestamps, planned for v0.2. RFC 3161 is an internet standard for trusted timestamping used in legal and forensic contexts – it works like a digital notary stamp. A Timestamp Authority (TSA) such as freetsa.org signs a hash with a certified time, providing independent third-party proof that the data existed at a specific moment.

Bundle: portable evidence packages

At the end of a run (or periodically during long-running workflows), VOLT produces an Evidence Bundle – a self-contained package that includes everything needed for independent verification.

The manifest ties everything together: it records the hash of the first event, the hash of the last event, and the total event count. A verifier can confirm these endpoints match the actual event file without reading every event first, providing a fast integrity check before deep verification.

Attachments – tool outputs, generated artefacts, command results – are stored by content hash. If an event references an attachment with hash ab12...ff, the verifier can recompute the SHA-256 of the stored file and confirm it matches. Substituting a fake tool output will fail this check.

Verify: independent confirmation

VOLT's verification algorithm is deterministic and runs without any connection to the system that produced the bundle. A verifier walks the event chain in sequence, recomputing each hash and confirming each prev_hash link. It then validates the manifest's endpoint hashes and event count, checks attachment integrity, and verifies any signatures present.

The output is a structured PASS/FAIL report with specific failure codes. This is designed for automation. A CI pipeline can require VOLT verification PASS as a gate before promoting a deployment. An auditor can run the verifier against exported bundles without needing access to the production system. A compliance team can store bundles in cold storage and verify them years later – the maths does not expire.

Conformance levels

VOLT defines three conformance levels. An implementation may support any combination, but each level builds on the capabilities of the previous one.

Why not blockchain?

The question comes up frequently enough that it deserves a direct answer. Blockchain-based audit systems have been proposed in academic papers and some commercial products. They provide strong tamper evidence through distributed consensus – but at costs that are disproportionate for single-organisation evidence trails.

A blockchain solves the problem of trust between mutually distrusting parties who share no common infrastructure. That is not the problem VOLT addresses. VOLT solves the problem of proving, after the fact, that a recorded sequence of events has not been altered – within an organisation or between an organisation and its auditors.

Hash chaining with optional Ed25519 signatures provides equivalent tamper evidence for this use case, at a fraction of the computational and operational cost. A VOLT event is recorded in microseconds. A blockchain transaction takes seconds to minutes and requires network infrastructure, gas payments, or a permissioned chain setup.

Privacy by default

An evidence system that leaks secrets is worse than no evidence system at all. VOLT enforces privacy at the protocol level with a simple rule: events MUST NOT contain secrets.

Instead of logging raw tool inputs (which might include API keys, database credentials, or personal data), VOLT events record metadata: the tool name, the operation type, a duration, a status code, and content-addressed hashes that point to separately stored (and access-controlled) attachments. Sensitive inputs are replaced with explicit redaction markers like "inputs_redacted": true.

This is not an afterthought – it is a normative constraint in the VOLT specification. Implementations that record secrets in event payloads are non-conformant. The protocol's threat model explicitly identifies "privacy leakage via evidence bundles" as a threat and prescribes mitigations including secret scanning before event writes, role-based access to bundle viewers, and configurable retention with automatic deletion.

VOLT in the Quox architecture

VOLT is one of four protocols in the Quox trust stack:

• AEE (Agent Envelope Exchange) defines how agents communicate – the message format, correlation IDs, and envelope structure for agent-to-agent and human-to-agent interactions.
• AOCL (Agent Orchestration Control Layers) is a control-layer protocol for AI agent orchestration that produces observability as a first-class output – policy decisions, permissions, human-in-the-loop gates, and escalation rules.
• VOLT defines how you prove what happened – evidence recording, integrity guarantees, and exportable verification.
• WARD (Write-once Append-only Receipt Digests) adds content-free hash-chain witnessing on top of VOLT, providing an independent proof layer that survives even if the primary evidence store is compromised.

If AEE is how agents talk, and AOCL is how they are controlled and observed, then VOLT is how you prove what actually occurred.

In the Quox codebase, VOLT is implemented across a set of purpose-built modules backed by 156 tests. The core modules include:

The bridge module deserves particular attention. It operates as a fire-and-forget observer: it records events but never blocks the main execution path. If the bridge encounters an error, it logs the failure and continues – bridge errors must never disrupt the AEE transport pipeline.

This is a deliberate architectural choice. An evidence system that causes production outages will be disabled by the first on-call engineer who encounters it at 3 AM.

Certification tiers

As VOLT matures, a tiered certification programme is being designed to give organisations and their auditors a clear framework for assessing the strength of their evidence trails. These tiers are planned for VOLT v1.0 and may evolve as the specification matures.

The progression mirrors how TLS certificate validation evolved: from self-signed (you trust the issuer because you choose to) through domain-validated and organisation-validated certificates to extended validation with third-party attestation. Each tier adds a layer of independent assurance.

Alignment with emerging standards

VOLT was not designed in isolation. Its architecture directly addresses requirements from several active standards and regulatory initiatives.

NIST AI Risk Management Framework calls for organisations to document AI system behaviour, maintain audit trails, and provide mechanisms for independent review. VOLT's Evidence Bundles are purpose-built for this: they are portable, self-describing, and verifiable without access to the producing system.

NIST AI Agent Standards Initiative (launched 17 February 2026) focuses on interoperability, open-source protocols, and security/identity research for AI agents. The initiative's emphasis on verifiable and accountable agent operations maps to VOLT's core design goals.

Its request for information asks how organisations can demonstrate that autonomous AI agents operated within their defined parameters. VOLT's chain-of-custody model – where every policy evaluation, human approval, and tool execution is recorded as a verifiable event – provides a concrete answer.

SOC 2 Type II audits require evidence of controls operating effectively over time. The operative word is "evidence" – not "logs." Traditional mutable database logs are accepted today largely because alternatives did not exist. VOLT provides an alternative: cryptographically chained event records that a verifier can independently confirm have not been modified since creation.

EU AI Act enforcement for high-risk AI systems begins 2 August 2026. Articles 14 and 15 require human oversight mechanisms and logging capabilities for high-risk AI systems. Fines reach up to 7% of global annual revenue for prohibited AI practices and up to 3% for high-risk system non-compliance. VOLT's human-in-the-loop event types (hitl.requested, hitl.approved, hitl.denied) create verifiable proof that human oversight occurred, when it occurred, and who provided it.

What VOLT does not do

Intellectual honesty about limitations is essential for a protocol that claims to provide evidence.

VOLT does not guarantee truth. If the host running the AI agent is fully compromised, an attacker controlling the execution environment can emit a clean but fabricated VOLT trace.

VOLT guarantees tamper evidence – that a recorded trace has not been altered after the fact – not that the recording was honest in the first place. The VOLT threat model is explicit about this boundary, and prescribes mitigations (remote runner attestations, hardware-backed keys, cross-signing) for future versions.

VOLT does not replace policy enforcement. It records that policies were evaluated and what the outcomes were, but the actual enforcement is the responsibility of AOCL or whatever governance layer the organisation uses. VOLT is the flight recorder, not the autopilot.

VOLT does not act as a SIEM, analytics warehouse, or general-purpose observability platform. It produces evidence bundles, not dashboards. Organisations will likely feed VOLT events into their existing monitoring stack for operational visibility, but VOLT itself is deliberately narrow in scope.

Current status

The VOLT specification is at v0.1 (Draft). The core modules – recorder, store, bundler, verifier, signer, and canonical serialisation – are implemented and backed by 156 tests. The bridge module that connects VOLT to the QuoxCORE application lifecycle is built and tested but currently dormant in production, with settings-driven activation planned. RFC 3161 timestamping is planned for v0.2. Deterministic replay is planned for v0.3.

Where this goes

The v0.1 specification covers the core loop: Record, Bundle, Verify. The roadmap includes deterministic replay (re-executing tool interactions from recorded evidence for debugging and regression testing), TraceQL (a query language for investigating event chains), remote runner attestations with hardware-backed keys, and optional public anchoring for organisations that want external timestamp proof beyond RFC 3161.

The broader trajectory is toward a world where "the agent did the right thing" is not a claim a vendor makes in a slide deck. It is a cryptographic statement that any verifier can independently confirm, export, store, and re-examine years later.

AI agents are already making consequential decisions in production systems. The question is not whether we need verifiable evidence of those decisions. The question is whether we will build the evidence infrastructure before or after the first major incident where nobody can prove what happened.

VOLT is our answer to that question. The specification is open. The implementation has 156 tests. The maths does not require trust.