The Quox Trust Stack

The inversion

There is a seductive pattern in how AI agent platforms are built. Start with the orchestrator. Wire up the LLM. Connect the tools. Add memory. Ship it. Then, once customers ask about compliance, bolt on some logging. Once an auditor asks for evidence, export the logs to a PDF.

Once a regulator asks for controls, write a policy document that describes what the system is supposed to do and hope nobody checks whether it actually does it.

This is how the industry works today. Orchestration first. Trust as an afterthought.

The difference is not semantic. It determines what happens when something goes wrong.

In a log-generating system, evidence is a byproduct. The primary pipeline is: receive request, route to agent, execute tools, return result. Somewhere along that path, log entries are written. Those entries might be structured or unstructured, complete or partial, mutable or immutable. They exist because someone added a database insert at points they thought were important.

In an accountability system, evidence is the pipeline. Every step that processes a request also produces a structured, cryptographically linked record of what it did and why. The record is not a side effect of execution. It is a co-product. The system cannot process a request without simultaneously producing the audit trail, because the audit trail and the processing pipeline are architecturally the same thing.

Four protocols, one pipeline

The Quox Trust Stack is built from four open protocols. Each handles a distinct concern. Together, they form a single pipeline where every request is simultaneously processed and accounted for.

AEE: The Envelope

Agent Envelope Exchange is where everything begins. Every interaction in the system, human to agent, agent to agent, agent to tool, tool response back, is wrapped in a 14-field JSON envelope.

The envelope carries identity (who sent this, who receives it), correlation (which conversation does this belong to), causality (what message triggered this one), intent (what action is being requested), and operational constraints (timeouts, approval requirements, evidence levels).

AEE is not just a messaging format. It is the skeleton key for auditing multi-agent workflows. Given any correlation ID, you can pull the complete conversation graph, every participant, every delegation, every result, without parsing a single log file.

AOCL: The Control Layers

Agent Orchestration Control Layers defines what happens between receiving a request and producing a response. It specifies 11 ordered processing layers, from initial input normalisation through identity scoping, smart routing, policy gating, context retrieval, prompt shaping, task delegation, response verification, and audit writeback.

The critical insight: every layer emits a structured record when it executes. Not a log line. A structured event with a timestamp, the actor that executed it, the decision made, the inputs considered, and the outcome.

This is where the "trust first, orchestrate second" philosophy becomes concrete. AOCL does not orchestrate and then report what it did. The orchestration is the reporting. Each layer's primary output is twofold: the processing result and the observability event. You cannot have one without the other.

VOLT: The Evidence

Verifiable Operations Ledger and Trace records cryptographic proof of what happened during an agent operation. Every significant event becomes a VOLT event. Each event is SHA-256 hashed. Each event includes the hash of the previous event, forming an append-only chain. Tamper with any event and the chain breaks.

VOLT events are not logs. Logs are claims made by the system operator. VOLT events are cryptographic commitments. A VOLT Evidence Bundle can be exported, handed to an external auditor, and independently verified without any connection to the system that produced it. The result is PASS or FAIL. No trust required.

This matters because the regulatory landscape is catching up to where AI agents already are. The EU AI Act enforcement begins August 2026. NIST is actively soliciting input on accountability mechanisms. SOC 2 Type II audits are increasingly asking questions about AI system evidence that log files cannot answer.

WARD: The Witness

Write-once Append-only Receipt Digests is the final layer, and the one that closes a subtle but critical vulnerability.

VOLT provides tamper evidence: if someone modifies a recorded event, the chain breaks. But what if an attacker controls the host and rewrites the entire chain from genesis? The new chain is internally consistent. Every hash checks out. A VOLT verifier will report PASS on a completely fabricated trace.

WARD addresses this by maintaining a separate, content-free hash chain that witnesses events from the other three protocols. WARD never stores content, only identifiers and payload hashes. WARD tips (periodic signed checkpoints) can be published to external append-only stores. Once a tip is published externally, the integrity of the entire chain up to that point is anchored outside the system's trust boundary.

How the protocols compose

The four protocols are not independent tools you pick from a menu. They compose into a single pipeline where processing and accountability are inseparable. Here is what happens when a user sends a message to an AI agent running on the Quox Trust Stack:

1. Envelope creation (AEE): message wrapped in a 14-field envelope with unique ID, correlation ID, sender identity, recipient, intent classification, and operational constraints.
2. Control pipeline (AOCL): envelope passes through 11 ordered layers. Each layer processes the request and emits a structured observability event. Routing, policy, context, delegation, all recorded as they happen.
3. Evidence recording (VOLT): as AOCL layers execute, VOLT records each significant event as a hash-chained entry. Tool calls, policy decisions, human approvals, each becomes a link in the chain.
4. Witnessing (WARD): WARD observes the AEE envelope, the AOCL decisions, and the VOLT bundle commitment. For each, it creates a content-free receipt in its own hash chain and periodically publishes a signed tip.

