The Honor System Is Ending: Four Places Trust Went Cryptographic

Four unrelated corners of the internet spent 2026 solving the same problem, and mostly did not notice each other doing it. Email got certificate-backed sender logos. Web servers got cryptographically signed AI agents. Media files got signed provenance manifests. Software artifacts got build attestations. Different working groups, different vendors, different conference tracks.

Same architecture underneath: a claim, a signature, a published key, and a receiver who checks. The honor system is being retired one protocol at a time, and it is worth understanding as one movement rather than four unrelated projects, because the failure modes are identical and so are the ways organizations get them wrong.

The pattern

Every one of these follows the same five-part shape.

1. A party makes a claim about itself or its output.
2. The claim is signed by a key bound to a verified identity.
3. The verification material is published somewhere the receiver can fetch it.
4. The receiver checks the signature and applies its own policy on top.
5. Nobody is told when any of it breaks.

That last one is not a joke. It is the defining property of the whole class, and I have written about it separately because it deserves its own argument.

Email: the oldest surface, finally finishing

Email has spent twenty years bolting identity onto a protocol that shipped without it. SPF listed IPs. DKIM added signatures. DMARC added the alignment rule that made the first two mean anything. Each one closed a gap the previous had left.

BIMI is the layer that made it visible. Publish a logo in DNS, back it with a certificate that a CA has validated against your registered trademark, and Gmail renders your logo with a blue checkmark next to it. Google began accepting Common Mark Certificates on September 24, 2024, which opened the logo to brands without a trademark while keeping the checkmark itself gated behind one.

The interesting part is not the badge. It is what the badge costs. A Verified Mark Certificate requires a live trademark registration, which at the USPTO means a filing process that runs 10 to 18 months and starts at $350 per class. That is the barrier doing the security work: a phishing actor cannot obtain a certificate for a mark they do not own, and no amount of money compresses the timeline.

The full cost breakdown, prerequisites, and the cases where it is not worth buying are in the BIMI guide. The layer-by-layer version of how the whole stack composes is in the email authentication stack.

Agents: the newest surface, moving fastest

An AI agent hitting your site presents a user agent string, an IP, and nothing else. All three are trivially forged, and the industry's previous answer, reverse DNS verification, assumed every operator controlled static IP space. That assumption died the moment agents started running on behalf of individual users from arbitrary infrastructure.

Web Bot Auth fixes it the same way BIMI did. The operator publishes a public key, the agent signs its requests using HTTP Message Signatures (RFC 9421), and the origin verifies. Three IETF drafts carry the work: an architecture document, the protocol specification, and a registry draft for the key directory.

What is remarkable is the sequencing. None of the drafts had been adopted as a single working group document, and Cloudflare, Anthropic, and OpenAI moved to production anyway. Supported operators already include Claude, ChatGPT, Perplexity, and Common Crawl. The de facto standard arrived well ahead of the RFC, which is a pattern email never got to enjoy.

The distinction that gets lost here matters more than the mechanism: a verified signature is an authentication fact about an operator. It is not authorization. Knowing which company sent the request tells you who to apply policy to, not what the policy should be. Implementation details are here, and the separate problem of what an agent may do once it is inside your systems is a different guide entirely.

Media: the hardest surface

Content Credentials attach a signed manifest to a media file recording where it came from and what touched it. The C2PA specification moved through version 2.2 in May 2025, 2.3 in January 2026, and 2.4 in April 2026, with a conformance program for interoperability across creation tools and verifiers.

This is the one I am least confident about, and the reason is structural rather than technical. Signing works. Verification works. What does not work is the assumption that a manifest survives the journey from camera to browser. Every resizer, CDN format conversion, and thumbnail generator between signing and delivery strips metadata by default and reports success. Most teams that implement this discover the credential is gone in production and cannot explain why.

The second problem is worse and is a product problem, not an engineering one. Nearly all media in existence carries no credential. Any interface that renders absence as suspicion marks the whole web as suspect and trains users to ignore the indicator within a week. Presence has to be informative while absence stays silent, which is a much less satisfying product than the red badge everyone instinctively wants to build. The pipeline audit is the real work.

