Verifiable Operations Ledger and Trace (VOLT) Protocol

Verifiable Operations Ledger and Trace (VOLT) Protocol Quox Ltd

London United Kingdom adam@quox.ai https://quox.ai

Security Independent Submission AI agents cryptographic proof tamper evidence hash chain audit trail evidence bundle The Verifiable Operations Ledger and Trace (VOLT) protocol defines a minimal, interoperable format for producing tamper-evident execution traces for agentic AI workflows. VOLT records are linked via SHA-256 hash chains and packaged into portable Evidence Bundles that can be verified independently by any conformant implementation. VOLT functions as a "flight recorder" for AI agent operations: it captures the sequence of events -- messages received, policy decisions evaluated, human approvals granted, tools invoked, and results returned -- with cryptographic integrity guarantees that detect post-hoc modification, deletion, or insertion of records. The protocol is privacy-first by design. Events carry metadata and content-addressed references rather than raw secrets or sensitive payloads. Evidence Bundles support explicit redaction, optional Ed25519 signatures for non-repudiation, and both rolling and final snapshot modes for long-running workflows.

Introduction Autonomous and semi-autonomous AI agents are increasingly deployed to perform consequential operations: modifying production infrastructure, executing financial transactions, managing sensitive data, and orchestrating multi-step workflows across organizational boundaries. The operational logs produced by these systems are typically mutable, platform-locked, and lack cryptographic integrity guarantees. When an incident occurs -- an unauthorized change, a policy violation, or an unexpected outcome -- operators cannot reliably determine whether the recorded trace accurately reflects what happened. VOLT addresses this gap by defining a lightweight protocol for producing execution traces where each event is cryptographically linked to its predecessor via SHA-256 hash chaining. This creates an append-only integrity chain: any modification, deletion, or insertion of events after the fact is detectable through recomputation of hashes. Events are packaged into self-describing, portable Evidence Bundles that include a manifest, the event chain, content-addressed attachments, and optional digital signatures. VOLT is designed as a companion protocol to the Agent Envelope Exchange (AEE) messaging format and the Agent Orchestration Control Layers (AOCL) governance framework. Together, these three protocols provide a layered architecture for agentic systems: AEE handles message transport, AOCL enforces policies and approval gates, and VOLT records a tamper-evident audit trail of everything that occurred. It is important to note that VOLT provides tamper evidence, not "truth." If the execution host is fully compromised, an attacker controlling the recorder can emit a consistent but fabricated trace. VOLT detects post-hoc tampering of recorded traces; it does not guarantee that the recorder was honest at the time of recording. Optional signatures and planned future attestation mechanisms strengthen the non-repudiation properties, but the fundamental trust anchor remains the integrity of the recording environment. This document specifies VOLT version 0.1, covering event recording, hash chaining, Evidence Bundle packaging, verification, privacy and redaction rules, and conformance levels. Features such as deterministic replay, a trace query language, remote hardware attestation, and blockchain anchoring are explicitly out of scope for this version and are noted as future work.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Run: A single end-to-end execution instance, spanning from a user request (or system trigger) through to a terminal outcome. Each run is identified by a unique run_id.
Trace: The ordered sequence of events for a single run, forming the complete audit record of everything that occurred.
Event: One atomic record describing something that happened during a run: a message received, a policy decision, a tool invocation, a human approval, a model response, or any other observable action.
Ledger Chain: The sequence of events linked by prev_hash references, forming an append-only integrity chain. Each event's hash covers the event content, and each event's prev_hash points to the hash of the immediately preceding event.
Evidence Bundle: A portable, self-describing package containing the trace (as NDJSON), a manifest, optional content-addressed attachments, optional signatures, and optional redaction metadata. Bundles are designed for audit, compliance, and incident reconstruction.
Attachment: A content-addressed blob referenced by events via SHA-256 hash. Attachments hold tool outputs, generated artifacts, or other data that is too large or too detailed to embed in event payloads.
Commitment: A cryptographic hash representing content: an event hash, an attachment hash, or a run root hash. Commitments enable integrity verification without requiring access to the original content.
Attestation: A digital signature over one or more commitments, asserting that a particular actor or runner observed or executed the attested operations. Attestations are optional in VOLT v0.1 but the schema reserves fields for them.

Design Constraints

Privacy by Default VOLT events MUST NOT include secrets such as API keys, passwords, raw tokens, or private keys. Events SHOULD store metadata and content-addressed references (hashes) instead of raw content. Sensitive payload fields SHOULD be omitted or redacted at source. VOLT is an evidence protocol, and evidence that leaks secrets is a liability rather than an asset.

Minimal Schema with Extensible Evolution Every event MUST include a volt_version field. Unknown fields MUST be ignored by verifiers to ensure forward compatibility. Breaking changes to the event schema MUST increment the volt_version value (e.g., from "0.1" to "0.2" for compatible additions, or to "1.0" for incompatible changes).

