Implementation Guide

Compliance Evidence Export

When your auditor asks "prove that Agent X only accessed approved systems between January 1 and March 31," you need to produce verifiable evidence. This guide shows how to generate an export bundle, verify it offline, and deliver it as SOX/SOC 2 evidence.

Step 1: Generate the export bundle

An export bundle is a self-contained package of proof bundles, receipts, and a content-addressed manifest. It covers a specific audit window.

# Export all runs for a specific agent in a date range
clawsig export \
  --agent-did "did:key:z6Mkn...E7c7" \
  --from "2026-01-01" \
  --to "2026-03-31" \
  --output ./evidence/q1-2026-export.json

The export bundle includes:

  • Every proof bundle for runs in the window
  • All gateway and tool receipts referenced by those bundles
  • A manifest with SHA-256 hashes for every included file
  • A top-level Ed25519 signature over the manifest

Step 2: Verify offline

Run the verifier against the export bundle. This requires no network access and no API keys.

# Verify the export bundle
clawverify verify \
  --bundle ./evidence/q1-2026-export.json \
  --config ./clawverify.config.json \
  --output ./evidence/q1-2026-verify-report.json

The verification report contains:

  • PASS/FAIL verdict for each proof bundle
  • Machine-readable reason codes for any failures
  • Receipt count, event count, and coverage summary
  • Timestamp range and agent DID for each run

If any proof bundle fails verification, the export is flagged. Unknown schema versions or algorithms fail closed.

Step 3: Deliver to your auditor

Provide your auditor with:

  1. The export bundle JSON (q1-2026-export.json)
  2. The verification report (q1-2026-verify-report.json)
  3. The clawverify config (clawverify.config.json) — this is public, it just contains allowed DIDs
  4. Instructions to re-run verification independently (the auditor does not need platform access)

The auditor can re-run clawverify verify themselves using the same inputs. If the result matches, they have independent confirmation that the evidence is authentic and untampered.

Mapping to compliance frameworks

SOC 2 (Trust Services Criteria)

  • CC6.1 (logical access): CST scopes + token_scope_hash in receipts
  • CC7.2 (system monitoring): gateway receipts as monitoring evidence
  • CC8.1 (change management): commit.sig.json proofs on every PR

SOX (IT General Controls)

  • Access controls: Okta group → CST scope mapping
  • Change management: signed commits + Claw Verified PR pipeline
  • Monitoring: proof bundles as continuous control evidence

Related

Ready to implement this?

Take the assessment to map your stack, or review the Security Review Pack to prepare your security team.

Take the assessment Security Review Pack