Logs prove nothing — and the web already fixed this once

Field Notes on the Agent Economy · Action State · June 2026

This week we open-sourced scitt-cose, a standalone verifier for IETF SCITT receipts and signed statements, along with a free hosted verifier at verify.actionstate.ai. This post is the story of why a company that builds agent-operated businesses ended up shipping verification infrastructure — and why the answer was sitting in a pattern the web has now had to learn twice — once from hacked certificate authorities, once from a poisoned software build.

The problem we kept hitting

At Action State Group we build businesses where agents do the real work. GetGopher runs operations for small business owners over text message: it reads invoices, recomputes the arithmetic, checks for duplicates, and asks a human before anything consequential happens. It works. And operating it surfaced a problem much bigger than our product.

When an agent pays an invoice or files a form, the only record of what happened is a log file — and we control the log. If a vendor disputes a payment, if an auditor asks what the system did in March, if an insurer wants to know whether the approval step actually ran, the honest answer today is: trust my logs. That answer is worthless precisely when it matters, because the moments that matter are the moments when someone has a reason not to trust you. Logs can be edited. Logs can be selectively presented. A log is testimony, not evidence.

We needed receipts that someone else could verify without trusting us. That turns out to be a general problem, so before building anything agent-specific, we went looking for how the world had solved it before.

The web solved this in 2011, the hard way

In 2011, attackers compromised certificate authorities — most infamously DigiNotar, a Dutch CA whose breach produced fraudulent certificates for google.com that were used to intercept the traffic of users in Iran. The entire security of HTTPS rested on trusting a few hundred organizations to never be hacked and never go rogue, and that assumption had just failed in public. DigiNotar was bankrupt within weeks.

The response, led by engineers at Google, was Certificate Transparency: every certificate issued gets recorded in public, append-only, cryptographically tamper-evident logs. The genius of the design is who you don't have to trust. The logs are operated by a consortium of independent parties — Google, Cloudflare, DigiCert, Let's Encrypt and others run them today — but you don't have to trust any of them, because every log entry comes with a mathematical proof. Given the log's public key and a receipt, anyone can verify that a certificate is provably in the log: signatures and Merkle-tree math, not promises. Major browsers now require these proofs for new certificates. Certificate Transparency quietly protects every HTTPS connection you made today, and most people have never heard of it.

The pattern generalizes: don't ask the world to trust the operator — give the world a receipt it can check itself.

2020: the same lesson, one layer up

Then the software supply chain failed the same way. In late 2020, attackers compromised SolarWinds' build system and hid a backdoor inside the company's own signed updates — malware delivered through the front door, carrying valid signatures, to roughly eighteen thousand organizations including US government agencies. The signatures were real. The artifacts were poisoned. Once again, the world had been trusting intermediaries it couldn't verify — this time build systems and software publishers instead of certificate authorities.

That breach (and the supply-chain security wave that followed it) is where SCITT comes from. The IETF chartered the SCITT working group — Supply Chain Integrity, Transparency, and Trust; the name is the origin story — to generalize the Certificate Transparency pattern beyond certificates: let any signed statement — a software bill of materials, a build attestation, a compliance claim, in principle any digital assertion — be registered in a transparency log and come back with a receipt anyone can verify. The core specifications are Internet-Drafts now sitting in the RFC Editor's queue, the last stop before becoming RFCs. It is careful, unglamorous, load-bearing work, and the people doing it have been at it for years.

None of this is abstract committee work, and credit belongs where it's due: the SCITT effort is carried by a real consortium — engineers from Microsoft, Fraunhofer SIT, DataTrails, and a wider community of implementers and use-case contributors who run interop tests in the open on the working group's mailing list. Microsoft and DataTrails already operate production transparency services under their own receipt profiles. Standards age well when the people writing them are also running them; this group is.

The missing brick

At IETF 124, the working group's receipt-profiles presentation made an honest observation: the vendor-neutral receipt profile — the one not tied to any particular company's ledger — had, to the presenter's knowledge, no known deployed implementation. The slide even said "please correct me if I'm wrong."

We had spent months needing exactly that piece. So we built it and gave it back.

What scitt-cose is (and deliberately isn't)

scitt-cose is an Apache-2.0 Python library, with a clean-room Go implementation in-tree, that verifies SCITT signed statements and receipts under the vendor-neutral profile: given public keys, it checks the signatures and reconstructs the Merkle proofs — this statement is provably in that log — without trusting the log operator. It treats statement payloads as opaque bytes, so anyone's use case can ride on it. Conformance is cross-checked against the published RFC test vectors, the independent Go implementation, and a third-party COSE library, in CI that cannot be skipped.

Just as important is what it is not: it is not a transparency service. It never registers, issues, anchors, or stores anything — running a log is a separate concern with its own trust obligations. The hosted verifier at verify.actionstate.ai is a stateless convenience: no account, stores nothing, and the page itself tells you that you don't need it — the same verification runs anywhere the library runs.

We've also stated our intent publicly: as the ecosystem matures, we plan to contribute this work to an appropriate open-source foundation. Infrastructure everyone must trust shouldn't be owned by one vendor — that's a lesson I keep relearning since my Presto Foundation days, and it's the whole point of the design.

Why this matters for the agent economy

Here is the vision part, stated plainly. Agents are crossing the line from answering questions to taking actions — paying, filing, ordering, signing. Every increase in autonomy is really a question about proof. An agent that wants less supervision needs a track record — even just to show a manager it was right the last hundred times. A business that delegates real authority to software needs records that survive a dispute. An insurer pricing agent-driven operations needs evidence, not dashboards. Observability tells the operator what their own system did; what the rest of the world needs is proof that holds up after it leaves the operator's hands.

The web crossed this bridge twice: trust failed, and both times the answer was receipts anyone can verify. We think the agent economy crosses the same bridge, on the same infrastructure, and we'd rather help lay the planks than wait. The standards community has done the hard part for years. scitt-cose is one brick, offered with thanks.

Verify something yourself: pip install scitt-cose, or read the self-documenting API at verify.actionstate.ai. Corrections welcome — that's rather the point.