Tamper Evidence, Not "Truth" VOLT guarantees that recorded traces are tamper-evident: any modification after the fact is detectable through hash verification. VOLT does not guarantee correctness of the recorded data if the host environment is fully compromised at the time of recording. The protocol detects changes to the record; it does not attest to the fidelity of what was recorded.

Transport and Encoding VOLT events are stored as Newline-Delimited JSON (NDJSON): one complete JSON object per line, separated by a single newline character (U+000A). The encoding MUST be UTF-8. Each line MUST be a syntactically complete JSON object; partial objects or multi-line pretty-printed JSON MUST NOT be used in the events file. The events file is conventionally named events.ndjson, though an alternative filename MAY be specified in the Evidence Bundle manifest via the events_file field. Events within the file MUST be ordered by ascending seq value.

Canonicalization To ensure consistent hashing across implementations, VOLT defines a Canonical JSON serialization. An implementation MUST produce a canonical byte representation of an event object as follows:

Serialize as JSON with UTF-8 encoding and no insignificant whitespace (no spaces after colons or commas, no newlines or indentation).
Object keys MUST be sorted lexicographically (byte-wise comparison of UTF-8 encoded key strings) at every nesting level.
Numbers MUST be represented without exponent notation where possible, and without a trailing ".0" when the value is integral. For example, the number 100 MUST be serialized as 100, not 1e2 or 100.0.
Strings MUST be Unicode NFC (Normalization Form Composed) normalized before serialization.

If an implementation's language or standard library does not provide a canonical JSON serializer, the implementation MUST apply a deterministic key sort and the normalized serialization rules above to produce byte-identical output for identical input objects.

Cryptographic Primitives

Hash Algorithm Event hashing and attachment hashing MUST use SHA-256 in VOLT v0.1. Future versions MAY introduce algorithm agility; the hash_alg field in manifests and attachment references is reserved for this purpose.

Hash Encoding Hash values MUST be encoded as lowercase hexadecimal strings of exactly 64 characters (representing the 256-bit SHA-256 digest). Implementations MAY display a prefixed form such as sha256:2cf24d... in user interfaces, but the stored value in event fields and manifest fields MUST be the pure 64-character hexadecimal string without prefix.

Signatures Digital signatures are optional in VOLT v0.1 but the event and manifest schemas reserve fields for them. When signatures are used:

The signature algorithm SHOULD be Ed25519 .
Public key identifiers SHOULD be stable across sessions, using a DID (Decentralized Identifier) or a key fingerprint.
Signatures MUST be computed over a clearly defined message structure, as specified in .

Identifiers and Time

Identifiers The run_id field MUST be unique per run. The event_id field MUST be unique within a run. Identifiers SHOULD be UUIDv4 or ULID (Universally Unique Lexicographically Sortable Identifier). Other globally unique identifier schemes MAY be used provided they satisfy the uniqueness requirements.

Timestamps The ts field MUST be an ISO 8601 timestamp in UTC with the "Z" suffix. Millisecond precision is RECOMMENDED. For example: 2026-02-28T19:11:02.123Z. Implementations MUST NOT use local time zone offsets; all timestamps MUST be expressed in UTC.

Event Schema All VOLT events are JSON objects. Every event MUST contain the following top-level fields: Required Event Fields

Field	Type	Description
`volt_version`	string	Protocol version, e.g., "0.1"
`event_id`	string	Unique identifier for this event within the run
`run_id`	string	Unique identifier for the run
`ts`	string	ISO 8601 UTC timestamp with Z suffix
`seq`	integer	Monotonically increasing sequence number, starting at 1
`event_type`	string	Dotted path identifying the event kind
`actor`	object	Who caused or observed the event
`context`	object	Correlation and cross-protocol linkage
`payload`	object	Event-type-specific data (privacy-safe)
`prev_hash`	string	64-char hex; hash of preceding event (64 zeros for genesis)
`hash`	string	64-char hex; SHA-256 of canonical event without hash field

Actor Object The actor object describes who emitted the event. It has the following fields: REQUIRED fields:

actor_type (string): One of "agent", "human", "system", "tool", or "runner".
actor_id (string): A stable identifier for the actor, such as an agent name, user ID, or system component identifier.

OPTIONAL fields:

display_name (string): A human-readable name for display purposes.
org_id (string): Organizational identifier.
team_id (string): Team identifier within the organization.
runner_id (string): Machine or host identity, when known, identifying the execution environment.

Example:

Context Object The context object links the event to AEE/AOCL and other external systems, enabling cross-protocol correlation. REQUIRED fields:

correlation_id (string): A stable identifier spanning the run. Implementations SHOULD use the AEE correlation ID as the primary linkage value.

OPTIONAL fields:

