Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript.
Please enable Javascript for full functionality.
Verifiable Operations Ledger and Trace (VOLT) Protocol
draft-cowles-volt-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Adam Cowles | ||
| Last updated | 2026-02-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cowles-volt-00
Independent Submission A. Cowles
Internet-Draft Quox Ltd
Intended status: Experimental 28 February 2026
Expires: 1 September 2026
Verifiable Operations Ledger and Trace (VOLT) Protocol
draft-cowles-volt-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 September 2026.
Cowles Expires 1 September 2026 [Page 1]
Internet-Draft VOLT Protocol February 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Design Constraints . . . . . . . . . . . . . . . . . . . . . 6
4.1. Privacy by Default . . . . . . . . . . . . . . . . . . . 6
4.2. Minimal Schema with Extensible Evolution . . . . . . . . 6
4.3. Tamper Evidence, Not "Truth" . . . . . . . . . . . . . . 6
5. Transport and Encoding . . . . . . . . . . . . . . . . . . . 6
6. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 7
7. Cryptographic Primitives . . . . . . . . . . . . . . . . . . 7
7.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . . 7
7.2. Hash Encoding . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Signatures . . . . . . . . . . . . . . . . . . . . . . . 7
8. Identifiers and Time . . . . . . . . . . . . . . . . . . . . 8
8.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 8
9. Event Schema . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Actor Object . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Context Object . . . . . . . . . . . . . . . . . . . . . 10
9.3. Payload Object . . . . . . . . . . . . . . . . . . . . . 11
10. Event Hashing and Chaining . . . . . . . . . . . . . . . . . 11
10.1. Hash Computation . . . . . . . . . . . . . . . . . . . . 11
10.2. Genesis Event . . . . . . . . . . . . . . . . . . . . . 11
10.3. Chain Rule . . . . . . . . . . . . . . . . . . . . . . . 12
10.4. Chained Events Example . . . . . . . . . . . . . . . . . 12
11. Standard Event Types . . . . . . . . . . . . . . . . . . . . 14
11.1. Run Lifecycle Events . . . . . . . . . . . . . . . . . . 14
11.2. AEE Messaging Events . . . . . . . . . . . . . . . . . . 14
11.3. AOCL Policy and Control Events . . . . . . . . . . . . . 15
11.4. Tool Execution Events . . . . . . . . . . . . . . . . . 15
11.5. Human-in-the-Loop Events . . . . . . . . . . . . . . . . 15
11.6. File and Network Events . . . . . . . . . . . . . . . . 16
11.7. Model Activity Events . . . . . . . . . . . . . . . . . 16
11.8. Custom Event Types . . . . . . . . . . . . . . . . . . . 16
12. Attachments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Cowles Expires 1 September 2026 [Page 2]
Internet-Draft VOLT Protocol February 2026
12.1. Attachment Hashing . . . . . . . . . . . . . . . . . . . 17
12.2. Attachment References in Payloads . . . . . . . . . . . 17
12.3. Storage Layout . . . . . . . . . . . . . . . . . . . . . 18
12.4. Attachment Content Guidance . . . . . . . . . . . . . . 18
13. Evidence Bundles . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Bundle Layout . . . . . . . . . . . . . . . . . . . . . 19
13.2. Manifest Format . . . . . . . . . . . . . . . . . . . . 19
13.2.1. Required Manifest Fields . . . . . . . . . . . . . . 20
13.2.2. Recommended Manifest Fields . . . . . . . . . . . . 20
13.2.3. Manifest Example . . . . . . . . . . . . . . . . . . 21
13.3. Rolling and Final Bundles . . . . . . . . . . . . . . . 22
13.3.1. Rolling Bundles . . . . . . . . . . . . . . . . . . 22
13.3.2. Final Bundles . . . . . . . . . . . . . . . . . . . 23
13.4. Signature Records . . . . . . . . . . . . . . . . . . . 23
14. Verification . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. What Verification Guarantees . . . . . . . . . . . . . . 24
14.2. What Verification Does Not Guarantee . . . . . . . . . . 25
14.3. Verification Algorithm . . . . . . . . . . . . . . . . . 25
14.4. Verifier Report Format . . . . . . . . . . . . . . . . . 26
14.5. Exit Codes . . . . . . . . . . . . . . . . . . . . . . . 27
14.6. Standard Failure Reason Codes . . . . . . . . . . . . . 28
15. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 29
15.1. VOLT-R (Recorder) . . . . . . . . . . . . . . . . . . . 29
15.2. VOLT-B (Bundler) . . . . . . . . . . . . . . . . . . . . 30
15.3. VOLT-V (Verifier) . . . . . . . . . . . . . . . . . . . 30
16. Privacy and Redaction . . . . . . . . . . . . . . . . . . . . 30
16.1. Non-Negotiable Rules . . . . . . . . . . . . . . . . . . 30
16.2. Data Classification . . . . . . . . . . . . . . . . . . 31
16.3. Secret Scanning . . . . . . . . . . . . . . . . . . . . 31
16.4. Redaction Flags and Strategy . . . . . . . . . . . . . . 32
16.5. Redaction Log . . . . . . . . . . . . . . . . . . . . . 32
16.6. Export Safety Rules . . . . . . . . . . . . . . . . . . 33
17. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 33
17.1. Threats VOLT Mitigates . . . . . . . . . . . . . . . . . 34
17.1.1. T1 -- Post-Hoc Tampering of Events . . . . . . . . . 34
17.1.2. T2 -- Deleting Events from the Middle . . . . . . . 34
17.1.3. T3 -- Inserting Fake Events . . . . . . . . . . . . 34
17.1.4. T4 -- Attachment Substitution . . . . . . . . . . . 34
17.1.5. T5 -- Repudiation of Approvals . . . . . . . . . . . 35
17.1.6. T6 -- Silent Redaction / Deceptive Logging . . . . . 35
17.2. Threats VOLT Does Not Fully Mitigate . . . . . . . . . . 35
17.2.1. T7 -- Fully Compromised Host or Runner . . . . . . . 35
17.2.2. T8 -- Signing Key Theft . . . . . . . . . . . . . . 35
17.2.3. T9 -- Incomplete Evidence (Missing Coverage) . . . . 36
17.2.4. T10 -- Privacy Leakage via Evidence Bundles . . . . 36
18. Security Considerations . . . . . . . . . . . . . . . . . . . 36
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
Cowles Expires 1 September 2026 [Page 3]
Internet-Draft VOLT Protocol February 2026
20.1. Normative References . . . . . . . . . . . . . . . . . . 38
20.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
1. 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) [AEE] messaging format and the Agent Orchestration
Control Layers (AOCL) [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.
Cowles Expires 1 September 2026 [Page 4]
Internet-Draft VOLT Protocol February 2026
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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. 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.
Cowles Expires 1 September 2026 [Page 5]
Internet-Draft VOLT Protocol February 2026
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.
4. Design Constraints
4.1. 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.
4.2. 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).
4.3. 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.
5. Transport and Encoding
VOLT events are stored as Newline-Delimited JSON (NDJSON): one
complete JSON [RFC8259] 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.
Cowles Expires 1 September 2026 [Page 6]
Internet-Draft VOLT Protocol February 2026
6. 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:
1. Serialize as JSON with UTF-8 encoding and no insignificant
whitespace (no spaces after colons or commas, no newlines or
indentation).
2. Object keys MUST be sorted lexicographically (byte-wise
comparison of UTF-8 encoded key strings) at every nesting level.
3. 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.
4. 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.
7. Cryptographic Primitives
7.1. Hash Algorithm
Event hashing and attachment hashing MUST use SHA-256 [RFC6234] in
VOLT v0.1. Future versions MAY introduce algorithm agility; the
hash_alg field in manifests and attachment references is reserved for
this purpose.
7.2. 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.
7.3. Signatures
Digital signatures are optional in VOLT v0.1 but the event and
manifest schemas reserve fields for them. When signatures are used:
Cowles Expires 1 September 2026 [Page 7]
Internet-Draft VOLT Protocol February 2026
* The signature algorithm SHOULD be Ed25519 [RFC8032].
* 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 Section 13.4.
8. Identifiers and Time
8.1. Identifiers
The run_id field MUST be unique per run. The event_id field MUST be
unique within a run. Identifiers SHOULD be UUIDv4 [RFC4122] or ULID
(Universally Unique Lexicographically Sortable Identifier). Other
globally unique identifier schemes MAY be used provided they satisfy
the uniqueness requirements.
8.2. 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.
9. Event Schema
All VOLT events are JSON objects. Every event MUST contain the
following top-level fields:
Cowles Expires 1 September 2026 [Page 8]
Internet-Draft VOLT Protocol February 2026
+==============+=========+===================================+
| 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 |
+--------------+---------+-----------------------------------+
Table 1: Required Event Fields
9.1. 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.
Cowles Expires 1 September 2026 [Page 9]
Internet-Draft VOLT Protocol February 2026
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:
{
"actor_type": "agent",
"actor_id": "quox.agent.routeros",
"display_name": "RouterOS Agent",
"runner_id": "runner:vm-prod-01"
}
9.2. 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.
Cowles Expires 1 September 2026 [Page 10]
Internet-Draft VOLT Protocol February 2026
* project_id (string): Project identifier.
* tags (array of strings): Freeform tags for categorization and
filtering.
Example:
{
"correlation_id": "aee-corr-01HZABC123",
"aee_envelope_id": "aee-env-456",
"aocl_policy_id": "policy.prod.write.requires_hitl",
"tags": ["prod", "write", "hitl"]
}
9.3. 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.
10. Event Hashing and Chaining
10.1. Hash Computation
The event hash is computed as:
hash = SHA-256( CanonicalJSON( EventWithoutHashField ) )
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.
10.2. Genesis Event
The first event in a run (the genesis event) MUST have:
* seq equal to 1.
Cowles Expires 1 September 2026 [Page 11]
Internet-Draft VOLT Protocol February 2026
* prev_hash equal to 64 hexadecimal zeros: "000000000000000000000000
0000000000000000000000000000000000000000".
10.3. 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.
10.4. 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.
Cowles Expires 1 September 2026 [Page 12]
Internet-Draft VOLT Protocol February 2026
{"volt_version":"0.1","event_id":"evt-001",
"run_id":"run-abc-123",
"ts":"2026-02-28T19:12:00.000Z","seq":1,
"event_type":"run.started",
"actor":{"actor_type":"system",
"actor_id":"quox.core"},
"context":{"correlation_id":"corr-xyz-789"},
"payload":{"entrypoint":"api.chat",
"mode":"orchestrated"},
"prev_hash":"00000000...00000000",
"hash":"a1b2c3d4...e5f60718"}
{"volt_version":"0.1","event_id":"evt-002",
"run_id":"run-abc-123",
"ts":"2026-02-28T19:12:00.050Z","seq":2,
"event_type":"aee.envelope.received",
"actor":{"actor_type":"system",
"actor_id":"quox.aee.gateway"},
"context":{"correlation_id":"corr-xyz-789",
"aee_envelope_id":"aee-env-456"},
"payload":{"channel":"web","size_bytes":1842},
"prev_hash":"a1b2c3d4...e5f60718",
"hash":"b2c3d4e5...f6071829"}
{"volt_version":"0.1","event_id":"evt-003",
"run_id":"run-abc-123",
"ts":"2026-02-28T19:12:01.000Z","seq":3,
"event_type":"tool.call.executed",
"actor":{"actor_type":"runner",
"actor_id":"runner:vm-prod-01"},
"context":{"correlation_id":"corr-xyz-789"},
"payload":{"tool_name":"shell",
"status":"success","duration_ms":812,
"attachment_refs":[
{"hash_alg":"sha256",
"hash":"e3b0c442...7852b855",
"content_type":"text/plain",
"label":"stdout"}]},
"prev_hash":"b2c3d4e5...f6071829",
"hash":"c3d4e5f6...07182930"}
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.
Cowles Expires 1 September 2026 [Page 13]
Internet-Draft VOLT Protocol February 2026
* Event 3 has prev_hash equal to Event 2's hash, continuing the
chain. It also references an attachment by SHA-256 hash.
11. 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.
11.1. Run Lifecycle Events
+===============+=================================+
| 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 |
+---------------+---------------------------------+
Table 2: Run Lifecycle Event Types
11.2. AEE Messaging Events
+=======================+=============================+
| 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) |
+-----------------------+-----------------------------+
Table 3: AEE Event Types
Cowles Expires 1 September 2026 [Page 14]
Internet-Draft VOLT Protocol February 2026
11.3. AOCL Policy and Control Events
+========================+=============================+
| 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 |
+------------------------+-----------------------------+
Table 4: AOCL Event Types
11.4. Tool Execution Events
+=====================+=============================================+
| 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 |
+---------------------+---------------------------------------------+
Table 5: Tool Event Types
11.5. Human-in-the-Loop Events
+================+=======================================+
| 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 |
+----------------+---------------------------------------+
Cowles Expires 1 September 2026 [Page 15]
Internet-Draft VOLT Protocol February 2026
| hitl.timed_out | A human approval request expired |
| | without response |
+----------------+---------------------------------------+
Table 6: HITL Event Types
11.6. File and Network Events
+=============+======================================+
| 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) |
+-------------+--------------------------------------+
Table 7: File and Network Event Types
11.7. Model Activity Events
+=================+=====================================+
| 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) |
+-----------------+-------------------------------------+
Table 8: Model Event Types
11.8. 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
Cowles Expires 1 September 2026 [Page 16]
Internet-Draft VOLT Protocol February 2026
Verifiers MUST ignore unknown event_type values provided that all
required fields are present and valid.
12. 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.
12.1. 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.
12.2. 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:
Cowles Expires 1 September 2026 [Page 17]
Internet-Draft VOLT Protocol February 2026
{
"tool_name": "shell",
"status": "success",
"duration_ms": 812,
"attachment_refs": [
{
"hash_alg": "sha256",
"hash": "e3b0c44298fc1c149afbf4c8996fb924...",
"content_type": "text/plain",
"label": "stdout"
},
{
"hash_alg": "sha256",
"hash": "7d865e959b2466918c9863afca942d0f...",
"content_type": "text/plain",
"label": "stderr"
}
]
}
12.3. 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:
attachments/<first-two-hex-chars>/<full-hash>
For example, an attachment with hash
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
would be stored at:
attachments/e3/e3b0c44298fc1c14...7852b855
This prefix-based layout prevents file system performance degradation
when large numbers of attachments are present.
12.4. 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.
Cowles Expires 1 September 2026 [Page 18]
Internet-Draft VOLT Protocol February 2026
Implementations SHOULD support a configurable maximum attachment size
and truncation with a "truncated" marker in the payload when content
exceeds the limit.
13. 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.
13.1. 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:
<bundle_root>/
manifest.json # REQUIRED: bundle index and summary
events.ndjson # REQUIRED: the event chain
attachments/ # OPTIONAL: content-addressed blobs
ab/
ab12...<hash>
e3/
e3b0...<hash>
signatures/ # OPTIONAL: detached signature files
sig-1.json
redactions/ # OPTIONAL: redaction metadata
redactions.json
notes/ # OPTIONAL: human-readable notes
notes.md
13.2. 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.
Cowles Expires 1 September 2026 [Page 19]
Internet-Draft VOLT Protocol February 2026
13.2.1. 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) |
+------------------+---------+------------------------------+
Table 9: Required Manifest Fields
13.2.2. 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.
Cowles Expires 1 September 2026 [Page 20]
Internet-Draft VOLT Protocol February 2026
* 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 Section 13.4.
* notes (string): Free-text notes about the bundle.
13.2.3. Manifest Example
Cowles Expires 1 September 2026 [Page 21]
Internet-Draft VOLT Protocol February 2026
{
"volt_version": "0.1",
"bundle_id": "01HZBUNDLE001",
"run_id": "01HZRUN001",
"created_ts": "2026-02-28T19:15:00.000Z",
"hash_alg": "sha256",
"events_file": "events.ndjson",
"event_count": 8,
"first_event_hash":
"a1b2c3d4...e5f60718",
"last_event_hash":
"c3d4e5f6...07182930",
"bundle_mode": "final",
"correlation_id": "aee-corr-01HZABC123",
"producer": {
"name": "quox-core",
"version": "0.9.3",
"build": "git:8f3a3b1"
},
"redactions_present": true,
"attachments_present": true,
"attachments": [
{
"hash_alg": "sha256",
"hash":
"e3b0c442...7852b855",
"content_type": "text/plain",
"bytes": 4832,
"path":
"attachments/e3/e3b0c442...b855"
}
]
}
13.3. Rolling and Final Bundles
13.3.1. 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.
Cowles Expires 1 September 2026 [Page 22]
Internet-Draft VOLT Protocol February 2026
13.3.2. 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.
13.4. 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:
Cowles Expires 1 September 2026 [Page 23]
Internet-Draft VOLT Protocol February 2026
{
"sig_version": "0.1",
"sig_type": "ed25519",
"key_id":
"did:key:z6Mkn5Gq...LxXWxabc",
"signed_ts": "2026-02-28T19:15:05.000Z",
"scope": "bundle",
"message": {
"run_id": "01HZRUN001",
"bundle_id": "01HZBUNDLE001",
"hash_alg": "sha256",
"first_event_hash":
"a1b2c3d4...e5f60718",
"last_event_hash":
"c3d4e5f6...07182930",
"event_count": 8
},
"signature": "MEUCIQDxAbcDefGhIjKlMnOpQrStUvWxYz0123456789..."
}
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.
14. 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.
14.1. 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.
Cowles Expires 1 September 2026 [Page 24]
Internet-Draft VOLT Protocol February 2026
14.2. 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.
14.3. 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
Section 13.2.1. 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 Table 1 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.
Cowles Expires 1 September 2026 [Page 25]
Internet-Draft VOLT Protocol February 2026
*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 Section 6; (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 Section 13.4; (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.
14.4. Verifier Report Format
A verifier MUST output a result. For interoperability, VOLT v0.1
RECOMMENDS a JSON report format.
PASS report example:
Cowles Expires 1 September 2026 [Page 26]
Internet-Draft VOLT Protocol February 2026
{
"result": "PASS",
"run_id": "01HZRUN001",
"bundle_id": "01HZBUNDLE001",
"volt_version": "0.1",
"hash_alg": "sha256",
"event_count": 128,
"first_event_hash": "a1b2c3d4...90",
"last_event_hash": "f0e1d2c3...08",
"attachments_verified": true,
"signatures_verified": false,
"warnings": []
}
FAIL report example:
{
"result": "FAIL",
"reason": "EVENT_HASH_MISMATCH",
"details": {
"seq": 42,
"event_id": "01HZ-EVT-042",
"expected_hash": "a1b2c3d4e5f6...",
"found_hash": "ffee0011aabb..."
}
}
ERROR report example:
{
"result": "ERROR",
"reason": "MANIFEST_UNREADABLE",
"details": {
"message": "manifest.json missing or invalid JSON"
}
}
14.5. Exit Codes
For command-line implementations, the following exit codes are
RECOMMENDED:
Cowles Expires 1 September 2026 [Page 27]
Internet-Draft VOLT Protocol February 2026
+======+====================================================+
| Code | Meaning |
+======+====================================================+
| 0 | PASS -- verification succeeded |
+------+----------------------------------------------------+
| 1 | FAIL -- verification detected integrity violations |
+------+----------------------------------------------------+
| 2 | ERROR -- invalid bundle format or I/O error |
+------+----------------------------------------------------+
Table 10: Verifier Exit Codes
14.6. Standard Failure Reason Codes
Verifiers SHOULD use consistent reason codes to enable automated
processing of verification results. The following codes are defined:
+============================+===================================+
| 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 |
+----------------------------+-----------------------------------+
Cowles Expires 1 September 2026 [Page 28]
Internet-Draft VOLT Protocol February 2026
| 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 |
+----------------------------+-----------------------------------+
Table 11: Standard Failure Reason Codes
15. Conformance Levels
To keep implementations comparable, VOLT defines three conformance
targets. An implementation may conform to one or more of these
levels.
15.1. VOLT-R (Recorder)
An implementation is VOLT-R conformant if it:
* Emits events matching the schema defined in Section 9.
* Computes hash and prev_hash correctly per Section 10.
* Respects the privacy constraints defined in Section 4.
Cowles Expires 1 September 2026 [Page 29]
Internet-Draft VOLT Protocol February 2026
* Uses the Canonical JSON serialization defined in Section 6 for
hash computation.
15.2. VOLT-B (Bundler)
An implementation is VOLT-B conformant if it:
* Produces a manifest.json with all required fields per
Section 13.2.1.
* Writes events.ndjson ordered by ascending seq per Section 5.
* Stores attachments content-addressed per Section 12.
* Ensures that secrets are excluded from event payloads and
attachments.
15.3. VOLT-V (Verifier)
An implementation is VOLT-V conformant if it:
* Implements the full verification algorithm defined in
Section 14.3.
* Verifies both event hashes and chain integrity.
* Verifies attachments referenced by events.
* Produces a report per Section 14.4.
* Returns appropriate exit codes per Section 14.5.
16. 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.
16.1. 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.
Cowles Expires 1 September 2026 [Page 30]
Internet-Draft VOLT Protocol February 2026
* 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.
16.2. Data Classification
Implementations SHOULD classify data into at least the following
categories:
+===========+======================================================+
| 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 |
+-----------+------------------------------------------------------+
Table 12: Data Classification Levels
16.3. 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).
Cowles Expires 1 September 2026 [Page 31]
Internet-Draft VOLT Protocol February 2026
* 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.
16.4. 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:
{
"tool_name": "shell",
"operation": "write_file",
"target": "prod/nginx.conf",
"inputs_redacted": true,
"inputs_summary": "Write nginx configuration update"
}
16.5. 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:
Cowles Expires 1 September 2026 [Page 32]
Internet-Draft VOLT Protocol February 2026
{
"volt_version": "0.1",
"run_id": "01HZRUN001",
"items": [
{
"event_id": "evt-006",
"fields_removed": ["payload.inputs"],
"reason": "secret"
},
{
"event_id": "evt-009",
"fields_removed": ["payload.response_body"],
"reason": "pii"
}
]
}
Note: VOLT v0.1 does not require cryptographic proof of redaction
correctness. That is a planned enhancement for future versions.
16.6. 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.
17. 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.
Cowles Expires 1 September 2026 [Page 33]
Internet-Draft VOLT Protocol February 2026
17.1. Threats VOLT Mitigates
17.1.1. 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.
17.1.2. 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.
17.1.3. 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.
17.1.4. 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.
Cowles Expires 1 September 2026 [Page 34]
Internet-Draft VOLT Protocol February 2026
17.1.5. 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.
17.1.6. 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.
17.2. Threats VOLT Does Not Fully Mitigate
17.2.1. 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.
17.2.2. 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.
Cowles Expires 1 September 2026 [Page 35]
Internet-Draft VOLT Protocol February 2026
17.2.3. 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).
17.2.4. 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.
18. 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.
Cowles Expires 1 September 2026 [Page 36]
Internet-Draft VOLT Protocol February 2026
*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 Section 16.6
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.
Cowles Expires 1 September 2026 [Page 37]
Internet-Draft VOLT Protocol February 2026
*Replay and Preimage Resistance of SHA-256.* VOLT relies on the
collision resistance and preimage resistance of SHA-256 [RFC6234].
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 [FIPS180-4] and be prepared to
transition to stronger hash functions if required.
*Non-Repudiation with Ed25519.* Ed25519 [RFC8032] 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.
19. IANA Considerations
This document has no IANA actions.
20. References
20.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Cowles Expires 1 September 2026 [Page 38]
Internet-Draft VOLT Protocol February 2026
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
20.2. Informative References
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[AEE] Cowles, A., "Agent Envelope Exchange (AEE)", Work in
Progress, Internet-Draft, draft-cowles-aee-00, 2026,
<https://github.com/AdaminX/AEE-Agent-Envelope-Exchange>.
[AOCL] Cowles, A., "Agent Orchestration Control Layers (AOCL)",
Work in Progress, Internet-Draft, draft-cowles-aocl-00,
2026, <https://github.com/AdaminX/AOCL-Agent-
Orchestration-Control-Layers-Protocol>.
[FIPS180-4]
National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS 180-4, August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/
final>.
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.
Author's Address
Cowles Expires 1 September 2026 [Page 39]
Internet-Draft VOLT Protocol February 2026
Adam Cowles
Quox Ltd
London
United Kingdom
Email: adam@quox.ai
URI: https://quox.ai
Cowles Expires 1 September 2026 [Page 40]