Evidence
What it proves — and what it does not
Everyone in this category promises an audit trail you can rely on completely. That promise is easy to make, impossible to check, and therefore worth nothing. Here is what our evidence actually establishes, what it cannot establish, and a check of our published log that already ran in your browser — no account, no upload, nothing asked of you.
The published log, checked in your browser right now
Nothing to install and nothing to paste. When this page loaded, your browser fetched the
tree heads we publish at /anchors/heads.jsonl (each head is a short
fingerprint of the entire log at one moment) and recomputed the RFC 6962 consistency
proof between them using Web Crypto. The verdict below is whatever that computation
returned — if the proof had not recomputed, this is where you would be reading that it had
not.
[····] Fetching the published heads and recomputing the proof in this browser.
The part a browser cannot do
The external timestamp is an RFC 3161 token over the root bytes, and checking it needs an openssl binary — there is no Web Crypto path to it, so this page does not pretend to have checked it. Run this instead. The certificate authority comes from freetsa.org, not from us, which is the entire point of naming a third party.
The command names a specific head, so it appears once the head registry has been read.
What this establishes: across the heads published so far, the log was only ever appended to. What it does not: a head commits to a prefix of the log, so checking every interval shows that the prefix you are looking at was never rewritten, and says nothing whatsoever about entries that were never appended in the first place. Omission stays undetectable — see the limits below.
Hash-chained integrity inside an audit log is not unusual; Splunk and QRadar both ship it. The question worth asking a vendor is whether you can confirm it without them. Here the root bytes and the timestamp tokens are files you download, the arithmetic runs on your machine, and the certificate that validates the timestamp comes from the timestamping authority rather than from us.
Watch a decision become an entry
The requests below are made up. Everything done to them is not. The policy engine runs in your browser and decides each one as you watch, and every ledger entry is a real hash of a real decision. Select any entry and your browser recomputes the tree head from that entry's proof alone: if it matches, the entry is provably in the log and nothing before it was altered. What you are checking here is the machinery, on inputs we chose so you can see every outcome. Your own agents would produce the same shapes.
Every action, decided before it runs
…and written to evidence you can check
…Select an entry to recompute the head from its proof.
Timed in your browser and amortised over 5,000 evaluations per row. Browsers deliberately blunt their clocks, so anything under about 0.2 µs is below what this page can measure.
Nothing here is sent anywhere. The verification runs entirely in your browser, which is also the point: you do not have to trust our server to check our arithmetic.
What it proves
The record has not changed since it was logged
Any edit to any entry changes the tree head. You can check that yourself, below.
A specific record was in the log at a given size
An inclusion proof recomputes the head from one entry and its path — without revealing the others.
Between two published heads, nothing was removed — only appended
A consistency proof. Rewriting history becomes detectable rather than deniable.
What it does not prove
This is the more useful list. Anyone can tell you what their system proves; the limits are where you find out whether they understand it.
Not truth
A record saying an action was denied is recorded as faithfully as one saying it was allowed. The proof shows the record has not changed since it was written — not that it was accurate when written.
Not that the decision was right
That is a policy question. The evidence shows what was decided, not whether the policy was wise.
Not completeness
This is the one most people get wrong, including vendors who should know better. A Merkle log makes REWRITING history detectable. It does not make OMISSION detectable. If a record was never appended, no proof will say so.
Not identity beyond the key
Signature verification proves a specific key signed. Binding that key to us is a separate problem, which is what publication in an independent log is for.
Not third-party non-repudiation of the contents
Entries are metadata-first — hashes, names, counts. An auditor verifies structure, not your source. That is the deliberate privacy trade: your code never leaves your machine.
What is live today
The verifiers on this page are real and running now. The tree heads they read are published, and the root bytes of each head published so far carry an RFC 3161 timestamp issued by an independent timestamping authority. Both the token and the certificate that validates it are files you fetch yourself — the certificate from the authority, not from us — which is why the command for it is printed above rather than replaced by a badge.
What is not live: publication of those heads into an independent transparency log, so that our own hosting stops being where they come from. That is specified and not yet deployed. Until it is, an external timestamp makes rewriting the published history detectable; it does not make our hosting of that history redundant. We will say so here on the day it changes, and not before.
A page about evidence that overstated its own status would refute itself. If you are evaluating us, that sentence is the one to hold us to.
Why metadata-first
Entries record which agent, which action, which resource, which decision and which rule — never your source code. Grading and authorization read agent configuration and capability boundaries; your code stays on your machine. That limits what an auditor can independently confirm, and we would rather accept that limit than ask you to upload your codebase.
The scoring behind any grade is published separately — see the methodology.
Who wrote this
I spent four years doing cloud and AI security architecture inside regulated estates: LPL Financial, TIAA, Edward Jones. Before that I built and secured platforms at Anthem, Merck and Sanofi. The limits named on this page are not modesty. They are the questions I would have asked from the other side of the table, and the ones I could never get a straight answer to.
Brad McEvilly · DeepSweep