parent_event_id (string): For span-like linkage to a parent event within the same run.
aee_envelope_id (string): AEE envelope identifier.
aee_message_id (string): AEE message identifier.
aocl_policy_id (string): AOCL policy identifier relevant to this event.
aocl_decision_id (string): AOCL decision identifier for a specific policy evaluation.
workspace_id (string): Workspace or tenant identifier.
project_id (string): Project identifier.
tags (array of strings): Freeform tags for categorization and filtering.

Example:

Payload Object The payload object carries event-type-specific data. It MUST be safe by default: implementations MUST include metadata (tool names, operation types, timing, status codes) rather than secrets or raw sensitive content. Attachments SHOULD be referenced by hash rather than embedded. In VOLT v0.1, payloads are metadata-only. Examples of appropriate payload content include: field names present in the original message (payload_keys), token counts, tool names, exit codes, and duration measurements. Full-content payloads (raw message text, raw tool output) are deferred to future versions and will require opt-in redaction support to be conformant.

Event Hashing and Chaining

Hash Computation The event hash is computed as: Where EventWithoutHashField is the complete event object with the hash field removed. All other fields, including prev_hash, are included in the hash input. The result is encoded as a 64-character lowercase hexadecimal string.

Genesis Event The first event in a run (the genesis event) MUST have:

seq equal to 1.
prev_hash equal to 64 hexadecimal zeros: "0000000000000000000000000000000000000000000000000000000000000000".

Chain Rule For all events where seq is greater than 1, the prev_hash field MUST equal the hash of the event with sequence number seq - 1. Verifiers MUST reject any trace where the chain rule is violated.

Chained Events Example The following example shows three chained events forming a minimal trace. Hashes shown are illustrative abbreviated values; real implementations MUST use full 64-character hexadecimal SHA-256 digests. In this trace:

Event 1 (genesis) has prev_hash set to 64 zeros and its hash computed from its own content.
Event 2 has prev_hash equal to Event 1's hash, establishing the chain link.
Event 3 has prev_hash equal to Event 2's hash, continuing the chain. It also references an attachment by SHA-256 hash.

Standard Event Types Implementations MAY introduce custom event types, but the following standard types are RECOMMENDED for interoperability. The event_type field MUST be a lowercase dotted string with at least two segments.

Run Lifecycle Events Run Lifecycle Event Types

Event Type	Description
`run.started`	Run initialization; first substantive event after genesis
`run.completed`	Run finished successfully
`run.failed`	Run terminated with an error
`run.cancelled`	Run was cancelled by a user or system

AEE Messaging Events AEE Event Types

Event Type	Description
`aee.envelope.received`	An AEE envelope was received by the system
`aee.envelope.sent`	An AEE envelope was sent to a recipient
`aee.message.parsed`	An AEE message was successfully parsed
`aee.message.rejected`	An AEE message was rejected (validation failure)

AOCL Policy and Control Events AOCL Event Types

Event Type	Description
`aocl.policy.evaluated`	A policy was evaluated against the current context
`aocl.decision.approved`	A policy evaluation resulted in approval
`aocl.decision.denied`	A policy evaluation resulted in denial
`aocl.hitl.required`	A policy mandated human-in-the-loop approval

Tool Execution Events Tool Event Types

Event Type	Description
`tool.call.requested`	A tool invocation was requested by an agent
`tool.call.executed`	A tool invocation completed (success or failure)
`tool.call.failed`	A tool invocation failed with an error

Human-in-the-Loop Events HITL Event Types

Event Type	Description
`hitl.requested`	Human approval was requested
`hitl.approved`	A human approved the requested action
`hitl.denied`	A human denied the requested action
`hitl.timed_out`	A human approval request expired without response

File and Network Events File and Network Event Types

Event Type	Description
`file.read`	A file was read (metadata only: path category, size)
`file.write`	A file was written (metadata only: path category, size)
`net.request`	A network request was made (metadata only: method, status, timing)

Model Activity Events Model Event Types

Event Type	Description
`model.requested`	An AI model inference was requested (metadata: model name, token count)
`model.responded`	An AI model returned a response (metadata: model name, tokens used)

Custom Event Types Custom event types MAY be introduced by implementations. Custom types MUST NOT conflict with the standard prefixes (run, aee, aocl, tool, hitl, file, net, model) unless they are extending those namespaces in a compatible manner. Custom types SHOULD use a vendor namespace prefix, for example:

quox.marketplace.offer.created
vendorx.routeros.script.deployed

Verifiers MUST ignore unknown event_type values provided that all required fields are present and valid.

Attachments Attachments are content-addressed blobs referenced by events. They hold data that is too large or too detailed for inline inclusion in event payloads, such as tool standard output, generated configuration files, or sanitized report artifacts.

Attachment Hashing Attachment content MUST be hashed with SHA-256 over the raw bytes of the attachment file. The resulting hash is used both as the content address (filename) and as the integrity reference in event payloads.

