Tamper-evident logs are not enough. Someone has to watch the watcher.
In the Quox trust stack, AEE defines how agents communicate, AOCL defines how they are controlled, and VOLT defines how you prove what happened. Three protocols, three responsibilities, all working toward the same goal: making AI agent operations accountable.
But there is a gap.
VOLT produces hash-chained, verifiable evidence of everything an agent does. It is tamper-evident -- if someone modifies a recorded event, the chain breaks and a verifier will catch it. That is powerful. But "tamper-evident" has a boundary condition that is easy to overlook: if the attacker controls the host, they can rewrite the entire chain from genesis and produce a new, internally consistent trace that passes verification perfectly.
The evidence is honest. But who is watching the evidence?
This is the problem WARD solves.
What WARD Is
WARD -- Write-once Append-only Receipt Digests -- is a content-free witnessing protocol. It maintains a separate hash chain that observes events from AEE, AOCL, and VOLT, recording cryptographic receipts that prove specific events existed at specific points in time.
The critical word is "content-free." A WARD entry never stores what happened. It stores that something happened, identified by a source ID and the SHA-256 hash of the source event's canonical content. Zero bytes of payload. Zero bytes of message content. Zero bytes of tool output.
This is not a limitation -- it is the defining design constraint. A witnessing layer that stores content becomes another evidence system, with all the same attack surface, privacy concerns, and storage costs. WARD deliberately refuses to be that. It is a notary stamp, not a filing cabinet.
The Witness Problem
Consider a financial services firm running AI agents that execute trades on behalf of clients. VOLT records every decision: the market data received, the policy evaluation that approved the trade, the execution confirmation, the settlement notification. The VOLT Evidence Bundle is hash-chained and can be independently verified.
Now imagine a scenario where the firm's production host is compromised. The attacker does not just modify one event -- they regenerate the entire VOLT chain with fabricated events showing different trade parameters. The new chain is internally consistent. Every hash checks out. Every prev_hash links correctly. A VOLT verifier examining only the bundle will report PASS.
This is not a flaw in VOLT. VOLT's threat model is explicit about this boundary (threat T10: full host compromise). Hash chains guarantee that a recorded sequence has not been altered after creation. They do not guarantee that the recording was honest in the first place.
WARD addresses this by maintaining a separate chain, on a separate system, that witnesses events as they occur. When the VOLT recorder creates event 42, WARD independently records: "I observed event 42 with hash a1b2c3... at 2026-03-06T14:30:00Z." If the attacker later rewrites the VOLT chain, the WARD receipts will not match the new hashes. The tampering becomes detectable even after a full host compromise -- because the witness was elsewhere.
How WARD Works
WARD's design is deliberately minimal. Three operations: Witness, Tip, and Verify.
Witness: Content-Free Receipts
When a source event occurs -- an AEE envelope is sent, an AOCL policy decision is made, a VOLT event is recorded -- WARD creates a ward entry:
{
"ward_version": "0.1",
"ward_entry_id": "01JA...W1",
"chain_id": "ward:org/quox/env/production",
"seq": 147,
"witnessed_at": "2026-03-06T14:30:00.000Z",
"source_kind": "VOLT",
"source_id": "evt_01HZ...A7",
"payload_hash": "a1b2c3d4e5f6...64 hex chars",
"prev_chain_hash": "f7e8d9c0b1a2...64 hex chars",
"chain_hash": "1a2b3c4d5e6f...64 hex chars",
"issuer_id": "ward-instance-prod-01"
}
Notice what is absent. No message content. No tool inputs. No policy details. No personally identifiable information. The entry says: "Source VOLT event evt_01HZ...A7 was observed, and its canonical content hashed to a1b2c3...." That is all.
The chain_hash links this entry to the previous one via a deterministic formula:
chain_hash = SHA-256(prev_chain_hash | chain_id | seq | ward_entry_id
| timestamp | source_kind | source_id | payload_hash)
The first entry in any chain uses a genesis hash derived from the chain ID: SHA-256("WARD-GENESIS|" + chain_id). This anchors the chain's origin deterministically -- no random seed, no configuration, just the chain identifier.
Tip: Checkpoints With Teeth
Periodically -- every N entries, every T minutes, or at significant boundaries like the end of a workflow run -- WARD creates a tip. A tip is a signed checkpoint that summarizes chain state at a given sequence number.
Tips can be published to external append-only stores: Gitea signed tags, S3 Object Lock buckets, or any service that prevents modification after write. Once a tip is published externally, even compromising the WARD instance cannot erase the fact that the chain existed in that state at that time.
This is where WARD's value compounds. A hash chain on a single host provides tamper evidence. A signed tip published to an external sink provides tamper evidence that survives host compromise.
Verify: Chain Integrity Check
A WARD verifier performs five checks:
- Genesis -- The first entry's
prevchainhash matches the computed genesis hash for the chain ID. - Chain integrity -- Every entry's
chain_hash recomputes correctly from its inputs. - Ordering -- Sequence numbers are monotonically increasing from 1, with no gaps.
- Uniqueness -- No duplicate
(chainid, sourcekind, source_id) tuples. A chain must not witness the same event twice. - Tips -- If tips exist, each tip's
chain_hash matches the entry at the stated sequence number.
Like VOLT's verifier, WARD verification is deterministic and runs without any connection to the producing system.
Meta-Chains: Chains of Chains
WARD has one more structural feature that distinguishes it from a simple hash chain: meta-chains.
A meta-chain is a WARD chain that witnesses tips from other WARD chains. If you have separate chains for production, staging, and CI environments, a meta-chain can witness all of their tips, creating a single chain-of-chains for your entire deployment.
The meta-chain entry looks like any other ward entry, except sourcekind is WARD and the sourceid references the sub-chain's tip:
source_id: "ward:org/quox/env/production::42"
This means: "tip at sequence 42 from the production chain." The double colon separates the chain ID from the tip sequence to avoid ambiguity with the single colons in chain IDs.
A single meta-chain tip published to an external sink can anchor the integrity of every sub-chain in the deployment. One signed tag. One S3 object. Proof that all chains existed in their stated configurations at a specific moment.
One-Way Observation
WARD is a passive observer. This constraint is normative -- not a suggestion, a requirement.
Witnessing must not block, delay, or modify the source event pipeline. If WARD fails to record a receipt, the AEE message still delivers, the AOCL policy still evaluates, the VOLT event still records. WARD failures are logged but never propagated.
This matters for production adoption. An evidence system that causes downtime will be disabled. An evidence system that adds latency to the critical path will be bypassed. WARD is designed to be invisible to the systems it observes -- a silent notary that stamps receipts without interrupting the proceedings.
Where WARD Fits in the Stack
User Request
|
v
AEE (messages/envelopes) <----> Agents
|
v
AOCL (policies, approvals, control)
|
v
Tools / Runtimes / Files / Network
|
v
VOLT (evidence ledger + bundles + verification)
|
v
WARD (content-free witnessing + hash chain + tips)
Each layer has a clear, non-overlapping responsibility:
- AEE defines the message format. It does not enforce policy.
- AOCL enforces policy. It does not record evidence.
- VOLT records evidence. It does not witness itself.
- WARD witnesses everything. It does not store content.
The separation is deliberate. A witnessing layer that also stores content is just another evidence layer with additional attack surface. A witnessing layer that also enforces policy has a conflict of interest. WARD does exactly one thing: observe, hash, chain, and checkpoint.
Three Conformance Levels
WARD defines three conformance levels, allowing implementations to adopt the protocol incrementally:
WARD-W (Witness) -- The implementation produces valid ward entries with correct hashing, chaining, and uniqueness constraints. This is the entry point: a functioning hash-chain witness.
WARD-V (Verifier) -- The implementation can independently verify chain integrity, producing structured PASS/FAIL results. A verifier does not need to be the same system that produced the chain.
WARD-T (Tipper) -- The implementation creates valid tips, optionally signs them with Ed25519, and optionally publishes them to external sinks. This is the highest level, providing tamper evidence that survives host compromise.
What WARD Does Not Do
WARD does not store evidence. That is VOLT's job. WARD stores receipts -- cryptographic proof that evidence existed, not the evidence itself.
WARD does not prevent tampering. It makes tampering detectable. If an attacker rewrites a VOLT chain, WARD's receipts will not match the new hashes. But WARD cannot stop the attacker from rewriting in the first place.
WARD does not guarantee that the witness was honest. If the WARD instance itself is compromised at the time of witnessing, it can produce false receipts. The mitigation is operational: run WARD on a separate host, sign tips, and publish them to external sinks that the attacker does not control. The meta-chain pattern adds another layer by allowing independent WARD instances to cross-witness each other.
WARD does not replace a blockchain. For scenarios requiring distributed consensus among mutually distrusting parties, a blockchain may be appropriate. WARD solves a different problem: tamper-evident witnessing within an organization's trust boundary, with optional external anchoring for additional assurance.
Current Status
WARD is at v0.1 (Draft). The specification defines the core schema, hashing rules, chaining algorithm, tip format, meta-chain pattern, and verification procedure across 19 sections. The full spec, integration guide, verification algorithm, threat model, and worked examples are published in the repository.
Implementation is next. The spec is designed to be implementable in any language -- the cryptographic primitives are SHA-256 and optional Ed25519, both universally available. The storage model is intentionally flexible: SQLite for single-node deployments, PostgreSQL for multi-node, or any append-only store that supports the required constraints.
The WARD repository is at github.com/quoxai/ward. It will be made public shortly -- the spec is complete, and we are preparing the reference implementation.
Why This Matters Now
The AI agent industry is moving fast. Agents are executing tool calls, making policy decisions, handling financial transactions, and accessing sensitive systems. The evidence infrastructure is catching up -- VOLT provides verifiable traces, and that is a significant step forward from mutable database logs.
But evidence without a witness is evidence that can be silently replaced. WARD closes that gap. It is the final layer in a trust architecture that starts with standardized messaging (AEE), adds policy enforcement and observability (AOCL), records verifiable evidence (VOLT), and now provides independent, content-free witnessing that the evidence has not been tampered with.
The notary has arrived. The receipts are content-free, hash-chained, and -- once tipped to an external sink -- permanent.
Quox (quox.ai) builds trust infrastructure for AI agent operations. Its open protocols -- AEE for standardized agent messaging, AOCL for orchestration control and observability, VOLT for cryptographic evidence chains, and WARD for content-free witnessing -- provide the accountability architecture that autonomous systems require.
Get started
