Overview

The Sannvit Ledger is an append-only, hash-chained audit trail for AI agent activity. Every LLM call, tool invocation, and retrieval an agent makes is sealed into a per-org SHA-256 hash chain — independently re-verifiable by anyone, not just by the system that wrote it. It runs entirely inside your own infrastructure: self-hosted via Docker Compose or Kubernetes, no data leaves your walls.

The problem it solves

Application logs are a claim, not evidence — an administrator can edit a row, retention is measured in days, and there's no distinction between what an AI asserted and what was independently recorded. A regulator, auditor, or opposing counsel asking "what did your AI do, and what did it rely on" needs more than that: sealed records nobody can silently rewrite, years of retention, and a chain of custody from decision back to the input it depended on.

How it works

• Capture — a lightweight SDK observes your agent's actions in-process, without intermediating them. Nothing sits between your code and your model provider, and the SDK can't take your application down: capture is a synchronous, non-blocking buffer push, and delivery to the ledger API happens asynchronously. See SDKs.
• Seal — hash chaining happens server-side, in the ledger API, not the SDK — concurrent writers can't know "the previous record," so the single-writer invariant lives in one database function. Each record seals onto the one before it in a per-org chain.
• Verify — the chain is independently re-verifiable: recompute every record's hash and walk the links, outside the running service, without trusting the operator.
• Review — a dashboard reconstructs any decision's chain of custody, handles alerting, and exports evidence packs for an examiner.

Architecture properties

• Observer, not gateway. The SDK never sits in the request path — if the ledger were unreachable, your agent wouldn't notice. Failures report to an on_error callback instead of propagating.
• Server-side sealing. Records serialize as canonical RFC 8785 entries, hash-chained with SHA-256 (one record_hash / prev_hash pair per record). The SDK only reports what happened; the server computes every hash.
• Never lose silently. If the ingest buffer overflows, dropped events are counted and sealed in as a lifecycle record — the gap itself becomes part of the audit trail, not a silent hole in it.
• Self-hosted. Plain Postgres, Keycloak for auth, and an S3-compatible blob store for payload content (pointer + hash only, content-addressed) — all running in your own VPC or on-prem, no managed backend to trust.

What's in the stack

Where to go next

• Getting Started — stand up the stack with Docker Compose or Kubernetes.
• SDKs — instrument an agent to start sealing its activity into the ledger.