Attachment References in Payloads Events that refer to attachments MUST reference them by hash within the payload object using an attachment_refs array. Each entry in the array MUST include:

hash_alg (string): The hash algorithm, "sha256" in v0.1.
hash (string): The 64-character hexadecimal hash of the attachment content.
content_type (string): The MIME type of the attachment (e.g., "text/plain", "application/json").
label (string): A human-readable label (e.g., "stdout", "stderr", "config_backup").

Example:

Storage Layout Within an Evidence Bundle, attachments SHOULD be stored under a two-level directory structure using the first two characters of the hash as a prefix directory: / ]]> For example, an attachment with hash e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 would be stored at: This prefix-based layout prevents file system performance degradation when large numbers of attachments are present.

Attachment Content Guidance Good candidates for attachments include: sanitized tool stdout/stderr, JSON tool results with secrets removed, generated artifacts (reports, configurations), and policy evaluation explanations. The following MUST NOT be stored as attachments by default: raw prompts containing secrets, raw HTTP headers or cookies, raw database dumps, private keys or tokens, full file contents of sensitive system locations, and personal data unless explicitly required and approved by policy. Implementations SHOULD support a configurable maximum attachment size and truncation with a "truncated" marker in the payload when content exceeds the limit.

Evidence Bundles An Evidence Bundle is a self-contained, portable package that enables independent verification of a VOLT trace. Bundles are designed for audit and compliance evidence, incident reconstruction, workflow accountability, and cross-system portability.

Bundle Layout A bundle may be represented as a directory on disk or as a ZIP archive. The contents MUST be identical regardless of container format. The recommended layout is: / manifest.json # REQUIRED: bundle index and summary events.ndjson # REQUIRED: the event chain attachments/ # OPTIONAL: content-addressed blobs ab/ ab12... e3/ e3b0... signatures/ # OPTIONAL: detached signature files sig-1.json redactions/ # OPTIONAL: redaction metadata redactions.json notes/ # OPTIONAL: human-readable notes notes.md ]]>

Manifest Format The manifest.json file MUST be a single JSON object encoded as UTF-8. It serves as the index and summary record for the bundle.

Required Manifest Fields Required Manifest Fields

Field	Type	Description
`volt_version`	string	MUST equal the event `volt_version`, e.g., "0.1"
`bundle_id`	string	Unique identifier for this bundle (UUID or ULID)
`run_id`	string	The run this bundle covers; ties to event `run_id`
`created_ts`	string	ISO 8601 UTC timestamp of bundle creation
`hash_alg`	string	Hash algorithm; MUST be "sha256" in v0.1
`events_file`	string	Filename of the events file, typically "events.ndjson"
`event_count`	integer	Total number of events in the events file
`first_event_hash`	string	64-char hex hash of the first event (seq=1)
`last_event_hash`	string	64-char hex hash of the last event (seq=max)

Recommended Manifest Fields The following fields are RECOMMENDED for production bundles:

bundle_mode (string): Either "rolling" or "final".
cutoff_ts (string): For rolling bundles, the ISO 8601 UTC timestamp of the cutoff point.
correlation_id (string): The AEE correlation ID for cross-protocol linkage.
producer (object): Information about the system that created the bundle, with subfields name (string), version (string), and optionally build (string, e.g., a git SHA).
integrations (object): Summary identifiers for AEE and AOCL integration, with optional aee and aocl subobjects.
redactions_present (boolean): Whether any events in the bundle contain redacted fields.
attachments_present (boolean): Whether the bundle includes attachment files.
attachments (array): A summary of included attachments, where each entry contains hash_alg, hash, content_type, bytes (integer), and path (string).
signatures (array): Signature records as defined in .
notes (string): Free-text notes about the bundle.

Manifest Example

Rolling and Final Bundles

Rolling Bundles Rolling bundles provide periodic evidence checkpoints for long-running workflows or to reduce data loss if a run crashes. A rolling bundle SHOULD set bundle_mode to "rolling", include a cutoff_ts timestamp, and set last_event_hash to the hash of the last included event at the cutoff point. Rolling bundles may be superseded by later rolling bundles or a final bundle.

Final Bundles Final bundles represent the complete record of a run. A final bundle SHOULD set bundle_mode to "final" and include a terminal event (run.completed, run.failed, or run.cancelled) as the last event in the chain. The event chain SHOULD span from seq=1 through the terminal event.

Signature Records VOLT v0.1 does not require signing, but defines a standard signature record format so that implementations can add signatures without breaking interoperability. Signatures may be included inline in manifest.json under the signatures array, or as individual files under the signatures/ directory. Each signature record contains the following REQUIRED fields:

