AIVS: Agentic Integrity Verification Standard SwarmSync.AI
benstone@swarmsync.ai https://swarmsync.ai
Applications Individual Submission AI agents audit log integrity verification Ed25519 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)
1. Motivation
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:
  • 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 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 dependencies Verification must require only Python 3 standard library. Signature verification MAY use the cryptography library.
Session-level Covers an entire session (sequence of actions), not individual action receipts.
Lightweight profile AIVS-Micro provides a ~200-byte 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.
1.3 Relationship to Existing Standards AIVS is complementary to, not competitive with, existing work:
Standard Scope AIVS Relationship
W3C Verifiable Credentials 2.0 Identity claims AIVS bundles could be wrapped as a VC credentialSubject
W3C Data Integrity EdDSA v1.0 Ed25519 VC proof format AIVS identities MAY be represented with DataIntegrityProof using eddsa-jcs-2022
IETF SCITT (draft-ietf-scitt-architecture) Supply chain transparency logs AIVS bundles could be registered as SCITT signed statements
C2PA v2.2 Media asset provenance AIVS applies the same manifest-chain concept to agent actions
VAP (draft-ailex-vap-legal-ai-provenance) AI decision provenance for regulated industries AIVS covers interactive agent sessions (browser, tool calls); VAP covers model decision trails for legal/regulatory filing. Non-overlapping scope.
Agent Action Receipts (AAR) Individual action receipts AIVS provides session-level aggregation of action-level records
Certificate Transparency (RFC 6962) Append-only Merkle logs AIVS's hash chain is a simplified linear variant; Merkle tree extension is possible
EU AI Act Article 19 Audit log requirements AIVS is a concrete format that satisfies Article 19's content requirements
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 Bundle A .tar.gz archive containing the audit log, 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 Key An Ed25519 keypair used to sign the chain hash or micro-proof payload.
Scanner Version Hash SHA-256 of the scanner implementation file, binding a proof to a specific code version.
3. Hash Chain Specification
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: 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 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.
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 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. Audit Row Schema Each row in the audit log is a JSON object with the following fields: { "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 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.
row_hash String Yes This row's computed SHA-256 hash (see Section 3.1).
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 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 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...\"}" }
5. Ed25519 Signature
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 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)
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
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 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. AIVS Full Bundle Format
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 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.
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 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.
Implementations MAY include additional metadata fields in the manifest. Verifiers MUST ignore unrecognized fields.
6.5 session_sig.txt See Section 5.3.
6.6 public_key.pem See Section 5.4.
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 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.
  • 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 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. 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 Purpose and Use Cases
Use Case Why Micro
Continuous page monitoring (15-min intervals) Full bundles at high frequency are too large
Embedded score badge / live widget API response must be lightweight
Cold outreach proof attachment Recipient needs verifiable proof, not a full audit log
DNS TXT record verification Record size limits require minimal format
API responses asserting scan freshness ~200 bytes fits inline in any JSON response
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 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 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 (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.
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 Micro Proof Verification 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 Relationship to Full Bundle AIVS-Micro and AIVS Full Bundles are complementary, not alternatives:
Property AIVS Full Bundle AIVS-Micro
Contains Complete action-by-action log Single-URL scan attestation only
Size Variable (scales with session length) ~200 bytes
Verifier Embedded verify.py (stdlib only) One Ed25519 verify call
Frequency One per agent session Can be generated every scan interval
Use case Legal evidence, detailed audit, compliance filing Monitoring, badges, API responses, cold outreach
Offline verification Yes (embedded verifier) Yes (single crypto operation)
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.
8. Verification Algorithm
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 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
8.3 Exit Codes
Code Meaning
0 Hash chain verified. Signature verified (if present and library available).
1 Hash chain broken OR signature invalid.
9. Security Considerations
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 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).
  • 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 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
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. 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. References
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.
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.
Appendix A: Reference Implementation The reference implementation is located in the Conduit repository:
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
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": "..."}
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.
Appendix C: Comparison with Related Formats
Property AIVS Full AIVS-Micro VAP/LAP AAR C2PA SCITT
Scope Session (multi-action) Single URL scan AI model decision provenance Single action Media asset lifecycle Supply chain statement
Self-verifiable Yes (embedded verify.py) Yes (one Ed25519 call) No (HTTP API required) No No (requires SDK) No (requires transparency service)
Offline verification Yes Yes No Yes Partial No
Zero dependencies Yes (stdlib Python) Yes (one crypto call) No No (requires SDK) No (requires SDK) No
Hash chain SHA-256 linear chain N/A (single proof) SHA-256 per-event + Merkle No (individual signatures) Hash binding Merkle tree
Signature Ed25519 (optional) Ed25519 (optional) Ed25519 (required) Ed25519 (required) X.509 certificates COSE signatures
Portable archive .tar.gz JSON object .zip JSON JUMBF COSE
Interactive agent sessions Yes Yes No Yes No No
JS source in chain Yes (eval actions) No No No No No
Domain Any agent action Any URL scan Legal/regulated AI Any agent action Media content Supply chain artifacts
Changelog
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.
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.
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_*.
v0.1 (2026-03-12)
  • Initial specification as CSPF v1.0.