March 23, 2026

Guillermo Weinmann

Agents that can prove facts about their operator

TLSN enables verifiable human claims without revealing identity

Going beyond an Agent's self-description, the industry seems to be rushing towards developing standards for verifiable agent trust. But there's no framework for agents to present privacy-preserving attributes before or outside of a payment. At least not yet. The Verifiable Intent specification announced on March 5 solves for transaction authorization, and AP2 solves for payment, but neither one addresses provable facts about the operator.

In theory, TLSNotary proofs could enable an agent to prove facts about their operator, without revealing identity or private information.

Creating a good user experience is the challenge.

The Prover must be either a browser extension, a WASM module, or a combination of developer tools allowing network request inspection. None of these implementations are delightful to users.

The UX barrier sits on top of a TLSN technical requirement: the Prover and the Notary need to communicate but they can't be one and the same, since the Prover selectively discloses facts to the Notary. This data flow allows the Prover to redact sensitive information from the data prior to sharing it with the Notary. When paired with Zero-Knowledge Proofs, you get verifiable claims without revealing identity.

What goes where

Do agent developers care about user experience, and if so, do they care more, less, or the same about it as the general public?

My next step is to identify where and how TLSN fits in the A2A protocol. Is this for agents, or is it for humans, or both? Which part goes where?

If you're an agent developer and/or operator, please do reach out to me. I'd love to talk.


This is part of a series about Identity Architecture for the agent era.