sig_version (string): "0.1".
sig_type (string): The signature algorithm; "ed25519" is RECOMMENDED.
key_id (string): A stable identifier for the signing key (DID or key fingerprint).
signed_ts (string): ISO 8601 UTC timestamp of signing.
scope (string): "bundle" in v0.1.
message (object): The data that was signed, containing run_id, bundle_id, hash_alg, first_event_hash, last_event_hash, and event_count.
signature (string): Base64-encoded signature bytes.

Example signature record: A valid signature indicates that the signer attests the bundle's event chain endpoints and count match the signed message. Signatures do not prove that the underlying host was uncompromised; they provide non-repudiation and stronger chain-of-custody evidence.

Verification Verification is the core value proposition of VOLT: if an Evidence Bundle cannot be verified independently, it is not evidence. A successful verification confirms that the trace has integrity and the bundle is complete.

What Verification Guarantees A successful VOLT verification confirms:

Events are well-formed per this specification.
Each event hash matches recomputed content.
Each event links correctly to its predecessor via prev_hash.
The manifest matches the bundle contents (count and endpoint hashes).
Any referenced attachments exist and their hashes match.
Any included signatures (if present) validate correctly.

What Verification Does Not Guarantee Verification does not prove:

The host or runner was uncompromised during execution.
The tool results are "true" beyond what was recorded.
The AI model's reasoning was correct.
The run complied with external laws or policies not recorded as events.

VOLT is a tamper-evidence and chain-of-custody protocol, not an oracle.

Verification Algorithm The following algorithm is normative. A conformant verifier MUST implement all steps unless an optional skip flag is specified. Step 0 -- Load Bundle: Locate and parse manifest.json as UTF-8 JSON. Validate that all required manifest fields exist per . If the manifest is missing or unparseable, the result is ERROR. Step 1 -- Load Events: Read the events file specified by manifest.events_file (defaulting to events.ndjson). Parse as NDJSON: one JSON object per line. Collect events in file order. If any line is not valid JSON, the result is FAIL with reason INVALID_EVENT_JSON. Step 2 -- Validate Event Ordering: Ensure events are ordered by seq ascending. In strict mode, FAIL if seq does not start at 1 (SEQ_GAP), if any gap exists (SEQ_GAP), if duplicates are found (SEQ_DUPLICATE), or if the sequence is non-monotonic (SEQ_NOT_MONOTONIC). In permissive mode, warn on gaps but still FAIL on duplicates or decreasing sequences. Step 3 -- Validate Required Event Fields: For each event, verify that all required fields from exist and have the correct types. Missing or invalid fields result in FAIL with reason EVENT_SCHEMA_INVALID. Step 4 -- Validate Version Compatibility: The volt_version in manifest.json MUST match the volt_version in every event. A mismatch results in FAIL with reason VERSION_MISMATCH. Step 5 -- Recompute and Validate Event Hashes: For each event: (a) create a copy of the event object with the hash field removed; (b) serialize using the Canonical JSON rules from ; (c) compute the SHA-256 digest of the canonical bytes; (d) compare the computed hexadecimal digest to the stored hash. A mismatch results in FAIL with reason EVENT_HASH_MISMATCH. Step 6 -- Validate the Chain: For the first event (seq=1), prev_hash MUST be 64 hexadecimal zeros. Failure results in FAIL with reason INVALID_GENESIS_PREV_HASH. For each subsequent event, prev_hash MUST equal the hash of the immediately preceding event. A mismatch results in FAIL with reason CHAIN_BROKEN. Step 7 -- Validate Run ID Consistency: All events MUST have the same run_id as the manifest's run_id. A mismatch results in FAIL with reason RUN_ID_MISMATCH. Step 8 -- Validate Manifest Counts and Endpoints: (a) Count events in the file; the count MUST equal manifest.event_count. (b) Confirm manifest.first_event_hash equals the hash of the first event. (c) Confirm manifest.last_event_hash equals the hash of the last event. Any mismatch results in FAIL with reason MANIFEST_MISMATCH. Step 9 -- Validate Attachments (if enabled): For each event, locate any payload.attachment_refs entries. For each referenced attachment: (a) locate the file at attachments/<first2>/<hash>; (b) read the raw bytes; (c) compute SHA-256; (d) compare to the referenced hash. A missing file results in FAIL with reason ATTACHMENT_MISSING. A hash mismatch results in FAIL with reason ATTACHMENT_HASH_MISMATCH. If attachment verification is disabled via a flag, the verifier SHOULD set attachments_verified to false in the report and warn if attachment references exist. Step 10 -- Validate Signatures (if present and enabled): For each signature record in the manifest or under signatures/: (a) validate the signature record schema; (b) reconstruct the message object as defined in ; (c) verify the signature bytes using the declared algorithm (Ed25519 recommended); (d) confirm the scope is supported ("bundle" in v0.1). An invalid signature results in FAIL with reason SIGNATURE_INVALID. If signature verification is disabled, set signatures_verified to false in the report.

