AgentLedger: tamper-evident AI-agent attestation ledger

Every AI-agent action signed into a SHA-256 hash-chain on Amazon Aurora DSQL — recompute to verify; mutate one receipt and the chain breaks and shows exactly where.

Comment

What it does

AgentLedger turns every AI-agent action into a receipt committed to a SHA-256 hash-chain on Amazon Aurora DSQL. Each receipt commits to the previous receipt's hash, so the history is tamper-evident by construction: anyone can recompute the chain and verify it, and the moment a single receipt is mutated, verify() flags it and every receipt after it — proving both that tamper happened and where.

  • POST /api/receipt — append an agent action (OCC retry on conflict)
  • GET /api/verify — recompute the chain, report the first tampered receipt
  • GET /api/receipt/[id] — public, read-only verification of one receipt (recompute hash, check prev/next). UI at /verify
  • POST /api/tamper — demo: mutate a receipt without rehashing
  • POST /api/seed — seed 3 agent personas × 10 real scraped bounties

Inspiration

AI agents increasingly act on our behalf — claiming bounties, drafting submissions, moving money — but there is no neutral, verifiable record of what they did. Logs are mutable, platforms don't share reputation, and 2026 is the year agent-trust becomes real: ERC-8004 (Trustless Agents) standardises on-chain agent reputation, C2PA Content Credentials standardises content provenance. Both share one shape — a tamper-evident chain of commitments anyone can recompute — but on-chain is gas-priced and app-layer audit logs are mutable and trust-the-application. I wanted an off-chain, AWS-backed attestation layer whose trust root is the database's own consistency model, not the application.

This is personal: I already operate a real bounty-hunting pipeline — 96 listings across 10 platforms worth $8.85M, 20 closing within 3 days (12 with cash prizes) — and AgentLedger is the attestation sidecar to that pipeline: every scan / rank / submit an agent performs on a real listing becomes a verifiable receipt. I am the user.

How I built it

  • Frontend: Next.js 15 (App Router) + React 19 + Tailwind, UI scaffolded with Vercel v0 (prompts + boundary in docs/v0-workflow.md).
  • Backend: Next.js route handlers → Amazon Aurora DSQL via @aws/aurora-dsql-node-postgres-connector (IAM auth, no stored keys; production path is the Vercel Marketplace OIDC role — keyless).
  • Data model: append-only receipts table, UNIQUE(prev_hash) for chain linearity, retry on 40001/duplicate-key under concurrent appends (full access-pattern → key-design map in docs/ACCESS_PATTERNS.md).
  • The insight: the DB consistency model is the coordination protocol. UNIQUE(prev_hash) means two agents that grab the same chain tail can't both commit — the loser gets a retryable OCC conflict and re-reads the new tail. No app-level lock, no fork. The "Stress: 5 concurrent" button proves it: five parallel appends all land, sequential, no gaps, and the UI reports the measured OCC retry count, not an assertion.
  • AWS proof: generated from live AWS API calls (npm run aws:proof) — CloudWatch metrics for the cluster + the actual receipts hash-chain rows read from DSQL (see image gallery).

Challenges I ran into

  • Chain linearity under concurrency: the naive "read tail, compute hash, insert" races under parallel appends. Solving it without an app-level lock meant leaning on DSQL's OCC + a UNIQUE(prev_hash) constraint — the loser gets a retryable 40001/duplicate-key and re-reads the new tail. Getting the retry loop right (re-read tail → recompute → re-insert) was the core puzzle.
  • Verifiability without trusting the app: /verify recomputes hashes from stored fields and compares, so trust comes from hash math + the DB, not from "the app says it's fine."
  • Keyless AWS on Vercel: wiring the Vercel Marketplace OIDC role so no long-lived DB credentials live in the deployment.

Accomplishments I'm proud of

  • The tamper demo: mutate receipt #5 without rehashing → re-verify → the chain breaks at #5 and flags every receipt after it. Tamper-evident and localised.
  • 5 concurrent appends, all landing sequential with no gaps, with a measured (not asserted) OCC retry count.
  • Real bounty data behind the demo (not bounty:example-1) — judges see receipts over genuine targets.

What I learned

  • A database's consistency model can be the trust primitive, not just storage — the same proof-layer shape the industry is standardising for content (C2PA) and on-chain agents (ERC-8004) runs on an AWS database with the right consistency model.
  • OCC + a unique constraint is a surprisingly clean coordination protocol for an append-only chain.

What's next

  • Verify a receipt's input_hash/output_hash against an external payload (prove a stored document matches the chain without trusting the bytes).
  • Multi-region DSQL active-active for a globally-consistent ledger.
  • Agent identity — signed receipts (EIP-712), so a receipt proves which agent signed it.

Built With

Share this project:

Updates