Sigstore Rekor · OpenTimestamps · offline verifier · AGPL
Every event is hash-chained, signed on ingest, rolled into Merkle roots and anchored to Sigstore Rekor and OpenTimestamps. The verifier runs offline. Our servers can be gone and the proof still holds.
Three people arrive here with three sentences. The sentences are the ones they actually type.
Founder or CTO in a first enterprise security review
"security questionnaire asks if our audit logs are immutable and exportable to SIEM, fastest way to add this"
Five lines of SDK, a JSONL export API, and an answer to the integrity question that is a command, not a paragraph.
Security or compliance lead at a regulated SaaS
"how do I prove to my auditor that nobody with database access can alter our audit log, PCI 10.3.2 / AU-9(3)"
Signed receipts, roots in two public logs, and an offline verifier the auditor runs themselves. The export and the verifier's report are plain files you attach as evidence; there is no Vanta or Drata integration.
Platform engineer told to make the Postgres audit table tamper-proof
"immutable audit log postgres hash chain how to anchor so a DBA can't rewrite it"
The chain, the Merkle roots and the anchoring already built, AGPL, one container, SQLite. Or the hosted version.
Log an event, get a signed receipt, watch it link to the previous one, verify the chain, then watch the root land in Rekor.
throwaway project · tenant = hash of your IP · 30 req/min · reset nightly
No events yet for this visitor. Log one; the receipt appears here as the first block of your own chain.
Every event hashes its predecessor into a per-tenant chain and comes back with a signed receipt. On each anchor tick, new events roll into a tenant Merkle root, tenant roots into a project root, project roots into one global root, and that one hash goes to two public logs AuditKit cannot edit.
Chain and sign
event_hash = sha256(JCS(header)) with prev_hash inside the header. The receipt carries position, hashes and an Ed25519 signature; keep it and a later verify proves we never dropped or reordered what we acknowledged.
Root
Three Merkle levels keep public-log traffic to one entry per tick while every tenant gets its own root and its own inclusion path. get_proof(event_id) returns the full path.
Anchor
The global root is written to Sigstore Rekor (append-only, inclusion proof, final on write) and stamped by OpenTimestamps calendars; the Bitcoin confirmation lands within hours. Time comes from OTS; Rekor gives inclusion, not a timestamp.
Roots go to two independent public logs we cannot edit. Anyone can look up the Rekor entry; the anchors page lists every root we have published, live from the server. Anchor cadence is a plan feature: daily, 5 minutes, 1 minute. Sigstore describes Rekor as "an immutable, tamper-resistant ledger" with a free public instance at rekor.sigstore.dev.
rekor hashedrekord · ots .ots proof stored per root
Your auditor runs one command against an export file (until the package is published, from the repo: node packages/verify/dist/cli.js <file>; npx @auditkit/verify is the eventual command). It re-hashes every event, walks the chain, checks the signatures against the server key you pin (--pin, from /.well-known/auditkit.json), rebuilds every Merkle root and verifies the Rekor and OTS receipts. No call to AuditKit. Exit code 0 means VALID.
# until @auditkit/verify is published, run it from the repo; later: npx @auditkit/verify …
$ node packages/verify/dist/cli.js acme-2026-10.jsonl --pin MCowBQYDK2VwAyEA…
ok manifest version 1, tenant ten_01j9k4, positions 0..1283, exported 2026-10-05T09:12:44.102Z
ok chain 1284 events, prev GENESIS → head 9f3c1a…e1a7
ok signatures 1284 server signatures verify (pinned key)
ok payloads 1281 payload commitments verify, 3 erased
? client_sigs 1284 client signatures present, no client keys given
ok roots 4 of 4 roots rebuilt and chained to their global root
ok anchors 8 of 8 anchor receipts verify
rekor 184201337/24296fb2… for 0..311: verified
ots alice.btc.calendar.opentimestamps.org for 0..311: verified at 2026-10-04T18:41:08.000Z
…
ok coverage anchored: 0..1283
VALID
Each event's payload is stored separately under a per-event salt. The chain commits to sha256(salt ∥ JCS(payload)), never the payload itself. A GDPR erasure deletes payload and salt; the event row, the chain, the roots and the anchors stay exactly as valid as before, and the erasure is appended to the same chain as a payload.erased event, so the log records that it happened. Immutable log and right-to-erasure stop being in conflict.
This is the pattern the EDPB describes in Guidelines 02/2025: "store only a salted or keyed hash of the personal data … after deletion of the secret key or salt, the hash should not be linkable to the original data". While the salt exists the hash is still personal data; erasure destroys both salt and payload.
POST /v1/erase/01J9K4… scope: erase
before payload_commit 7c1e… payload {"email":"ann@…"}
after payload_commit 7c1e… payload null erased: true
verify ok payloads 1281 payload commitments verify, 3 erased
ok chain 1284 events, prev GENESIS → head 9f3c…AuditKit supports these controls. It is not a certification and we do not say "compliant". The quotes are verbatim from the linked text; the right column is what the product does about each.
PCI DSS v4 · 10.3.2
"Audit log files are protected to prevent modifications by individuals."
10.3.4: change-detection mechanisms on audit logs so that existing log data can't be changed without generating alerts. 10.5.1: retain at least 12 months. source
AuditKit: Any modification changes a hash that no longer matches a root already in Rekor. Business retention is 3 years.
NIST SP 800-53 r5 · AU-9(3)
"Implement cryptographic mechanisms to protect the integrity of audit information and audit tools."
Guidance names signed hash functions using asymmetric cryptography with a distributable public key. AU-9(2): store records on a physically different system. source
AuditKit: Ed25519 receipts, public key at /.well-known/auditkit.json, roots stored in logs we do not operate.
HIPAA · 45 CFR 164.312(c)(2)
"Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner."
(b) Audit controls: record and examine activity in systems that contain ePHI. source
AuditKit: The verifier is the corroboration mechanism for the log itself; erasure is crypto-shredding, so the record of access survives the data.
ISO/IEC 27001:2022 · A.8.15
"Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed."
Implementation guidance: administrators who manage systems cannot modify or delete the logs those systems generate. source
AuditKit: Our own administrators cannot either: see the threat model.
DORA RTS 2024/1774 · Art. 12(2)(d)
"measures to protect logging systems and log information against tampering, deletion, and unauthorised access"
NIS2 Implementing Reg. 2024/2690 Annex 3.2: maintain and back up logs for a predefined period and protect them from unauthorised access or changes. source
AuditKit: Tamper detection by construction; export and self-host for the backup clause.
SOC 2 · CC7.2
"The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors …; anomalies are analyzed to determine whether they represent security events."
AuditKit: supports CC7.2-style log-integrity evidence: the export plus the verifier's report is one artifact an auditor can re-run.
Clients with no third-party dependencies for TypeScript (Node 22+, depends only on @auditkit/core) and Python (3.10+, standard library). Both retry on 429 and 5xx with idempotency keys, so a retry replays the original receipt instead of double-logging. Pass a private key and every event is client-signed with a key we never see (Python signing uses the cryptography extra).
// Until @auditkit/sdk is on npm: git clone https://github.com/AuditKitDev/auditkit && pnpm install && pnpm -r build,
// then npm install <clone>/packages/sdk. ESM ("type": "module") and Node 22+.
import { AuditKit } from "@auditkit/sdk";
const audit = new AuditKit({ apiKey: process.env.AUDITKIT_KEY!, baseUrl: process.env.AUDITKIT_URL ?? "https://api.auditkit.dev" });
const receipt = await audit.log({ tenant: "acme", actor: "u_1", action: "invoice.delete", target: "inv_42" });
console.log(receipt.position, receipt.event_hash, receipt.server_sig);Both SDKs are in the repo and tested; the npm and PyPI packages (auditkit-sdk) publish with v2.0.0. Until then install from the clone as the first line shows. Set AUDITKIT_URL to your own instance when self-hosting.
# Until auditkit-sdk is on PyPI: pip install <clone>/packages/sdk-python (Python 3.10+)
import os
from auditkit_sdk import AuditKit
audit = AuditKit(api_key=os.environ["AUDITKIT_KEY"], base_url=os.environ.get("AUDITKIT_URL", "https://api.auditkit.dev"))
receipt = audit.log("acme", "u_1", "invoice.delete", target="inv_42")
print(receipt["position"], receipt["event_hash"], receipt["server_sig"])Both SDKs are in the repo and tested; the npm and PyPI packages (auditkit-sdk) publish with v2.0.0. Until then install from the clone as the first line shows. Set AUDITKIT_URL to your own instance when self-hosting.
curl -X POST https://api.auditkit.dev/v1/events \
-H "Authorization: Bearer $AUDITKIT_KEY" -H "Content-Type: application/json" \
-d '{"tenant":"acme","actor":"u_1","action":"invoice.delete","target":"inv_42"}'
# → {"id":"01J…","position":0,"event_hash":"…","prev_hash":"000…","server_sig":"…"}The MCP server is the REST API's own process at /mcp, not a wrapper. Same data, same scopes. In Claude.ai: Settings → Connectors → Add custom connector → https://auditkit.dev/mcp → sign in with your email → pick the project. Every tool declares a title and read-only / destructive hints so an agent can tell a search from a write. There is no erase tool over MCP, on purpose.
claude mcp add --transport http auditkit https://auditkit.dev/mcp
# first use opens a browser: sign in with your email, pick the project, doneOAuth 2.1 sign-in for Claude.ai and Claude Code; Bearer API keys for everything else. Keys are ak_live_ or ak_test_; the prefix is a label for your own routing and both hit your project. Every new account also gets read access to a shared Sample project, so you can run every read tool before you log anything real.
search_eventsSearch audit eventsread-onlyget_eventGet one audit eventread-onlyget_proofGet tamper-evidence proof for an eventread-onlyverify_rangeVerify chain integrity for a tenantread-onlylist_tenantsList tenantsread-onlyexport_evidenceExport verifier-ready evidenceread-onlylog_eventRecord an audit eventwrites · not destructiveEvery feature is on every plan; the tiers differ only in monthly events, payload retention, anchor cadence and support. The same table is on the pricing page, in the dashboard, and in the server's plan table.
Free AGPL
$0 forever
$49 per month
$199 per month
Every plan, including Free, has the same features
Plans differ only in monthly events, payload retention, anchor cadence and support. Nothing below is gated by plan.
Retention is payload retention: hashes, signatures and anchors are kept so old exports still verify. Billing through Stripe Checkout; no seats, no metering beyond a monthly event counter. Prices in USD. [OWNER: confirm Stripe prices]
AuditKit is the evidence layer. Identity vendors sell retention and SIEM plumbing with no integrity claim; compliance platforms collect evidence but do not give your customers a log; cloud ledgers make the claim but the proof ends at the vendor.
| AuditKit | WorkOS Audit Logs | Datadog Audit Trail | Drata / Vanta | pgaudit / DIY Postgres | |
|---|---|---|---|---|---|
| Integrity claim | Hash chain, Ed25519 receipts, roots anchored to Rekor + OpenTimestamps | None on the product or pricing page | None; retention tiers | No customer-facing audit log; evidence bundles for your auditor | A permission (REVOKE), not a proof |
| Verify without trusting the vendor | Yes: @auditkit/verify, offline (run from the repo until published) | No | No | No | n/a: you are the vendor, and so is your DBA |
| Pricing | $0 / $49 / $199 per month | $99/mo per 1M events retained + $125/mo per SIEM stream | 2–3% of spend per month | Not published for this feature | Your time: 6–12 weeks for a basic build |
| Default retention | 30 days / 1 year / 3 years (payloads); hashes forever | 30 days by default | 3 to 90 days | n/a | Whatever you set, until someone drops the partition |
| Erasure without breaking the record | Crypto-shredding per event | Not evaluated | Not evaluated | n/a | DELETE breaks any chain you built |
| Per-tenant proofs for your customers' auditors | Merkle path + public-log receipts | No | No | No | No |
| SIEM streaming | No; JSONL export API instead | Yes, per-connection fee | Yes, it is a SIEM | No | Build it |
Vendor cells from their public pricing and docs pages, fetched 2026-10-05/06 (WorkOS pricing and docs, Datadog pricing list and Audit Trail docs, Velt's build estimate). Cloud ledgers and open-source options (Azure Confidential Ledger, Google Cloud Audit Logs, immudb, Retraced) are compared on the Postgres and self-built page. We will correct any cell a vendor shows to be out of date.
The export file carries every event, its signature, the Merkle roots and the public-log receipts. @auditkit/verify re-hashes everything and checks the roots against Rekor's inclusion proof and the OpenTimestamps proof. What you still trust: Rekor's log key, the Bitcoin chain, and the arithmetic. Not our database, not our staff, not our uptime.
They can change rows. They cannot make the changed rows hash to the roots already written to Rekor and stamped by OpenTimestamps, and they cannot re-sign events without the server key, which lives in the environment, not the database. See the threat model.
The chain commits to sha256(salt ∥ payload), not the payload. Erasure deletes the payload and the salt; the commitment stays, so the chain, roots and anchors still verify. The verifier reports the event as erased.
On the next anchor tick for your plan (daily on Free, 5 minutes on Pro, 1 minute on Business). Rekor accepts the root in seconds and is final on write. OpenTimestamps calendars stamp it immediately and the Bitcoin confirmation lands within hours; the receipt upgrades from pending to final.
Only against keys you register. The SDK signs with a private key we never see. Register the public key for a tenant and the server verifies every signed event against it; turn on "require client signatures" and it refuses unsigned events for that tenant. The offline verifier checks the same signatures from the export when you pass your public key, so the server's check is a convenience, not something you have to trust.
Yes and yes. Free is 10k events a month with daily anchoring and every feature the paid plans have; paid plans buy volume, retention, cadence and support. Self-host is the same code under AGPL: one container, SQLite, the same verifier.
AuditKit has no SOC 2 report today. What it gives you is log integrity you can prove to your own auditor with the verifier, which is the evidence behind log-integrity controls; it is not a compliance certification.
Start logging. Verify in an hour.
Free tier, no card. The first project is created on your first sign-in.