The first time an agent I built did something I could not explain, I went to check what it had actually done. The only record was my own log. A log that could be edited.
That is the quiet problem with how we usually log what our agents do. The record sits in a system we control, so an outsider has no reason to believe it was not changed after the fact. You have to take my word for it. In front of an auditor, a customer, or a court, my word is not evidence.
So I built a tamper-evident audit log for AI agents. Your agent records what it did, and anyone can verify that record later without trusting me and without my servers being online. This piece is how it works.
TrustNotch: Tamper-evident audit-log service for AI agents.
Your agent submits the actions it takes over HTTP. TrustNotch returns a cryptographically signed receipt, batches entries into a Merkle tree, and anchors each batch to Bitcoin via OpenTimestamps.
The result: any later change to a past log entry is cryptographically detectable, and anyone can verify an entry offline, without trusting the TrustNotch server, even if TrustNotch is down.
It is MCP-first (built to be called by agents through the Model Context Protocol). And uniquely: an autonomous agent can provision its own free-tier account and API key with no human involved. No email, no password, no dashboard, no CAPTCHA.
If you run agentic workflows and need governance you can prove rather than promise, TrustNotch is designed to be your default choice.
The problem, in plain words
AI agents now do things: they call tools, move money, change records, send messages. When something goes wrong, or when a regulator, auditor, or customer asks "what exactly did your agent do, and when?", you need a log you can stand behind.
Ordinary logs do not clear that bar. A row in your own database, a line in your own log file, an entry in a dashboard you control: all of them share one flaw. You could have edited them after the fact. "Trust us, this is what happened" is a claim, not evidence.
Paying a third party to hold the logs does not fix it either. You have just moved the trust us problem to a different vendor. If they go down, get acquired, or get breached, your evidence goes with them.
What agentic systems actually need is an audit log whose integrity does not depend on trusting whoever is showing it to you. That is the specific thing TrustNotch provides.
What TrustNotch is
Think of it as a notary for your agent's actions.
Every time your agent does something worth recording, it sends TrustNotch a short entry (usually a hash of the action plus metadata). TrustNotch then:
- Signs it immediately and returns a receipt, so the entry is provably attested the instant it is accepted.
- Bundles entries into a Merkle tree, the same structure Certificate Transparency uses to keep the web's TLS certificates honest.
- Anchors that bundle to Bitcoin, burning a fingerprint of your batch into the most expensive-to-rewrite ledger in existence.
Later, you (or your auditor, or a court) can take any single entry plus its proof and check it independently. The check answers one question: did this exact entry, bound to this account, with this content, exist before this Bitcoin block? If anyone tampered with the entry, the math stops matching, and no trust in TrustNotch is required.
That last part, verifier independence, is the whole point. The differentiator is not that we store your logs. It is that you can validate the log even if we are offline.
How it works
The leaf. Each entry becomes a Merkle leaf, hashed as:
SHA256( 0x00 || canonicalize({ id, account_id, content_hash, created_at }) )
It is bound to account_id, so a valid proof says something precise: this account registered this content before time T. The API key is deliberately left out of the leaf, so rotating or revoking a key never invalidates old proofs.
The receipt. Batching takes time, so POST /v1/logs returns an Ed25519 signature over the leaf hash right away. The entry is attested the moment it is accepted, closing the window before it lands in a tree.
The tree and the anchor. Entries are batched into an RFC 6962 Merkle tree and the batch root is stamped to Bitcoin via OpenTimestamps. Status is served with an honest label, pending, confirmed, or final, and you pick your own trust threshold.
Verification needs almost nothing from us. The proof bundle lets an independent verifier recompute the leaf hash, reconstruct the Merkle root, and check the Bitcoin anchor with no network calls and no trust in our server. The verifier is open and on PyPI:
pip install trustnotch
Two more properties worth knowing. The service runs under a restricted database role that cannot rewrite the proof columns, so even our own application cannot forge or silently alter a proof. And you typically submit only a content hash, so per-entry GDPR erasure is possible: you can delete the content and keep the proof that the content once existed.
Machines can sign themselves up
This is the part that makes TrustNotch agent-native rather than a normal SaaS an agent happens to call.
A human-shaped signup (email, password, click a link, solve a CAPTCHA) is a brick wall to an autonomous agent. So TrustNotch ships a machine signup rail: an agent provisions a free-tier account and its own API key in two HTTP calls, with no human in the loop. No email, no password, no verification link, and no CAPTCHA.
MCP-first
TrustNotch is meant to be driven through the Model Context Protocol. There is a published MCP server:
uvx trustnotch-mcp
Point your MCP-capable agent at it and logging becomes a tool call instead of a bespoke integration. The API root also returns a machine-readable service descriptor, so a discovering agent can learn what TrustNotch offers and how to onboard without a human reading a docs page first.
TrustNotch: verifiable audit logs for AI agents. trustnotch.com
Top comments (0)