Verifier Report Format A verifier MUST output a result. For interoperability, VOLT v0.1 RECOMMENDS a JSON report format. PASS report example: FAIL report example: ERROR report example:

Exit Codes For command-line implementations, the following exit codes are RECOMMENDED: Verifier Exit Codes

Code	Meaning
0	PASS -- verification succeeded
1	FAIL -- verification detected integrity violations
2	ERROR -- invalid bundle format or I/O error

Standard Failure Reason Codes Verifiers SHOULD use consistent reason codes to enable automated processing of verification results. The following codes are defined: Standard Failure Reason Codes

Code	Description
MANIFEST_MISSING	manifest.json not found in bundle
MANIFEST_UNREADABLE	manifest.json exists but cannot be parsed
MANIFEST_SCHEMA_INVALID	manifest.json missing required fields
EVENTS_FILE_MISSING	Events file referenced by manifest not found
INVALID_EVENT_JSON	A line in the events file is not valid JSON
EVENT_SCHEMA_INVALID	An event is missing required fields or has wrong types
VERSION_MISMATCH	Event volt_version does not match manifest
RUN_ID_MISMATCH	Event run_id does not match manifest run_id
SEQ_NOT_MONOTONIC	Event sequence numbers are not monotonically increasing
SEQ_DUPLICATE	Duplicate sequence number found
SEQ_GAP	Gap detected in sequence numbers (strict mode)
EVENT_HASH_MISMATCH	Recomputed event hash does not match stored hash
INVALID_GENESIS_PREV_HASH	First event prev_hash is not 64 hex zeros
CHAIN_BROKEN	Event prev_hash does not match preceding event hash
MANIFEST_MISMATCH	Manifest counts or endpoint hashes do not match
ATTACHMENT_MISSING	Referenced attachment file not found
ATTACHMENT_HASH_MISMATCH	Attachment file hash does not match reference
SIGNATURE_SCHEMA_INVALID	Signature record is malformed
SIGNATURE_INVALID	Signature does not verify
UNSUPPORTED_SIGNATURE_TYPE	Signature algorithm not supported by verifier

Conformance Levels To keep implementations comparable, VOLT defines three conformance targets. An implementation may conform to one or more of these levels.

VOLT-R (Recorder) An implementation is VOLT-R conformant if it:

Emits events matching the schema defined in .
Computes hash and prev_hash correctly per .
Respects the privacy constraints defined in .
Uses the Canonical JSON serialization defined in for hash computation.

VOLT-B (Bundler) An implementation is VOLT-B conformant if it:

Produces a manifest.json with all required fields per .
Writes events.ndjson ordered by ascending seq per .
Stores attachments content-addressed per .
Ensures that secrets are excluded from event payloads and attachments.

VOLT-V (Verifier) An implementation is VOLT-V conformant if it:

Implements the full verification algorithm defined in .
Verifies both event hashes and chain integrity.
Verifies attachments referenced by events.
Produces a report per .
Returns appropriate exit codes per .

Privacy and Redaction VOLT is an evidence protocol. Evidence that captures secrets, personal data, or sensitive operational content by accident is a liability. This section defines the privacy-first logging rules and redaction strategies for VOLT.

Non-Negotiable Rules VOLT events and attachments MUST NOT contain:

API keys, access tokens, or session cookies.
Passwords or password hashes.
Private keys, seed phrases, or recovery codes.
Database connection strings containing credentials.
Full authorization headers (e.g., "Authorization: Bearer ...").
Raw secrets from environment variables.

The rule of thumb: if it can grant access, it MUST NOT be recorded. Events MUST default to metadata and references. Full outputs SHOULD be stored as attachments only when safe and useful. When in doubt, implementations MUST record a summary and content hash rather than raw content. When anything is omitted or sanitized, events MUST indicate this explicitly via redaction flags such as payload.redacted, payload.inputs_redacted, or payload.outputs_redacted set to true. This prevents silent censorship and keeps audits honest.

Data Classification Implementations SHOULD classify data into at least the following categories: Data Classification Levels

Level	Description
PUBLIC	Safe to store and export (rare for operational data)
INTERNAL	Safe within the organization; not for public export
SENSITIVE	Requires strict redaction controls before storage
SECRET	Must never be stored in VOLT events or attachments
PII	Personal data; may be subject to regulatory requirements

Secret Scanning Implementations SHOULD include a guard that runs before events and attachments are persisted. The scanner SHOULD detect:

Token-like strings (JWT patterns, API key prefixes such as sk-, ghp_, AKIA).
Common credential keys (password=, api_key, secret).
PEM blocks (-----BEGIN PRIVATE KEY-----).
AWS access key patterns (AKIA...).
Common bearer token and cookie patterns.

When a potential secret is detected, the implementation SHOULD strip the value, set payload.redacted to true, and optionally raise an AOCL policy alert. Attachments SHOULD be scanned and sanitized before storage; if an attachment cannot be safely sanitized, it SHOULD be omitted entirely.

