> ## Documentation Index
> Fetch the complete documentation index at: https://mwillaimission.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Warning>
  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.
</Warning>

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.

```json theme={null}
{
  "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.

```text theme={null}
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.

<Note>
  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.
</Note>

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.