Protocol integration

Each protocol feeds into the next. The data flow is unidirectional and the evidence chain is continuous: an AEE envelope carries identity, correlation, and causality into the AOCL pipeline, where 11 layers each emit a structured event. Those events become the VOLT chain, hash-linked evidence for each one.

WARD receipts then provide a content-free witness of all layers, and a signed tip is published to an external anchor store, completing the chain from message to independently verifiable proof.

Why order matters

The temptation is to build the orchestrator first and add governance later. Every team faces this pressure. The demo needs to work by Tuesday. The investor wants to see the agent execute a complex workflow. The customer wants tool integration, not compliance paperwork.

But governance retrofitted onto an existing system is fundamentally different from governance built into the foundation.

This is the architectural decision that the "trust first" philosophy demands. It is more work upfront. It is slower to ship the first demo. But when a regulator asks "prove this agent was authorised to access that data," you hand them a VOLT Evidence Bundle.

When an auditor asks "was human oversight applied?" you pull the AOCL L3 policy gate record and the HITL approval event, both cryptographically chained to the exact request in question.

What runs through the stack

The four protocols are designed to handle every category of AI agent operation:

• Conversational AI. Every message is an AEE envelope. Every turn passes through AOCL control layers. Every significant event is a VOLT entry. The complete conversation is auditable end to end.
• Tool execution. Tool calls pass through AOCL delegation (L7) and produce VOLT events for the call, the result, and any side effects. Destructive tools can require human-in-the-loop gates.
• Multi-agent workflows. Delegations are AEE envelopes with reply_to linking. The entire chain shares a single correlation ID. Pull the corr and you get the complete workflow graph.
• Policy enforcement. Rate limits, permissions, content filtering, cost controls, all evaluated at AOCL L3. Both allow and deny decisions are captured as structured events.
• Human oversight. Approvals, escalations, manual overrides. The chain of custody from automated request through human decision to execution is unbroken and cryptographically linked.
• Scheduled automation. Cron-triggered tasks, event-driven workflows, batch processing. Same pipeline, same evidence trail. Whether the request came from a human or a cron job, the audit trail is identical.

The compliance conversation

Every quarter, the compliance conversation gets more urgent. The EU AI Act reaches enforcement for high-risk systems in August 2026, fines up to 7% of global annual revenue. NIST's AI Risk Management Framework calls for documented AI system behaviour and mechanisms for independent review. SOC 2 Type II audits increasingly ask about AI agent controls and evidence trails.

The Quox Trust Stack produces a different kind of answer. Instead of describing what controls exist, it produces cryptographic proof that controls were applied. Instead of documenting what the system is supposed to do, it provides verifiable evidence of what the system actually did.

Open protocols, not a walled garden

All four protocols are open specifications, published under MIT licence. They are open for community review, critique, and independent implementation.

*Updated twice in August 2026. This section once split the four protocols into filed and unfiled; since 31 August that distinction is gone in the other direction. AEE, AOCL, VOLT and WARD are all live IETF Internet-Drafts, filed or refreshed together and current to 4 March 2027.

All four stand in the same place: published open specifications, with resubmission of all four planned to the same standards body that produced HTTP, TLS and JSON once Quox is launched.*

Trust infrastructure should not be proprietary. If the system that proves your AI agents are accountable is itself a black box, you have not solved the trust problem, you have moved it. The protocols are designed so that any organisation can implement them independently and any third party can verify the output without trusting Quox's infrastructure.

Where this is going

The Quox Trust Stack is not a future plan. All four protocols are implemented, tested, and integrated into QuoxCORE, and all four ship with an SDK and a conformance suite.

Updated August 2026: this section used to say WARD's specification was complete and implementation was next. That undersold it. WARD runs as a dedicated service inside QuoxCORE, with Ed25519-signed chain tips, a standalone verification CLI, and the most thorough conformance suite of the four: chain-hash mismatches, broken links, sequence violations, missing genesis, duplicate sources, tip forgery, unsigned tips and invalid signatures are each detected with their own failure code.

The trajectory is towards a world where "the AI agent did the right thing" is not a vendor claim in a marketing slide. It is a cryptographic statement backed by four layers of evidence that any verifier can independently confirm.

Quox (quox.ai) builds trust infrastructure for AI agent operations. The Quox Trust Stack, AEE for standardised messaging, AOCL for control and observability, VOLT for cryptographic evidence, and WARD for content-free witnessing, provides the accountability architecture that autonomous systems require.