For the broader question of verifying people, agents, and content together, I wrote about that a while back and the framing has held up.

Builds: the surface with the best tooling

Software supply chain attestation got there first and has the most mature implementation. Sigstore signs artifacts using a short-lived certificate bound to a CI workflow identity, logged to a public transparency log, which removed the long-lived private key that killed every previous signing initiative. SLSA adds provenance: a signed statement recording the source repository, commit, build platform, and parameters.

Generating both is close to free on hosted CI. A few lines of YAML on GitHub Actions produces signed provenance. That is the good news and it is also the trap, because generation without verification is theater. Most organizations that have adopted this have the signing half and no admission-time policy checking it, which means an attacker who compromises the pipeline gets their artifact signed by your legitimate workflow identity, validly, exactly as designed.

The verification half is the actual project.

Why all four, and why now

Three forces converged, and none of them are about cryptography.

Impersonation got cheap. Generating a convincing brand email, a plausible agent, a synthetic photograph, or a malicious package now costs almost nothing. When forgery is expensive, reputation systems work. When it is free, they stop working, and the only remaining discriminator is something the forger cannot produce. That is what a certificate is: an artifact whose cost is the point.

The receiver population consolidated. These systems need someone to do the checking. Four mailbox providers cover most consumer email. A handful of CDNs sit in front of a large share of the web. Two or three registries hold most container images. Verification at scale requires a small number of parties who can afford to implement it, and that concentration arrived first.

Machines became the audience. This is the underrated one. Self-asserted identity worked when a human was making the trust judgment, because humans use context. An automated pipeline consuming a package, an origin deciding whether to serve a crawler, or a model ingesting a document has no context. It needs a signature or it has nothing.

What this costs, and who it excludes

I want to be honest about the part the standards bodies skip.

Every one of these systems has a floor that a small operator cannot get under. A BIMI checkmark requires a registered trademark, which is a year and four figures. C2PA production signing requires a certificate from a CA in the conformance program. SLSA Build L3 requires a build platform that most self-hosted CI cannot provide. Web Bot Auth is the cheapest of the four, and it still requires publishing and maintaining a key directory at a stable URL.

The predictable outcome is a two-tier internet, where verified is a property of organizations large enough to buy it. That is not a reason to oppose any of this. It is a reason to be precise about what a badge means, because the gap between "unverified" and "untrustworthy" is where a great deal of harm will get done over the next few years.

There is a related failure I keep seeing in security awareness programs: teaching people that a checkmark means safe. It does not. Different platforms verify wildly different things, from a trademark registration down to an $8 subscription, and the badges render identically.

What none of it solves

Signature verification proves an identified party made a claim about a specific artifact. That is all it proves. It says nothing about whether the claim is true, whether the signing account is compromised, or whether the verified party is acting in good faith.

A verified sender with leaked marketing platform credentials sends perfectly authenticated, logo-bearing phishing. A verified agent can be a scraper you did not want. A validly signed C2PA manifest can contain a lie, because the signer is who is trusted, not the assertions. A legitimately signed build artifact from a compromised pipeline is still legitimately signed.

Verification narrows who can lie to you. It does not stop them lying. That distinction is the whole design and it is the first thing that gets lost when a badge reaches a user interface.

What to do this quarter

Concretely, in the order the value lands:

1. Get DMARC to enforcement. It is the prerequisite for the email half, it is free, and the sender inventory it forces is worth more than the badge on top. The rollout without breaking mail is six to eight weeks.
2. Turn on agent verification logging at your CDN. Not blocking. Logging. You cannot set a policy on traffic you have never measured, and a month of data costs nothing.
3. Generate build provenance, then go find who verifies it. The generation is a day. The absence of a verifying policy is the actual finding.
4. Leave C2PA alone unless you publish original media. The pipeline work is real and the ecosystem is early.
5. Buy the certificate last. Every one of these has a free tier that delivers most of the security value. The certificate buys visibility, and visibility is worth having only after the layer underneath it works.

The through-line: in all four cases the expensive, visible artifact is the least important part, and the boring inventory work underneath is what actually reduces risk. That has been true of every security control I have shipped in twenty years, and it is somehow still the hardest thing to get funded.