Redaction Flags and Strategy In VOLT v0.1, redaction is explicit and simple:

Omit sensitive fields entirely from the payload.
Replace with boolean flags: "inputs_redacted": true or "redacted": true.
Optionally include a summary: "inputs_summary": "Write config file to prod".

Example redacted payload:

Redaction Log If an implementation performs redaction, it MAY include a redactions/redactions.json file in the Evidence Bundle. This file describes which events had fields redacted and the category of redaction. The format is: Note: VOLT v0.1 does not require cryptographic proof of redaction correctness. That is a planned enhancement for future versions.

Export Safety Rules When exporting Evidence Bundles outside the originating system (e.g., as a ZIP for audit handoff):

INTERNAL and SENSITIVE attachments SHOULD be removed unless explicitly included by policy.
A summary report of removed items SHOULD be included.
A verification report SHOULD be included if requested.
Chain integrity MUST be preserved: events MUST NOT be rewritten during export, as this would invalidate hashes.

If content must be removed after the fact, the export SHOULD be labeled as a "redacted bundle" and MUST NOT be presented as the original full-fidelity record.

Threat Model This section describes the threats VOLT is designed to mitigate, the threats it cannot fully mitigate, and recommended countermeasures. VOLT is an evidence integrity protocol providing tamper-evident traces and portable verification, not perfect truth in adversarial environments.

Threats VOLT Mitigates

T1 -- Post-Hoc Tampering of Events Attack: An adversary modifies an event after the run completes (e.g., changing "denied" to "approved"). Mitigation: Event hash validation detects the modification (EVENT_HASH_MISMATCH). Residual risk: If the adversary re-hashes the entire chain and no signatures are present, the fabricated chain will appear valid. Signatures eliminate this residual risk.

T2 -- Deleting Events from the Middle Attack: An adversary removes a tool execution event to conceal activity. Mitigation: The chain breaks (CHAIN_BROKEN) and/or a sequence gap is detected (SEQ_GAP). Residual risk: Same as T1 if the adversary rebuilds the chain from the deletion point.

T3 -- Inserting Fake Events Attack: An adversary inserts a fabricated hitl.approved event to manufacture consent. Mitigation: The chain breaks at the insertion point unless the adversary re-hashes all subsequent events. Residual risk: Without trusted signatures, a complete re-hash produces a valid fabricated chain.

T4 -- Attachment Substitution Attack: An adversary replaces a tool output attachment with a sanitized or fake version. Mitigation: Attachment hash validation detects the substitution (ATTACHMENT_HASH_MISMATCH). Residual risk: If the adversary also modifies the referencing event and re-hashes the chain, see T1.

T5 -- Repudiation of Approvals Attack: An actor claims "that approval wasn't mine." Mitigation: When actor identity and/or digital signatures are used, repudiation becomes significantly harder. Residual risk: Without signatures or strong identity binding, VOLT v0.1 provides sequencing evidence but weaker non-repudiation.

T6 -- Silent Redaction / Deceptive Logging Attack: A recorder omits sensitive tool actions silently without leaving any trace of their existence. Mitigation: VOLT requires explicit redaction flags; undisclosed omissions remain a governance and detection problem. Residual risk: If an event was never recorded, its absence cannot be proven by VOLT alone. AOCL policies should enforce required event types for specific operation classes.

Threats VOLT Does Not Fully Mitigate

T7 -- Fully Compromised Host or Runner Attack: An attacker controls the runner and emits a clean but fabricated VOLT trace. Why VOLT cannot solve this alone: The recorder runs in the compromised environment. A compromised host can produce any trace it wishes. Recommended mitigations: Remote runner attestations (planned), secure enclaves or TPM-backed keys, cross-signing from both orchestrator and runner, a separate logging channel to an append-only store, and strong AOCL enforcement with network segmentation.

T8 -- Signing Key Theft Attack: An attacker steals a signing key and can sign forged bundles. Recommended mitigations: Store keys in HSM or TPM hardware where possible; use short-lived keys with regular rotation; maintain key revocation lists; use separate keys per environment (development, staging, production); consider multi-signature requirements for high-risk runs.

T9 -- Incomplete Evidence (Missing Coverage) Attack: A tool executes without VOLT hooks, so the evidence is incomplete. Recommended mitigations: Enforce that all tool calls pass through instrumented middleware; use AOCL policies to deny execution if the VOLT recorder is not active; implement CI checks requiring certain event types (e.g., production runs must include hitl.approved).

T10 -- Privacy Leakage via Evidence Bundles Attack: Sensitive data leaks because it was inadvertently logged or exported without proper controls. Recommended mitigations: Enable secret scanning before write; enforce strict export controls with role-based access; implement configurable retention with automatic deletion; provide "export-safe" bundle modes that strip sensitive attachments.

