Individual Submission B. Stone Internet-Draft SwarmSync.AI Intended status: Informational 4 September 2026 Expires: 8 March 2027 AIVS: Agentic Integrity Verification Standard draft-stone-aivs-01 Abstract The Agentic Integrity Verification Standard (AIVS) defines a portable, self-verifiable archive format for cryptographic proof of AI agent sessions. An AIVS bundle is a gzip-compressed tar archive containing a SHA-256 hash-chained audit log, an Ed25519 digital signature over the chain, a machine-readable manifest, and an embedded verification script that requires only Python 3 standard library to execute. AIVS also defines *AIVS-Micro*: a minimal 6-field attestation (~200 bytes) for continuous monitoring, embedded widgets, and API responses where a full session bundle is not required. AIVS enables any party to independently verify that: 1. Every action in the session is accounted for and unmodified (hash chain integrity) 2. No actions have been inserted, deleted, or reordered (sequential chaining) 3. The session was produced by a specific cryptographic identity (Ed25519 signature) 4. All of the above can be verified offline, without network access, and without installing any software beyond Python 3 (self- verification) 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/. Stone Expires 8 March 2027 [Page 1] Internet-Draft AIVS September 2026 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 8 March 2027. 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. 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 1.1 Problem Statement . . . . . . . . . . . . . . . . . . 3 1.2. 1.2 Design Goals . . . . . . . . . . . . . . . . . . . . 4 1.3. 1.3 Relationship to Existing Standards . . . . . . . . . 5 2. 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. 3. Hash Chain Specification . . . . . . . . . . . . . . . . 6 3.1. 3.1 Row Hash Computation . . . . . . . . . . . . . . . . 6 3.2. 3.2 Field Definitions . . . . . . . . . . . . . . . . . . 7 3.3. 3.3 Chain Integrity Property . . . . . . . . . . . . . . 8 3.4. 3.4 Chain Hash Computation . . . . . . . . . . . . . . . 8 4. 4. Audit Row Schema . . . . . . . . . . . . . . . . . . . . 8 4.1. 4.1 Field Specifications . . . . . . . . . . . . . . . . 9 4.2. 4.2 Sensitive Input Redaction . . . . . . . . . . . . . . 10 4.3. 4.3 Output Truncation . . . . . . . . . . . . . . . . . . 10 4.4. 4.4 JavaScript Source Storage (eval actions) . . . . . . 10 5. 5. Ed25519 Signature . . . . . . . . . . . . . . . . . . . . 11 5.1. 5.1 Signing . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. 5.2 Identity Key . . . . . . . . . . . . . . . . . . . . 11 5.3. 5.3 Signature File Format . . . . . . . . . . . . . . . . 11 5.4. 5.4 Public Key File Format . . . . . . . . . . . . . . . 12 5.5. 5.5 Signature is Optional . . . . . . . . . . . . . . . . 12 6. 6. AIVS Full Bundle Format . . . . . . . . . . . . . . . . . 12 6.1. 6.1 Archive Structure . . . . . . . . . . . . . . . . . . 12 6.2. 6.2 Filename Convention . . . . . . . . . . . . . . . . . 12 6.3. 6.3 audit_log.jsonl . . . . . . . . . . . . . . . . . . . 13 6.4. 6.4 manifest.json . . . . . . . . . . . . . . . . . . . . 13 6.5. 6.5 session_sig.txt . . . . . . . . . . . . . . . . . . . 14 6.6. 6.6 public_key.pem . . . . . . . . . . . . . . . . . . . 14 Stone Expires 8 March 2027 [Page 2] Internet-Draft AIVS September 2026 6.7. 6.7 verify.py . . . . . . . . . . . . . . . . . . . . . . 14 6.8. 6.8 Bundle Chaining (optional) . . . . . . . . . . . . . 14 6.9. 6.9 Merkle Tree (optional) . . . . . . . . . . . . . . . 15 7. 7. AIVS-Micro . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. 7.1 Purpose and Use Cases . . . . . . . . . . . . . . . . 15 7.2. 7.2 Micro Proof Format . . . . . . . . . . . . . . . . . 16 7.3. 7.3 Field Definitions . . . . . . . . . . . . . . . . . . 16 7.4. 7.4 Canonical Payload for Signing . . . . . . . . . . . . 17 7.5. 7.5 Micro Proof Verification . . . . . . . . . . . . . . 17 7.6. 7.6 Relationship to Full Bundle . . . . . . . . . . . . . 18 8. 8. Verification Algorithm . . . . . . . . . . . . . . . . . 19 8.1. 8.1 Hash Chain Verification (REQUIRED, stdlib only) . . . 19 8.2. 8.2 Ed25519 Signature Verification (OPTIONAL, requires cryptography) . . . . . . . . . . . . . . . . . . . . . . 19 8.3. 8.3 Exit Codes . . . . . . . . . . . . . . . . . . . . . 20 9. 9. Security Considerations . . . . . . . . . . . . . . . . . 20 9.1. 9.1 What AIVS Proves . . . . . . . . . . . . . . . . . . 20 9.2. 9.2 What AIVS Does NOT Prove . . . . . . . . . . . . . . 20 9.3. 9.3 Threat Model . . . . . . . . . . . . . . . . . . . . 21 9.4. 9.4 Recommended Extensions for High-Assurance Use . . . . 22 10. 10. IANA Considerations . . . . . . . . . . . . . . . . . . 22 11. 11. References . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Informative . . . . . . . . . . . . . . . . . . . . . . 23 12. Appendix A: Reference Implementation . . . . . . . . . . . . 23 13. Appendix B: Example verify.py Output . . . . . . . . . . . . 24 14. Appendix C: Comparison with Related Formats . . . . . . . . . 25 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 25 15.1. v1.1 (refreshed 2026-09-04) . . . . . . . . . . . . . . 26 15.2. v1.1 (2026-04-16) . . . . . . . . . . . . . . . . . . . 26 15.3. v1.0 (2026-03-14) . . . . . . . . . . . . . . . . . . . 26 15.4. v0.1 (2026-03-12) . . . . . . . . . . . . . . . . . . . 26 1. 1. Motivation 1.1. 1.1 Problem Statement AI agents increasingly perform consequential actions on behalf of humans: navigating websites, filling forms, executing JavaScript, extracting data, and making purchases. Existing observability platforms (OpenTelemetry, LangSmith, Langfuse) log these actions but provide no cryptographic guarantees that the logs are complete, unmodified, or authentic. Regulatory frameworks mandate audit trails but do not prescribe formats: Stone Expires 8 March 2027 [Page 3] Internet-Draft AIVS September 2026 * *EU AI Act Article 19* requires automatically generated logs for high-risk AI systems but specifies no format. * *ISO/IEC 42001:2023 Annex A.6.2.8* requires event logging but defines no data structure. * *NIST AI RMF* requires documentation and audit trails but deliberately avoids prescribing formats. This creates a gap: organizations that must prove what their AI agents did have no standard way to produce, exchange, or verify that proof. 1.2. 1.2 Design Goals +=================+===========================================+ | Goal | Rationale | +=================+===========================================+ | Self-verifiable | Proof bundles must be verifiable without | | | contacting any server, blockchain, or | | | authority. | +-----------------+-------------------------------------------+ | Portable | A single file that can be emailed, | | | stored, or submitted to any system. | +-----------------+-------------------------------------------+ | Tamper-evident | Modifying any action in the log must be | | | detectable. | +-----------------+-------------------------------------------+ | Zero | Verification must require only Python 3 | | dependencies | standard library. Signature verification | | | MAY use the cryptography library. | +-----------------+-------------------------------------------+ | Session-level | Covers an entire session (sequence of | | | actions), not individual action receipts. | +-----------------+-------------------------------------------+ | Lightweight | AIVS-Micro provides a ~200-byte | | profile | attestation for high-frequency monitoring | | | without full bundle overhead. | +-----------------+-------------------------------------------+ | Domain-agnostic | Applicable to any AI agent performing any | | | type of action, not limited to commerce, | | | trading, or specific tools. | +-----------------+-------------------------------------------+ Table 1 Stone Expires 8 March 2027 [Page 4] Internet-Draft AIVS September 2026 1.3. 1.3 Relationship to Existing Standards AIVS is complementary to, not competitive with, existing work: +===============+===============+=================================+ | Standard | Scope | AIVS Relationship | +===============+===============+=================================+ | W3C | Identity | AIVS bundles could be wrapped | | Verifiable | claims | as a VC credentialSubject | | Credentials | | | | 2.0 | | | +---------------+---------------+---------------------------------+ | W3C Data | Ed25519 VC | AIVS identities MAY be | | Integrity | proof format | represented with | | EdDSA v1.0 | | DataIntegrityProof using eddsa- | | | | jcs-2022 | +---------------+---------------+---------------------------------+ | IETF SCITT | Supply chain | AIVS bundles could be | | (draft-ietf- | transparency | registered as SCITT signed | | scitt- | logs | statements | | architecture) | | | +---------------+---------------+---------------------------------+ | C2PA v2.2 | Media asset | AIVS applies the same manifest- | | | provenance | chain concept to agent actions | +---------------+---------------+---------------------------------+ | VAP (draft- | AI decision | AIVS covers interactive agent | | ailex-vap- | provenance | sessions (browser, tool calls); | | legal-ai- | for regulated | VAP covers model decision | | provenance) | industries | trails for legal/regulatory | | | | filing. Non-overlapping scope. | +---------------+---------------+---------------------------------+ | Agent Action | Individual | AIVS provides session-level | | Receipts | action | aggregation of action-level | | (AAR) | receipts | records | +---------------+---------------+---------------------------------+ | Certificate | Append-only | AIVS's hash chain is a | | Transparency | Merkle logs | simplified linear variant; | | (RFC 6962) | | Merkle tree extension is | | | | possible | +---------------+---------------+---------------------------------+ | EU AI Act | Audit log | AIVS is a concrete format that | | Article 19 | requirements | satisfies Article 19's content | | | | requirements | +---------------+---------------+---------------------------------+ Table 2 Stone Expires 8 March 2027 [Page 5] Internet-Draft AIVS September 2026 2. 2. Terminology +============+======================================================+ | Term | Definition | +============+======================================================+ | Session | A bounded sequence of actions performed by a single | | | AI agent instance, identified by a session_id. | +------------+------------------------------------------------------+ | Action | A single operation performed by the agent (e.g., | | | navigate to URL, click element, execute | | | JavaScript). | +------------+------------------------------------------------------+ | Audit Row | A JSON object recording one action with its inputs, | | | outputs, timestamp, cost, and hash chain fields. | +------------+------------------------------------------------------+ | Hash Chain | A sequence of audit rows where each row's hash | | | depends on the previous row's hash, forming a | | | tamper-evident chain. | +------------+------------------------------------------------------+ | Chain Hash | A single SHA-256 hash computed over all row hashes, | | | serving as a fingerprint of the entire session. | +------------+------------------------------------------------------+ | Proof | A .tar.gz archive containing the audit log, | | Bundle | signature, manifest, public key, and verifier | | | script. Also called an AIVS Full Bundle. | +------------+------------------------------------------------------+ | AIVS-Micro | A minimal 6-field JSON proof (~200 bytes) for a | | | single-URL scan attestation. | +------------+------------------------------------------------------+ | Identity | An Ed25519 keypair used to sign the chain hash or | | Key | micro-proof payload. | +------------+------------------------------------------------------+ | Scanner | SHA-256 of the scanner implementation file, binding | | Version | a proof to a specific code version. | | Hash | | +------------+------------------------------------------------------+ Table 3 3. 3. Hash Chain Specification 3.1. 3.1 Row Hash Computation Each audit row is identified by a deterministic SHA-256 hash. The hash input is a canonical JSON object serialized with sorted keys, no whitespace, UTF-8 encoding: Stone Expires 8 March 2027 [Page 6] Internet-Draft AIVS September 2026 row_hash = SHA-256( canonical_json({ "row_id": row_id, "session_id": session_id, "action_type": action_type, "tool_name": tool_name, "cost_cents": cost_cents, "timestamp": timestamp, "prev_hash": prev_hash }) ) Where canonical_json means: object keys sorted alphabetically, no whitespace between tokens, UTF-8 encoding, no trailing newline. The hash is represented as a lowercase hexadecimal string (64 characters). *Migration note (v1.0 → v1.1):* Prior to v1.1, the hash input used colon-separated field concatenation. Implementations MUST check the aivs_version field in manifest.json to determine which serialization to apply during verification. 3.2. 3.2 Field Definitions +=============+=========+===========================================+ | Field | Type | Description | +=============+=========+===========================================+ | row_id | Integer | Monotonically increasing row | | | | identifier (1-indexed). | +-------------+---------+-------------------------------------------+ | session_id | String | Unique identifier for the session. | +-------------+---------+-------------------------------------------+ | action_type | String | Classification of the action. | | | | Default: "tool_call". | +-------------+---------+-------------------------------------------+ | tool_name | String | Namespaced tool identifier (e.g., | | | | "browser.navigate", "browser.eval"). | +-------------+---------+-------------------------------------------+ | cost_cents | Integer | Cost of the action in cents. 0 for | | | | free actions. | +-------------+---------+-------------------------------------------+ | timestamp | Float | Unix timestamp with fractional | | | | seconds (e.g., 1710252645.123456). | +-------------+---------+-------------------------------------------+ | prev_hash | String | The row_hash of the immediately | | | | preceding row. Empty string "" for | | | | the first row. | Stone Expires 8 March 2027 [Page 7] Internet-Draft AIVS September 2026 +-------------+---------+-------------------------------------------+ Table 4 3.3. 3.3 Chain Integrity Property For a chain of N rows, modifying any field of row K invalidates row_hash[K], which invalidates prev_hash[K+1], which invalidates row_hash[K+1], and so on through row_hash[N]. This means: * *Insertion* of a row is detectable (changes all subsequent row_id values and hashes). * *Deletion* of a row is detectable (breaks the prev_hash link). * *Reordering* of rows is detectable (changes prev_hash linkage). * *Modification* of any field is detectable (changes the affected row's hash and all subsequent hashes). 3.4. 3.4 Chain Hash Computation The chain hash is a single SHA-256 hash that fingerprints the entire session: If rows is empty: chain_hash = SHA-256(b"empty") Else: combined = concatenate(row_hash[1], row_hash[2], ..., row_hash[N]) chain_hash = SHA-256(combined.encode("utf-8")) The chain hash is represented as a lowercase hexadecimal string (64 characters). 4. 4. Audit Row Schema Each row in the audit log is a JSON object with the following fields: Stone Expires 8 March 2027 [Page 8] Internet-Draft AIVS September 2026 { "id": 1, "session_id": "sess-abc123", "action_type": "tool_call", "tool_name": "browser.navigate", "inputs_json": "{\"url\": \"https://example.com\"}", "outputs_json": "{\"title\": \"Example Domain\", \"url\": \"https://example.com/\"}", "cost_cents": 0, "error": "", "timestamp": 1710252645.123456, "prev_hash": "", "row_hash": "a1b2c3d4e5f6..." } 4.1. 4.1 Field Specifications +==============+=========+==========+=============================+ | Field | Type | Required | Description | +==============+=========+==========+=============================+ | id | Integer | Yes | Row identifier, 1-indexed, | | | | | monotonically increasing. | +--------------+---------+----------+-----------------------------+ | session_id | String | Yes | Session identifier. | +--------------+---------+----------+-----------------------------+ | action_type | String | Yes | Action classification. | +--------------+---------+----------+-----------------------------+ | tool_name | String | Yes | Namespaced tool identifier. | +--------------+---------+----------+-----------------------------+ | inputs_json | String | Yes | JSON-encoded action inputs. | | | | | Sensitive keys MUST be | | | | | redacted (see Section 4.2). | +--------------+---------+----------+-----------------------------+ | outputs_json | String | Yes | JSON-encoded action | | | | | outputs. MAY be truncated. | +--------------+---------+----------+-----------------------------+ | cost_cents | Integer | Yes | Action cost in cents. | +--------------+---------+----------+-----------------------------+ | error | String | Yes | Error message if the action | | | | | failed; empty string if | | | | | successful. | +--------------+---------+----------+-----------------------------+ | timestamp | Float | Yes | Unix timestamp with | | | | | fractional seconds. | +--------------+---------+----------+-----------------------------+ | prev_hash | String | Yes | Previous row's row_hash. | | | | | Empty string for the first | | | | | row. | +--------------+---------+----------+-----------------------------+ Stone Expires 8 March 2027 [Page 9] Internet-Draft AIVS September 2026 | row_hash | String | Yes | This row's computed SHA-256 | | | | | hash (see Section 3.1). | +--------------+---------+----------+-----------------------------+ Table 5 4.2. 4.2 Sensitive Input Redaction Before computing the row hash, implementations MUST redact values for input keys matching any of the following case-insensitive substrings: password, token, api_key, secret, key, authorization, bearer, credential, passwd, passphrase Redacted values MUST be replaced with the string "[REDACTED]". 4.3. 4.3 Output Truncation Implementations MAY truncate outputs_json to a maximum length. The reference implementation truncates to 2000 characters. Truncation does not affect the hash chain because outputs_json is not included in the row hash computation. | *Note:* Only the seven fields listed in Section 3.1 are included | in the hash computation. inputs_json, outputs_json, and error are | included in the audit log for informational purposes but are NOT | part of the hash chain. This is intentional: it allows output | truncation and input redaction without breaking the chain. 4.4. 4.4 JavaScript Source Storage (eval actions) When an agent executes JavaScript, implementations SHOULD store the full JavaScript source verbatim in inputs_json under the key "js_code", along with a "code_hash" field containing the SHA-256 of the source. This provides cryptographic proof of exactly what code ran — not merely that JavaScript was executed. The js_code field is informational and is NOT included in the row hash computation. { "tool_name": "browser.eval", "inputs_json": "{\"js_code\": \"document.querySelectorAll('h1').length\", \"code_hash\": \"a1b2c3d4...\"}" } Stone Expires 8 March 2027 [Page 10] Internet-Draft AIVS September 2026 5. 5. Ed25519 Signature 5.1. 5.1 Signing The chain hash (Section 3.4) is signed using an Ed25519 private key: signature_bytes = Ed25519_Sign(private_key, chain_hash.encode("utf-8")) signature_b64 = Base64_Encode(signature_bytes) The signature is 64 bytes (512 bits), encoded as a Base64 ASCII string. 5.2. 5.2 Identity Key +===========================+========================+ | Property | Value | +===========================+========================+ | Algorithm | Ed25519 (RFC 8032) | +---------------------------+------------------------+ | Private key size | 32 bytes | +---------------------------+------------------------+ | Public key size | 32 bytes | +---------------------------+------------------------+ | Storage format | Raw bytes (not PEM) | +---------------------------+------------------------+ | Public key representation | 64-character lowercase | | | hexadecimal string | +---------------------------+------------------------+ | File permissions | 0600 (owner read/write | | | only) | +---------------------------+------------------------+ Table 6 5.3. 5.3 Signature File Format The signature is stored in session_sig.txt as a plain text file: chain_hash:{64-char-hex-chain-hash} signature:{base64-encoded-signature} If signing is unavailable: chain_hash:{64-char-hex-chain-hash} # Ed25519 signing not available Stone Expires 8 March 2027 [Page 11] Internet-Draft AIVS September 2026 5.4. 5.4 Public Key File Format The public key is stored in public_key.pem as a plain text file: # Ed25519 public key: {64-char-hex-public-key} If no signing key is configured: # No signing key configured 5.5. 5.5 Signature is Optional Implementations MAY produce bundles without Ed25519 signatures. The hash chain provides tamper-evidence independent of the signature. The signature adds identity binding (proof of who produced the bundle). 6. 6. AIVS Full Bundle Format 6.1. 6.1 Archive Structure An AIVS Full Bundle is a gzip-compressed tar archive (.tar.gz) containing a single directory with five required files: aivs_proof_{session_prefix}_{unix_timestamp}.tar.gz └── session_proof/ ├── audit_log.jsonl # Hash-chained action log ├── manifest.json # Bundle metadata ├── session_sig.txt # Ed25519 signature ├── public_key.pem # Signer's public key └── verify.py # Self-contained verifier (stdlib only) Optional files (included when applicable): ├── previous_bundle_hash.txt # SHA-256 of predecessor bundle (scan chain) └── merkle_tree.json # Page-level Merkle tree (crawl proofs) 6.2. 6.2 Filename Convention aivs_proof_{session_id[0:8]}_{int(unix_timestamp)}.tar.gz * session_id[0:8]: First 8 characters of the session ID. * unix_timestamp: Integer Unix timestamp at export time. Stone Expires 8 March 2027 [Page 12] Internet-Draft AIVS September 2026 6.3. 6.3 audit_log.jsonl Newline-delimited JSON (JSONL). Each line is one audit row (Section 4) serialized as a JSON object. Rows MUST be ordered by id ascending (chronological order). 6.4. 6.4 manifest.json A JSON object with the following fields: { "session_id": "sess-abc123", "exported_at": "2026-03-14T15:30:45Z", "action_count": 42, "chain_hash": "a1b2c3d4...", "aivs_version": "1.0", "generator": "Conduit", "generator_url": "https://github.com/bkauto3/Conduit" } +===============+=========+==========+=========================+ | Field | Type | Required | Description | +===============+=========+==========+=========================+ | session_id | String | Yes | The session identifier. | +---------------+---------+----------+-------------------------+ | exported_at | String | Yes | ISO 8601 UTC timestamp | | | | | (YYYY-MM-DDTHH:MM:SSZ). | +---------------+---------+----------+-------------------------+ | action_count | Integer | Yes | Number of rows in | | | | | audit_log.jsonl. | +---------------+---------+----------+-------------------------+ | chain_hash | String | Yes | 64-character hex chain | | | | | hash (Section 3.4). | +---------------+---------+----------+-------------------------+ | aivs_version | String | Yes | AIVS specification | | | | | version (e.g. "1.0"). | +---------------+---------+----------+-------------------------+ | generator | String | No | Name of the producing | | | | | software. | +---------------+---------+----------+-------------------------+ | generator_url | String | No | URL of the producing | | | | | software. | +---------------+---------+----------+-------------------------+ Table 7 Implementations MAY include additional metadata fields in the manifest. Verifiers MUST ignore unrecognized fields. Stone Expires 8 March 2027 [Page 13] Internet-Draft AIVS September 2026 6.5. 6.5 session_sig.txt See Section 5.3. 6.6. 6.6 public_key.pem See Section 5.4. 6.7. 6.7 verify.py A self-contained Python 3 verification script. Requirements: * MUST verify the hash chain using only Python 3 standard library (hashlib, json, sys, pathlib). * MAY verify the Ed25519 signature if the cryptography library is available. * MUST exit with code 0 on successful verification. * MUST exit with code 1 if the hash chain is broken or the signature is invalid. * MUST print human-readable verification results to stdout. *Deployment note:* The embedded verify.py is intended for ad-hoc verification by recipients without specialized tooling. Enterprise environments where executing bundled scripts is prohibited by policy SHOULD use the separately distributed reference implementation at https://github.com/swarmsync-ai/aivs-spec/tree/main/verifier/ instead. The reference verifier is functionally identical but distributed through standard package management channels and subject to organizational security review processes. The proof bundle remains verifiable by either path. The embedded verifier is the core differentiator of AIVS: any recipient can verify the bundle by running python verify.py with no installation, no network access, and no trust in external services. 6.8. 6.8 Bundle Chaining (optional) When a session produces multiple sequential bundles (e.g., repeated scans of the same target), each bundle MAY reference its predecessor: * previous_bundle_hash.txt: Contains the SHA-256 hex digest of the prior .tar.gz file. Stone Expires 8 March 2027 [Page 14] Internet-Draft AIVS September 2026 * The manifest.json SHOULD include a "previous_bundle_hash" field with the same value. This forms a scan chain: a tamper-evident sequence of bundles where each bundle cryptographically references its predecessor. 6.9. 6.9 Merkle Tree (optional) For multi-page crawl sessions, implementations MAY include merkle_tree.json to enable selective page verification: { "root": "abc123...", "leaf_count": 20, "pages": [ {"url": "https://example.com/", "hash": "def456...", "leaf_index": 0}, {"url": "https://example.com/about", "hash": "ghi789...", "leaf_index": 1} ], "tree": [["def456...", "ghi789...", ...], ["parent1...", ...], ["root..."]] } The Merkle tree is a binary tree over page content hashes. Internal nodes are computed as: parent = SHA-256((left_hash + right_hash).encode("utf-8")) Odd leaves are duplicated (paired with themselves). The root is included in manifest.json as "merkle_root". 7. 7. AIVS-Micro AIVS-Micro is a minimal single-URL scan attestation. It is the smallest meaningful cryptographic proof — approximately 200 bytes — designed for use cases where a full session bundle is impractical: continuous monitoring, embedded score widgets, API responses, DNS TXT record verification, and cold outreach proof attachments. 7.1. 7.1 Purpose and Use Cases +============================+=============================+ | Use Case | Why Micro | +============================+=============================+ | Continuous page monitoring | Full bundles at high | | (15-min intervals) | frequency are too large | +----------------------------+-----------------------------+ | Embedded score badge / | API response must be | | live widget | lightweight | +----------------------------+-----------------------------+ Stone Expires 8 March 2027 [Page 15] Internet-Draft AIVS September 2026 | Cold outreach proof | Recipient needs verifiable | | attachment | proof, not a full audit log | +----------------------------+-----------------------------+ | DNS TXT record | Record size limits require | | verification | minimal format | +----------------------------+-----------------------------+ | API responses asserting | ~200 bytes fits inline in | | scan freshness | any JSON response | +----------------------------+-----------------------------+ Table 8 A third party with the signer's Ed25519 public key can verify from an AIVS-Micro proof: * The scan happened at the stated time * The page DOM was in the stated state at that time * The scan was performed by the declared scanner instance (via scanner version hash) 7.2. 7.2 Micro Proof Format An AIVS-Micro proof is a JSON object with exactly six fields: { "url": "https://example.com", "dom_hash": "sha256:a1b2c3d4e5f6...", "timestamp": "2026-03-14T10:22:01.000000000Z", "signature": "ed25519:BASE64_ENCODED_SIGNATURE", "scanner_version_hash": "sha256:def456...", "scan_origin": "local" } 7.3. 7.3 Field Definitions +======================+======+========+===========================+ | Field |Type |Required| Description | +======================+======+========+===========================+ | url |String|Yes | The URL that was scanned. | +----------------------+------+--------+---------------------------+ | dom_hash |String|Yes | SHA-256 of the page DOM | | | | | content, prefixed with | | | | | "sha256:". | +----------------------+------+--------+---------------------------+ | timestamp |String|Yes | ISO 8601 UTC timestamp | | | | | with nanosecond precision | Stone Expires 8 March 2027 [Page 16] Internet-Draft AIVS September 2026 | | | | (YYYY-MM- | | | | | DDTHH:MM:SS.nnnnnnnnnZ). | +----------------------+------+--------+---------------------------+ | signature |String|Yes | Ed25519 signature over | | | | | the canonical payload | | | | | (Section 7.4), prefixed | | | | | with "ed25519:" and | | | | | Base64-encoded. Value is | | | | | "unsigned" if no identity | | | | | key is available. | +----------------------+------+--------+---------------------------+ | scanner_version_hash |String|Yes | SHA-256 of the scanner | | | | | implementation file, | | | | | prefixed with "sha256:". | | | | | Binds the proof to a | | | | | specific code version. | +----------------------+------+--------+---------------------------+ | scan_origin |String|Yes | Where the scan | | | | | originated. | | | | | Implementations SHOULD | | | | | use "local" for on-device | | | | | scans. | +----------------------+------+--------+---------------------------+ Table 9 7.4. 7.4 Canonical Payload for Signing The Ed25519 signature is computed over the following pipe-delimited string, encoded as UTF-8: {url}|{dom_hash}|{timestamp}|{scanner_version_hash}|{scan_origin} All fields are used verbatim (including the "sha256:" prefix on dom_hash and scanner_version_hash). 7.5. 7.5 Micro Proof Verification Stone Expires 8 March 2027 [Page 17] Internet-Draft AIVS September 2026 Input: micro_proof JSON object, signer's Ed25519 public key (hex) 1. Reconstruct canonical payload: payload = "{url}|{dom_hash}|{timestamp}|{scanner_version_hash}|{scan_origin}" 2. Decode signature: sig_b64 = micro_proof["signature"].removeprefix("ed25519:") sig_bytes = Base64_Decode(sig_b64) 3. Verify: Ed25519_Verify(public_key, sig_bytes, payload.encode("utf-8")) 4. If verification succeeds: PASS 5. If verification fails: FAIL 6. If signature == "unsigned": SKIP (no identity binding) 7.6. 7.6 Relationship to Full Bundle AIVS-Micro and AIVS Full Bundles are complementary, not alternatives: +==============+==========================+=====================+ | Property | AIVS Full Bundle | AIVS-Micro | +==============+==========================+=====================+ | Contains | Complete action-by- | Single-URL scan | | | action log | attestation only | +--------------+--------------------------+---------------------+ | Size | Variable (scales with | ~200 bytes | | | session length) | | +--------------+--------------------------+---------------------+ | Verifier | Embedded verify.py | One Ed25519 verify | | | (stdlib only) | call | +--------------+--------------------------+---------------------+ | Frequency | One per agent session | Can be generated | | | | every scan interval | +--------------+--------------------------+---------------------+ | Use case | Legal evidence, detailed | Monitoring, badges, | | | audit, compliance filing | API responses, cold | | | | outreach | +--------------+--------------------------+---------------------+ | Offline | Yes (embedded verifier) | Yes (single crypto | | verification | | operation) | +--------------+--------------------------+---------------------+ Table 10 A single agent session MAY produce both: a full bundle for the complete audit trail, and one or more micro proofs for individual URLs visited during that session. Stone Expires 8 March 2027 [Page 18] Internet-Draft AIVS September 2026 8. 8. Verification Algorithm 8.1. 8.1 Hash Chain Verification (REQUIRED, stdlib only) Input: audit_log.jsonl Output: PASS or FAIL with row number prev_hash = "" for each row in audit_log.jsonl (ordered by id): expected = SHA-256( canonical_json({ "row_id": row.id, "session_id": row.session_id, "action_type": row.action_type, "tool_name": row.tool_name, "cost_cents": row.cost_cents, "timestamp": row.timestamp, "prev_hash": prev_hash }) ) if row.row_hash != expected: FAIL at row.id prev_hash = row.row_hash PASS: all {N} rows verified 8.2. 8.2 Ed25519 Signature Verification (OPTIONAL, requires cryptography) Input: session_sig.txt, public_key.pem Output: PASS, FAIL, or SKIP 1. Parse chain_hash and signature from session_sig.txt 2. Parse public key hex from public_key.pem 3. If public key is all zeros ("0" * 64), SKIP 4. Reconstruct Ed25519PublicKey from raw bytes 5. Verify: Ed25519_Verify(public_key, signature, chain_hash.encode("utf-8")) 6. If verification succeeds: PASS 7. If verification fails: FAIL (exit 1) 8. If cryptography library unavailable: SKIP with notice Stone Expires 8 March 2027 [Page 19] Internet-Draft AIVS September 2026 8.3. 8.3 Exit Codes +======+==========================================+ | Code | Meaning | +======+==========================================+ | 0 | Hash chain verified. Signature verified | | | (if present and library available). | +------+------------------------------------------+ | 1 | Hash chain broken OR signature invalid. | +------+------------------------------------------+ Table 11 9. 9. Security Considerations 9.1. 9.1 What AIVS Proves * *Integrity:* The sequence of actions has not been modified since the bundle was created. * *Completeness:* No actions have been inserted or deleted from the chain. * *Ordering:* Actions occurred in the recorded sequence. * *Identity* (with signature): The bundle was produced by the holder of a specific Ed25519 private key. * *Code provenance* (eval actions): The exact JavaScript source that executed is recorded verbatim. 9.2. 9.2 What AIVS Does NOT Prove * *Truthfulness:* AIVS does not prove that the recorded inputs/ outputs actually occurred. A malicious agent could fabricate actions and produce a valid chain. * *Origin integrity:* AIVS detects after-the-fact tampering but does not prevent fabrication at the point of origin. An agent that controls its own logging infrastructure can construct a fraudulent but internally consistent hash chain from the start. AIVS proof bundles are therefore only as trustworthy as the logging infrastructure that produces them. For high-assurance use cases, the logging process SHOULD be isolated from the agent (e.g., a separate trusted process, hardware security module, or third-party logging service). Stone Expires 8 March 2027 [Page 20] Internet-Draft AIVS September 2026 * *Timeliness:* Timestamps are self-reported. AIVS does not include external time attestation (e.g., RFC 3161). Implementations requiring trusted timestamps SHOULD layer RFC 3161 on top. * *Key authenticity:* AIVS does not include a PKI or certificate chain. The public key in the bundle is self-asserted. Implementations requiring key authenticity SHOULD use a separate trust registry or Verifiable Credentials. * *Non-repudiation:* Without a trusted timestamp and key binding to a real-world identity, AIVS provides limited non-repudiation. The signer could claim key compromise. 9.3. 9.3 Threat Model +=====================================+===========================+ | Threat | Mitigated By | +=====================================+===========================+ | Post-hoc modification of action log | Hash chain (Section 3) | +-------------------------------------+---------------------------+ | Deletion of actions | Sequential prev_hash | | | chaining | +-------------------------------------+---------------------------+ | Insertion of actions | Sequential row_id + | | | prev_hash chaining | +-------------------------------------+---------------------------+ | Reordering of actions | prev_hash depends on | | | previous row_hash | +-------------------------------------+---------------------------+ | Impersonation of agent identity | Ed25519 signature | | | (Section 5) | +-------------------------------------+---------------------------+ | Exposure of sensitive inputs | Mandatory redaction | | | (Section 4.2) | +-------------------------------------+---------------------------+ | Replay of old proof bundle | session_id + timestamp | | | provide uniqueness | +-------------------------------------+---------------------------+ | Unknown JS code execution | Verbatim JS source | | | storage (Section 4.4) | +-------------------------------------+---------------------------+ | Micro proof tampering | Ed25519 over all six | | | fields' canonical payload | +-------------------------------------+---------------------------+ Table 12 Stone Expires 8 March 2027 [Page 21] Internet-Draft AIVS September 2026 9.4. 9.4 Recommended Extensions for High-Assurance Use For use cases requiring stronger guarantees (legal evidence, financial compliance, regulatory submission): 1. *RFC 3161 Timestamps:* Submit the chain hash to an RFC 3161 Time Stamping Authority. 2. *SCITT Registration:* Register the signed chain hash as a SCITT transparent statement. 3. *Verifiable Credentials:* Wrap the proof bundle metadata as a W3C Verifiable Credential. 4. *Merkle Tree Aggregation:* For multi-session audits, aggregate chain hashes into a Merkle tree. 10. 10. IANA Considerations This specification defines no new IANA registries. The following existing standards are referenced: * SHA-256: FIPS 180-4 * Ed25519: RFC 8032 * JSON: RFC 8259 * JSONL: Newline-delimited JSON (de facto standard) * gzip: RFC 1952 * tar: POSIX.1-2001 11. 11. References 11.1. Normative * [RFC 8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017. * [FIPS 180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015. * [RFC 8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017. Stone Expires 8 March 2027 [Page 22] Internet-Draft AIVS September 2026 11.2. Informative * [RFC 6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013. * [RFC 3161] Adams, C., et al., "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. * [EU AI Act] Regulation (EU) 2024/1689 of the European Parliament, Article 19. * [ISO 42001] ISO/IEC 42001:2023, Information technology -- Artificial intelligence -- Management system. * [SCITT] draft-ietf-scitt-architecture-22, Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. * [W3C VC] W3C Verifiable Credentials Data Model v2.0, W3C Recommendation, May 2025. * [VC-DI-EDDSA] W3C, "Data Integrity EdDSA Cryptosuites v1.0", W3C Recommendation, May 2025. * [C2PA] Coalition for Content Provenance and Authenticity, C2PA Technical Specification v2.2. * [VAP] draft-ailex-vap-legal-ai-provenance-03, Verifiable AI Provenance Framework and Legal AI Profile, March 2026. * [AAR] Agent Action Receipts v1.0, https://github.com/Cyberweasel777/agent-action-receipt-spec. 12. Appendix A: Reference Implementation The reference implementation is located in the Conduit repository: Stone Expires 8 March 2027 [Page 23] Internet-Draft AIVS September 2026 +========================+=============================+ | Component | File | +========================+=============================+ | Hash chain (audit log) | audit.py | +------------------------+-----------------------------+ | Full bundle export | tools/conduit_proof.py — | | | ConduitProof.export() | +------------------------+-----------------------------+ | AIVS-Micro export | tools/conduit_proof.py — | | | ConduitProof.export_micro() | +------------------------+-----------------------------+ | Embedded verifier | VERIFY_PY constant in | | | tools/conduit_proof.py | +------------------------+-----------------------------+ | Ed25519 identity | tools/conduit_bridge.py — | | | ConduitIdentity | +------------------------+-----------------------------+ Table 13 *Full bundle:* from tools.conduit_proof import ConduitProof proof = ConduitProof(audit_log, session_id, public_key_pem, identity) result = proof.export(output_dir="/path/to/output") # Returns: {"success": True, "path": "...", "action_count": N, "chain_hash": "..."} *AIVS-Micro:* micro = proof.export_micro( url="https://example.com", dom_hash="a1b2c3d4...", scan_origin="local", ) # Returns: {"success": True, "micro_proof": {...}, "payload_signed": "..."} 13. Appendix B: Example verify.py Output $ cd session_proof && python verify.py Chain OK: 8 actions verified Signature OK: Ed25519 signature verified Session: sess-abc123 Exported: 2026-03-14T15:30:45Z Actions: 8 VERIFIED: This session proof is intact and unmodified. Stone Expires 8 March 2027 [Page 24] Internet-Draft AIVS September 2026 14. Appendix C: Comparison with Related Formats +============+==========+==========+==========+===========+============+============+ |Property |AIVS Full |AIVS-Micro|VAP/LAP |AAR |C2PA |SCITT | +============+==========+==========+==========+===========+============+============+ |Scope |Session |Single URL|AI model |Single |Media asset |Supply chain| | |(multi- |scan |decision |action |lifecycle |statement | | |action) | |provenance| | | | +------------+----------+----------+----------+-----------+------------+------------+ |Self- |Yes |Yes (one |No (HTTP |No |No (requires|No (requires| |verifiable |(embedded |Ed25519 |API | |SDK) |transparency| | |verify.py)|call) |required) | | |service) | +------------+----------+----------+----------+-----------+------------+------------+ |Offline |Yes |Yes |No |Yes |Partial |No | |verification| | | | | | | +------------+----------+----------+----------+-----------+------------+------------+ |Zero |Yes |Yes (one |No |No |No (requires|No | |dependencies|(stdlib |crypto | |(requires |SDK) | | | |Python) |call) | |SDK) | | | +------------+----------+----------+----------+-----------+------------+------------+ |Hash chain |SHA-256 |N/A |SHA-256 |No |Hash binding|Merkle tree | | |linear |(single |per-event |(individual| | | | |chain |proof) |+ Merkle |signatures)| | | +------------+----------+----------+----------+-----------+------------+------------+ |Signature |Ed25519 |Ed25519 |Ed25519 |Ed25519 |X.509 |COSE | | |(optional)|(optional)|(required)|(required) |certificates|signatures | +------------+----------+----------+----------+-----------+------------+------------+ |Portable |.tar.gz |JSON |.zip |JSON |JUMBF |COSE | |archive | |object | | | | | +------------+----------+----------+----------+-----------+------------+------------+ |Interactive |Yes |Yes |No |Yes |No |No | |agent | | | | | | | |sessions | | | | | | | +------------+----------+----------+----------+-----------+------------+------------+ |JS source in|Yes (eval |No |No |No |No |No | |chain |actions) | | | | | | +------------+----------+----------+----------+-----------+------------+------------+ |Domain |Any agent |Any URL |Legal/ |Any agent |Media |Supply chain| | |action |scan |regulated |action |content |artifacts | | | | |AI | | | | +------------+----------+----------+----------+-----------+------------+------------+ Table 14 15. Changelog Stone Expires 8 March 2027 [Page 25] Internet-Draft AIVS September 2026 15.1. v1.1 (refreshed 2026-09-04) * Added current W3C Data Integrity EdDSA relationship; protocol wire format unchanged. * Retained canonical JSON hash computation introduced in April 2026. 15.2. v1.1 (2026-04-16) * Section 3.1: Replaced colon-separated field concatenation with canonical JSON serialization for hash computation to eliminate field-value collision vulnerability. * Section 6.7: Added deployment note for enterprise environments where executing bundled scripts is policy-prohibited. * Section 9.2: Added explicit Origin Integrity limitation documenting fabrication-at-origin concern. 15.3. v1.0 (2026-03-14) * Renamed from CSPF (Conduit Session Proof Format) to AIVS (Agentic Integrity Verification Standard). * Added Section 7: AIVS-Micro — minimal 6-field scan attestation for continuous monitoring. * Added Section 4.4: JavaScript source storage semantics for eval actions. * Added Section 6.8: Bundle chaining (scan chain) specification. * Added Section 6.9: Merkle tree specification for crawl proofs. * Added VAP/LAP to Section 1.3 relationship table and Appendix C comparison. * Updated aivs_version field in manifest.json schema. * Updated filename convention from conduit_proof_* to aivs_proof_*. 15.4. v0.1 (2026-03-12) * Initial specification as CSPF v1.0. Stone Expires 8 March 2027 [Page 26]