SwarmSync.AI

benstone@swarmsync.ai

Applications Individual Submission AI agents audit log integrity verification hash chain Ed25519 proof bundle This document specifies the Agentic Integrity Verification Standard (AIVS), a portable, self-verifiable archive format for cryptographic proof of AI agent sessions. An AIVS proof 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 the Python 3 standard library to execute. AIVS also defines AIVS-Micro: a minimal six-field attestation (~200 bytes) for continuous monitoring and API contexts where a full session bundle is not required. AIVS enables any party to independently verify that every action in an agent session is accounted for and unmodified, that no actions have been inserted, deleted, or reordered, and that the session was produced by a specific cryptographic identity — entirely offline, without installing any software beyond Python 3.

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: 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.

Each audit row is identified by a deterministic SHA-256 hash. The hash input is a colon-separated string of exactly seven fields in this order:

The hash is represented as a lowercase hexadecimal string (64 characters).

For a chain of N rows, modifying any field of row K invalidates row_hash[K], which invalidates prev_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).

The chain hash is represented as a lowercase hexadecimal string (64 characters).

Before computing the row hash, implementations MUST redact values for input keys matching any of the following case-insensitive substrings:

Redacted values MUST be replaced with the string "[REDACTED]".

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.

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).

The embedded verifier script MUST: Verify the hash chain using only Python 3 standard library (hashlib, json, sys, pathlib). Exit with code 0 on successful verification. Exit with code 1 if the hash chain is broken or the signature is invalid. Print human-readable verification results to stdout. The embedded verifier MAY verify the Ed25519 signature if the cryptography library is available.

When a session produces multiple sequential bundles, each bundle MAY reference its predecessor via previous_bundle_hash.txt, containing the SHA-256 hex digest of the prior .tar.gz file. This forms a scan chain: a tamper-evident sequence of bundles where each bundle cryptographically references its predecessor.

AIVS-Micro is a minimal single-URL scan attestation (~200 bytes) designed for use cases where a full session bundle is impractical: continuous monitoring, embedded score widgets, API responses, and DNS TXT record verification.

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.

Truthfulness: AIVS does not prove that the recorded inputs/outputs actually occurred. A malicious agent could fabricate actions and produce a valid chain. Timeliness: Timestamps are self-reported. 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.

This document defines no new IANA registries. The following existing standards are referenced: SHA-256 (FIPS 180-4), Ed25519 (RFC 8032), JSON (RFC 8259), gzip (RFC 1952).