Show me the proof, not the promise

I spent the first days of September in Geneva, at the Global Digital Collaboration (GDC) Conference and, on the Monday before it opened, at a workshop with the First Person Project and the Decentralized Trust Graph working group. This is GDC’s second year, and it brings together many smart, committed people. There is real excitement in that community, and real frustration.

The frustration has a shape. We described today’s problems with precision all week and spent much less time on solutions. Meanwhile, the field keeps fragmenting into more standards, specifications and implementations, rather than aligning on a common set that would not solve everything but would move all of us forward together. Perfect remains the enemy of good. Everything I describe below is built on that common set rather than alongside it.

Then there were three rooms.

In the first, an AI agent completed a bank onboarding on its holder’s behalf. The room did not trust it. Within minutes, the discussion had moved to mandates; revocable, limited in scope, explicitly not left to the agent’s judgement, which is to say, it had moved to what the human had actually agreed to.

In the second, someone looking back over ten years in this field named an unsolved problem: consent fatigue, saying yes because you are asked too often.

In the third, a live demonstration ran a full agentic credential flow that assumed a human present at the moment of purchase, watching, and understanding what they were approving.

Two of those three rooms I was not in. Affinidi colleagues told me about them afterwards, and only when we compared notes did we realise that all three had landed in the same place: the consent surface, the moment a person is asked to agree to something. None of them was arguing about cryptography.

The thing that has to be true first

In May, I wrote about the shipping container and how a plain steel box reorganised world trade once everyone agreed on the handoff. The part I left out is the manifest, the written account of what is inside each box. Customs has always assumed a manifest can be wrong. That is why inspectors scan boxes as well as read paperwork.

Too much of our field has run on the manifest alone for a decade. You publish a specification, claim conformance, announce an integration, and often, nobody opens the box. The OpenID Foundation’s certification programme is an honourable exception. We could live with that while the stakes were pilots. Once systems start acting on our behalf, we cannot, because nobody can say who is accountable when the system’s behaviour has only ever been described.

Underneath all three Geneva rooms is one simple question with an uncomfortably complex answer: when a system asks me to approve something, what am I actually approving?

Where the description comes from

If I am going to say yes, I need to see what changes for me. There are three places that the answer can come from.

The first is the provider’s word: undisclosed intent behind long, difficult terms and conditions. This is the “trust me” model of today’s large platforms.

The second is peer-reviewed open code. Better, and necessary, but not something an ordinary person can exercise. Nobody vets millions of lines, even when they are published. And what is published can itself drift from what is actually deployed.

The third is a dry run. The system executes the real code against its real state, records what it would change, changes nothing, and shows you the result.

The first two drift, the way documentation drifts, one change at a time, with nothing in the system comparing the description against the behaviour. Cloud infrastructure learned this the hard way. Even with infrastructure as code, we still had to compare what a change did against what it planned and stop with an error when the two differed. Most consent screens have no equivalent check. The third cannot drift in the same way, because there is nothing to drift from: it is generated from the running system at the moment of the ask.

That description matters more than it looks, because it is the only evidence that a person agreed to what happened. Let it drift, and you end up with a signed, timestamped, cryptographically verifiable record of informed consent to an action the user was never shown. That is worse than no record at all, because it manufactures evidence of informed approval. Murky, over-generalised consent protects providers, not individuals, and the number of approvals each of us faces is about to rise by orders of magnitude. I do not want to wake up in the morning to 100+ consent approvals waiting for me.

What a dry run does not do

Two honest limits, because an argument for proof should not itself be made on promises.

A dry run bounds what my system will do. It does not bound what a counterparty does afterwards. If I approve sharing a record, the preview shows the share; it does not show the recipient’s behaviour a month later. That needs different machinery; scoped grants, revocation, and never handing over the keys; not a better preview.

And a preview can go stale. Anyone who has run a plan and then an apply against moving infrastructure knows the window between the two is real. A diff shown to a human is a claim about a state that may have changed by the time they press yes. The only safe answer is to re-evaluate at the moment of execution and fail closed when the result no longer matches what was approved. Consent to a stale diff is the same failure as consent to a stale description, arriving by a shorter route.

Build the code and the specification together

The rest of the field is arriving at the same working method. Google contributed its Agent Payments Protocol (AP2) to the FIDO Alliance in April, and Mastercard contributed Verifiable Intent, which the two companies developed together. Verifiable Intent keeps a tamper-proof record of what a user authorised an agent to do and serves as the accountability mechanism for agent payments. They are right to build it and right to do it inside a standards body. Anthropic donated MCP to the Agentic AI Foundation, which is part of the Linux Foundation, in December 2025. In each case, the code and the specification moved at the same time.

