Open-source memory for AI agents you can actually audit. Every fact carries provenance (where it came from), the history is tamper-evident, and any user's data is provably deletable: forget() destroys their key and issues a signed certificate — data unrecoverable, audit proof survives. Reconciles GDPR "delete" with the EU AI Act "keep records." Zero-dependency core, runs on plain Postgres. Apache-2.0.
No reviews yetBe the first to leave a review for Attestari
Maker
📌
Hi Product Hunt 👋 I'm the solo founder of Attestari.
I kept hitting the same wall with agent-memory tools: they're black boxes. You can't prove where a stored "fact" came from, prove a user's data was actually deleted, or verify the history wasn't quietly edited — which rules them out for anyone under GDPR or the EU AI Act.
So I built the opposite. Attestari is event-sourced: an append-only, hash-linked log is the source of truth, and provenance, time-travel, and provable deletion fall out of it. Deletion works by encrypting each user's data under their own key — forget() destroys the key and issues a signed certificate, so the data is unrecoverable while the audit proof survives.
Don't take the claims on faith — `pip install attestari` and run examples/prove_the_moat.py; it attacks its own guarantees and self-verifies (asserts, not print statements). Apache-2.0, runs on plain Postgres.
Feedback welcome — especially from anyone who's shipped memory into a regulated stack (fintech, health, insurance). What would you need to actually run this?
Report
Congrats on tackling such a tricky compliance problem with the tamper-evident history and forget() flow. One thing that would really help teams adopting this is a small CLI or SDK helper that previews exactly which rows a forget() call would touch before it issues the certificate. Right now I can imagine nervous compliance folks wanting a dry run to sanity-check cascade paths and catch any unexpected references tied to that user before signing anything destructive.
Report
Maker
@kranoflazoqspk Great instinct — and it maps cleanly onto how forget() already works. The signed certificate it issues already enumerates exactly what it covers (e.g. "7 facts, 3 episodes" + a manifest hash), so a dry_run=True that returns that manifest *without* destroying the key is a natural next step: compliance sees the full blast radius, confirms the cascade, and only then signs. Putting it on the roadmap — that "look before you sign" step is exactly what makes people trust a destructive op. Thank you.
Report
Maker
@kranoflazoqspk Just shipped this! forget(dry_run=True) now returns the exact certificate a real forget would issue (subject, counts, manifest hash) but destroys nothing — no key shred, no tombstone, and the preview is left unsigned on purpose so it can never pass as a real deletion proof. Exactly your "sanity-check the blast radius before you sign" flow. Tracked + shipped: github.com/attestari/attestari/issues/1 — thanks for making the product better.
Report
Love that forget() issues a signed certificate, that's a clever way to bridge GDPR and the AI Act. One thing I'd find really useful: a small CLI flag like `attestari verify --user <id>` that re-checks a deletion certificate against the current ledger state, so I can run it during audits without digging through docs. Would make compliance reviews way smoother.
Report
Maker
@masal7ddh Good call. The verification primitive is already in the core — verify_certificate() re-checks a deletion certificate against the current key/ledger state, and verify_audit() re-validates the hash-linked chain — but today you'd call them from Python. Wrapping them in a one-line CLI like `attestari verify --user <id>`, so you can run it mid-audit without touching code, is the missing ergonomics and an easy win. Adding it — thanks for the sharp suggestion.
Report
Maker
@masal7ddh Great call — the verify primitives already exist in the core (verify_certificate re-checks a cert against the ledger, verify_audit re-validates the chain), and you're right they should be a one-liner from the terminal. Opened an issue to track the CLI: github.com/attestari/attestari/issues/2 — thanks for the sharp suggestion.
Report
The forget() flow with signed deletion certificates is genuinely clever—turning a legal headache into a cryptographic primitive. Nice execution on something most teams would have hand-waved away.
Report
Maker
@sudecoit Thank you — "turning a legal headache into a cryptographic primitive" is exactly the framing I was going for. That's the whole bet: deletion you can prove, not just assert. If you ever put memory into a regulated stack, I'd genuinely like to hear what would make you trust it in production.
Congrats on tackling such a tricky compliance problem with the tamper-evident history and forget() flow. One thing that would really help teams adopting this is a small CLI or SDK helper that previews exactly which rows a forget() call would touch before it issues the certificate. Right now I can imagine nervous compliance folks wanting a dry run to sanity-check cascade paths and catch any unexpected references tied to that user before signing anything destructive.
@kranoflazoqspk Great instinct — and it maps cleanly onto how forget() already works. The signed certificate it issues already enumerates exactly what it covers (e.g. "7 facts, 3 episodes" + a manifest hash), so a dry_run=True that returns that manifest *without* destroying the key is a natural next step: compliance sees the full blast radius, confirms the cascade, and only then signs. Putting it on the roadmap — that "look before you sign" step is exactly what makes people trust a destructive op. Thank you.
@kranoflazoqspk Just shipped this! forget(dry_run=True) now returns the exact certificate a real forget would issue (subject, counts, manifest hash) but destroys nothing — no key shred, no tombstone, and the preview is left unsigned on purpose so it can never pass as a real deletion proof. Exactly your "sanity-check the blast radius before you sign" flow. Tracked + shipped: github.com/attestari/attestari/issues/1 — thanks for making the product better.
Love that forget() issues a signed certificate, that's a clever way to bridge GDPR and the AI Act. One thing I'd find really useful: a small CLI flag like `attestari verify --user <id>` that re-checks a deletion certificate against the current ledger state, so I can run it during audits without digging through docs. Would make compliance reviews way smoother.
@masal7ddh Good call. The verification primitive is already in the core — verify_certificate() re-checks a deletion certificate against the current key/ledger state, and verify_audit() re-validates the hash-linked chain — but today you'd call them from Python. Wrapping them in a one-line CLI like `attestari verify --user <id>`, so you can run it mid-audit without touching code, is the missing ergonomics and an easy win. Adding it — thanks for the sharp suggestion.
@masal7ddh Great call — the verify primitives already exist in the core (verify_certificate re-checks a cert against the ledger, verify_audit re-validates the chain), and you're right they should be a one-liner from the terminal. Opened an issue to track the CLI: github.com/attestari/attestari/issues/2 — thanks for the sharp suggestion.
The forget() flow with signed deletion certificates is genuinely clever—turning a legal headache into a cryptographic primitive. Nice execution on something most teams would have hand-waved away.
@sudecoit Thank you — "turning a legal headache into a cryptographic primitive" is exactly the framing I was going for. That's the whole bet: deletion you can prove, not just assert. If you ever put memory into a regulated stack, I'd genuinely like to hear what would make you trust it in production.