Security Considerations This section discusses the security properties, limitations, and operational considerations of the VOLT protocol. Hash Chain Integrity Guarantees and Limitations. The SHA-256 hash chain provides strong tamper evidence for recorded traces. Any modification to an event -- changing a field value, altering a timestamp, or modifying actor information -- changes the event's hash, which in turn invalidates the prev_hash of every subsequent event. This cascade effect means that tampering with any single event requires recomputing all subsequent hashes. However, without digital signatures, an adversary with write access to the complete bundle can recompute the entire chain and produce a new, internally consistent but fabricated trace. Signatures provide the essential binding between the chain and a trusted identity. Genesis Event Trust Anchor. The genesis event (seq=1) uses a well-known prev_hash of 64 hexadecimal zeros. The integrity of the entire chain depends on the trustworthiness of this starting point. If an adversary can substitute the genesis event and recompute the chain, the verification will pass. Operators SHOULD treat the genesis event hash as a trust anchor and SHOULD distribute or record it through an out-of-band mechanism when strong assurance is required. Digital signatures over the bundle (covering first_event_hash) mitigate genesis substitution. Compromised Host Scenario. VOLT's integrity guarantees assume that the recording host is not fully compromised at the time of recording. A compromised host can emit arbitrary events that form a valid chain. VOLT detects post-hoc tampering (changes made after the chain was recorded), but it cannot detect fabrication at the source. Deployments requiring stronger guarantees SHOULD use remote attestation, cross-signing between multiple independent components, TPM-backed signing keys, or a separate append-only logging channel that is not controlled by the same host. Key Management for Signatures. When Ed25519 signatures are used, the signing keys become high-value targets. Key compromise allows an adversary to produce validly signed forged bundles. Implementations SHOULD store signing keys in hardware security modules (HSMs) or Trusted Platform Modules (TPMs) where available. Keys SHOULD be rotated regularly, and separate keys SHOULD be used for different environments (development, staging, production). Implementors SHOULD maintain a key revocation mechanism and SHOULD consider requiring multiple signatures from independent signers for high-risk production runs. Privacy Leakage via Metadata. Even when raw content is properly excluded from events, metadata can leak sensitive information. Timestamps reveal activity patterns. Actor identifiers may expose organizational structure. Correlation IDs can be used to link otherwise separate activities. Tool names and operation types may reveal infrastructure details. Implementations SHOULD assess the sensitivity of metadata fields in their deployment context and apply appropriate access controls to Evidence Bundles. The rules provide baseline guidance for cross-boundary transfers. Bundle Export Safety. Evidence Bundles exported outside the originating organization carry operational intelligence. Even with secrets removed, the sequence of events, tool names, timing information, and actor identifiers provide substantial insight into operational procedures and infrastructure. Exports MUST be treated as sensitive artifacts. Role-based access controls, audit logging of export operations, and data loss prevention policies SHOULD be applied. Redacted bundles MUST be clearly labeled and MUST NOT be represented as complete records. Replay and Preimage Resistance of SHA-256. VOLT relies on the collision resistance and preimage resistance of SHA-256 . As of the time of writing, SHA-256 remains considered secure against practical attacks, with no known feasible collision or preimage attacks. The hash_alg field in manifests and the versioning mechanism in VOLT provide a migration path if SHA-256 is deprecated in the future. Implementations SHOULD monitor cryptographic algorithm recommendations from NIST and be prepared to transition to stronger hash functions if required. Non-Repudiation with Ed25519. Ed25519 signatures over bundle commitments (covering run_id, bundle_id, first_event_hash, last_event_hash, and event_count) provide non-repudiation: a signer cannot deny having attested to a specific chain state without claiming key compromise. The strength of non-repudiation depends on the key management practices described above. In VOLT v0.1, signatures are optional; deployments requiring strong non-repudiation MUST enable signing and MUST implement robust key management. Future versions may introduce per-event signatures and multi-party attestation for stronger guarantees. Denial-of-Service Considerations. VOLT verification requires reading and hashing every event and attachment in a bundle. Maliciously crafted bundles with extremely large numbers of events, very large attachments, or deeply nested JSON structures could be used to consume excessive computational resources on a verifier. Implementations SHOULD impose configurable limits on event count, individual event size, attachment size, and total bundle size. Verifiers SHOULD report ERROR rather than attempting to process bundles that exceed configured limits.

IANA Considerations This document has no IANA actions.

References Normative References Informative References Agent Envelope Exchange (AEE) Agent Orchestration Control Layers (AOCL) Secure Hash Standard (SHS) National Institute of Standards and Technology (NIST)

Acknowledgements The author wishes to thank the early adopters and reviewers of the VOLT specification within the Quox ecosystem, whose feedback on real-world cryptographic evidence requirements for AI agent operations shaped the design of this protocol.