Since the start of the year, I have been building an end-to-end implementation of what I believe is the best set of standards for moving this industry forward. I call it Verifiable Trust Infrastructure (VTI), and it falls under LF Decentralized Trust and Trust Over IP. Early on I was lucky enough to meet Drummond Reed of the First Person Project and Darrell O’Donnell of Ayra in Seattle, and we agreed on a dual approach: build the code and develop the specifications in parallel. More than half a year on, that is the winning combination. The consent mechanism described here is running and tested behind a hosted service we operate. The wider VTI architecture is still being built; its specifications are public and still being argued over, and the delegation credential is a proposed type in an open pull request that nothing can yet claim conformance with.

It also means we trip over ourselves in the open. With thousands of merged changes and a fully built end-to-end deployment, we continue to find new attack vectors against these architectures and protocols: timing attacks, chain-of-custody impersonation, and correlation vectors. Solving them one at a time is the fun of building. The community has leaned in with multiple Risk and Harm Prevention reviews and security reviews, including an early Mythos review while the work was still under wraps.

Here is the one I would put in front of anyone who thinks conformance claims are enough. Our own conformance ledger reported a drift count of zero. It was measuring test fixtures rather than the running service. When we pointed it at the service, it found 134 real violations. Worse, 265 requirements called for a proof in the response that neither implementation had ever actually sent, and nobody noticed until something checked. We built the measurement, we published against it, and it was describing itself. That is exactly the failure this article is about, and we did it to ourselves. The code is what found it.

Trust Tasks

Did we know we needed Trust Tasks when we started building? No.

Early attempts in this field wrap cryptographic proofs around a transaction without ever capturing what the task actually was, what was required to complete it, and what changes as a result. A Trust Task does that explicitly: a common task, defined once, handed to another party, carrying both its requirements and its effects. Because the effects are part of the task rather than prose beside it, you get an audit chain where the input and the output can be hashed; proof of who requested which change and what the resulting change actually was. If I ask my bank to withdraw $10, I expect my balance to be $10 lower, and I expect the response to show me that.

Trust Tasks are transport-agnostic; they do not care how they get from A to B, or which intermediaries are involved. They are also a natural fit for zero-knowledge proofs and post-quantum cryptography, which they were designed to accommodate from the start. Proof of age is an obvious example: a proof-of-age Trust Task lets you establish that you are an adult or a child with zero disclosure.

Other things the specifications were missing turned up the same way: verifiable statement credentials, delegation models, complex asynchronous message handling at scale, and governance ceremonies expressed as open policy statements. None of them was visible from the specification alone.

Your agent, your policies

Within VTI, there is a digital twin of you, a Verifiable Trust Agent (VTA), which runs continuously and manages your keys, identities, credentials and agent memory. You choose where it runs.

This is where consent fatigue and richer consent are no longer opposed. They look contradictory, better previews mean heavier approvals, and we already have too many, but they resolve in each other. The computed diff is what makes automation safe. If a policy can key off what the code will actually change, rather than a category the requester declared, then most things can go through without me looking at them.

So: low-risk approvals auto-approve at my VTA. Medium-risk ones are reviewed and summarised in plain language by a personal AI agent. High-risk ones are explained to me and biometrically approved on a device I own. The tiers are mine to set and tune. What makes them trustworthy is not the tiering, which anyone can do, but that the classification runs against the real computed change, so a request cannot talk its way into the easy tier.

It extends past one person. Through a Verifiable Trust Community, a child’s content approval can be routed to a parent, or a suspicious financial transaction goes to family members for independent verification. And because the work is delegated without disclosing secrets, in what we call delegated trust task execution (DTTE), I can share sensitive information, identity, finances, and health with a third party who never owns that data and never holds the keys that protect it. I can still see it and still withdraw it.

Having used this in our own services, I find that it changes how I interact with other systems.

The wider lesson

We cannot reliably tell a person what a system is about to do by describing it. We have to run the real code against its real state, immediately before it runs, and show them the result.

None of those rooms in Geneva answered the question of who is accountable. Before anyone can, somebody has to be able to say what the system actually did, taken from the system itself, at the moment it did it. Anything less is the system’s own account of itself, and a person is being asked to make a decision on it that could later be held against them.

The shipping container changed the world once everyone agreed on the handoff, and customs kept working because someone could still open a box and check. Agents will need both: agreed standards, and a way to verify what they actually did. The specifications are outpacing the answers. So if you are building a system that asks people to approve what it is about to do, find out where your descriptions come from, before a regulator, a partner, or a court asks you instead.

Click to find out more about VTI and OpenVTC.

Click to find out more about Affinidi and learn about Building the Internet of Trust.

Sources

Google, “We’re donating Agent Payments Protocol to the FIDO Alliance”, Google blog, 28 April 2026. AP2 v0.2 and the Verifiable Intent contribution are described in the same post.

FIDO Alliance, “Building the Trust Layer for Agentic Payments with AP2 and Verifiable Intent”, fidoalliance.org, 2026.

Anthropic, “Donating the Model Context Protocol and establishing the Agentic AI Foundation”, 9 December 2025.

Conformance ledger figures (134 violations; 265 requirements with no proof sent): Affinidi and OpenVTC internal review, September 2026.