Audit Chain: Liability-Grade Agent Transaction Logging

Discover how AgentLedger’s Audit Chain records every consequential agent action for dispute resolution, liability attribution, and EU AI Act compliance.

Every consequential action an agent takes on behalf of a user — booking a flight, executing a payment, signing a document — must be attributable. Without a tamper-proof record of what happened, you cannot resolve disputes, assign liability, or satisfy regulatory requirements. AgentLedger’s Audit Chain provides exactly that: an immutable, PII-stripped log of agent actions that threads from user intent through agent decision to service response, linked cryptographically to the Trust Ledger entry that authorized each action.

Why the Audit Chain must exist from day one

The Audit Chain cannot be constructed after the fact. It must be present from the first agent transaction. Insurance products, governance frameworks, and EU AI Act compliance (enforcement August 2026) all depend on it — retroactive reconstruction is not legally or technically valid.

You cannot backfill an audit trail. The evidentiary value of an audit record depends on its contemporaneous capture. If you begin logging after your first transactions, those early transactions are unattributable — and that gap will matter when a dispute, a regulator, or an insurer asks for the complete record.

Anatomy of an audit record

Each audit record captures the full chain of custody from user intent through agent action to service response. The trust_ledger_ref field links every agent action to the Trust Ledger entry that authorized it, creating an unbroken cryptographic chain of custody.

{
  "record_id": "uuid-v4",
  "timestamp": "2026-04-10T14:32:00Z",
  "agent": {
    "verified_identity": "agent-id-from-layer-2",
    "platform": "claude-sonnet-4"
  },
  "service": {
    "id": "uuid-of-service",
    "manifest_version": "1.2.0",
    "manifest_hash": "sha256:..."
  },
  "action": {
    "capability_invoked": "travel.air.book",
    "context_provided": "[REDACTED — PII stripped]",
    "outcome": "success",
    "confirmation_id": "FLIGHT-ABC123"
  },
  "trust_ledger_ref": {
    "attestation_hash": "sha256:...",
    "ledger_block": 847291
  }
}

The manifest_hash field in the service block records exactly which version of the service’s manifest was active at the time of the action — so you can prove what the service declared, not just what it does today.

What the Audit Chain enables

Use case	How
Dispute resolution	Prove exactly what capability was invoked and what the service declared at that moment
Liability attribution	Determine whether failure was agent error, service error, or misrepresentation
Regulatory compliance	EU AI Act requires transparency and auditability records for high-risk AI systems
Insurance products	Actuarial data for agent action liability insurance (Layer 6)
Refund processing	Verified outcome records support automated refund triggers

The liability layer connection

The Audit Chain is the infrastructure prerequisite for Layer 6: Liability — where insurance products and governance frameworks for autonomous agent actions will eventually be built. Without complete audit records, no insurer can underwrite agent actions and no governance framework can assign responsibility.

Layer 6: Liability (insurance, governance)     ← depends on Layer 5
Layer 5: Orchestration & Taste                 ← depends on Layer 4
Layer 4: Context Matching                      ← depends on Layer 3
Layer 3: Trust & Verification                  ← depends on Layer 2
Layer 2: Identity & Attestation                ← depends on Layer 1
Layer 1: Discovery & Distribution              ← BUILT FIRST
         ↑
    Audit Chain threads through all layers

The Audit Chain is not a feature of one layer — it threads through all of them. Every layer that produces a consequential action contributes a record to the same chain.

Privacy design

Audit records are PII-stripped before storage. The context_provided field in each record contains only a cryptographic hash of the original context — enough to verify what was passed, not enough to reconstruct it. Full context reconstruction requires a key held only by the authorized user, not by AgentLedger.

PII stripping happens at ingestion time, before the record is written. The original context is never stored by AgentLedger. If you need to correlate an audit record with the original user context for dispute resolution, the authorized user must provide the decryption key.

This design means audit records are safe to expose to auditors, regulators, and insurers without disclosing personal data — the record proves what happened without revealing who the user was.