The Log Author Should Not Be the Log Subject

A June 2026 protocol proposal names the structural flaw in current agent observability directly: the entity producing the activity record and the entity whose activity is recorded are the same entity.

On June 2, 2026, an arXiv preprint by a single author, Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions, opened with a diagnosis stated in plain terms: "current AI agent observability is structurally compromised: the entity producing the activity log is the same entity whose activity is being logged." The paper continues: "a compromised or buggy agent can omit, alter, or fabricate its own traces, and the operator running the agent has no independent way to detect tampering." That sentence describes a property of nearly every agentic observability stack currently deployed. Logs are typically written by the same process, or a process controlled by the same operator, that performed the logged action.

The paper's proposed fix inverts where trust is placed rather than adding more logging. Instead of trusting the agent, or the operator running the agent, to accurately record what happened, the paper proposes that "the service that receives an agent's call signs a receipt of what it observed using its own key, encrypts the receipt to the agent's owner, and publishes it to a public transparency log." The party being asked to attest is no longer the party whose behavior is under scrutiny. It is the counterparty on the other end of the interaction, the service the agent called, which has no incentive to misrepresent what it received, because it is not the party whose accountability is at stake.

The four properties of the proposed protocol

The paper instantiates this trust inversion as a named protocol, Sello, combining four properties the paper states are "absent in any current system." The first, receiver-side signing, is the foundational move already described: the receiving service, not the calling agent, produces the authoritative record. The second, HPKE encryption to an owner public key bound to the authorization token via JWS, ensures the receipt's contents are readable only by the agent's actual owner, not by intermediaries or by the receiving service itself after the fact, while still cryptographically tying the receipt to the specific authorization under which the call was made.

The third property, publication to a witness-cosigned Merkle log, provides a transparency mechanism modeled on certificate transparency infrastructure already used to detect fraudulently issued TLS certificates: receipts are committed to an append-only structure that multiple independent witnesses cosign, making it detectable if a receipt is later altered or selectively withheld. The fourth, owner-side discovery by token reference, allows the agent's owner to locate and retrieve the relevant receipt using the authorization token as a reference, without needing to trust any single party to proactively deliver it.

What inverting the trust boundary actually buys

The practical consequence, per the paper, is that "the owner reconstructs a tamper-evident trail without trusting the agent or its operator." This is a meaningfully different accountability posture than log integrity measures that harden the agent's own logging pipeline, adding checksums, write-once storage, or tamper-evident sealing to logs the agent itself still produces. Hardening a log the suspect party still authors closes some tampering vectors but leaves open the possibility that the suspect party never wrote the compromising entry in the first place. Receiver-side signing removes the suspect party from the authorship chain entirely for that specific transaction.

The paper reports microbenchmarks of the cryptographic operations involved and situates Sello explicitly among adjacent work, naming Signet, AgentROA, Agent Passport System, draft-farley-acta, and SCITT as related receipt-protocol efforts. That positioning matters: Sello is not presented as the first attempt at receipt-based attestation, but as a specific combination of four properties the paper argues no prior system combines.

The limitations the paper names on its own

Notably, the paper does not present the protocol as a closed solution. It explicitly discusses "known limitations including the suppression attack, service collusion, and the adoption-incentive problem." The suppression attack describes a scenario in which a party capable of preventing a receipt from being published in the first place, rather than tampering with a receipt after the fact, can still defeat the protocol's guarantees. Service collusion describes the case where the receiving service itself colludes with the agent or its operator to produce a receipt that misrepresents what actually occurred, defeating the assumption that the receiving service has no incentive to misrepresent. The adoption-incentive problem is the most structurally difficult of the three: the protocol requires receiving services to adopt receiver-side signing infrastructure that primarily benefits the calling agent's owner, not the receiving service itself, raising the question of why any given service would bear that cost.

Where this sits relative to the identity question

The paper's framing treats accountability as downstream of a specific architectural choice: who is positioned to produce the authoritative record of an interaction. Agent identity frameworks that focus on scoring, authorizing, or delegating trust to an agent still generally assume that once an agent is authorized to act, its own account of what it did can be trusted, or at least independently verified through logs the agent or its operator controls. Sello's proposition is that this assumption is precisely the weak point, and that accountability requires moving the point of record-keeping outside the party whose accountability is being assessed.

That proposition does not resolve questions of authorization or delegation on its own. It answers a narrower, prior question: once an interaction has occurred, whose record of that interaction should an auditor trust. The paper's own acknowledged limitations, particularly the adoption-incentive problem, suggest that answering the narrower question does not automatically produce the incentive structure needed for the answer to be adopted at scale.

Open Questions

• What mechanism would give receiving services a durable incentive to bear the infrastructure cost of receiver-side signing, when the primary beneficiary of that signing is the calling agent's owner rather than the receiving service?
• How does the protocol's guarantee hold when the receiving service and the agent's operator are commercially aligned or under common ownership, given that service collusion is named as an acknowledged limitation?
• What remedy exists for an agent's owner when a receipt is suppressed before publication, rather than altered after the fact, given that the paper acknowledges the suppression attack as unresolved?
• Does the witness-cosigned Merkle log require a governance structure of its own, to determine who qualifies as a witness and what happens if witnesses themselves collude or go offline?
• How would this receipt-based attestation model interact with the compositional delegation chains proposed elsewhere in the same research period, where an action may pass through several agents before reaching the receiving service that ultimately signs the receipt?
• What legal or regulatory weight would a Sello receipt carry in a dispute, given that the protocol is a cryptographic proposal without an accompanying standards-body endorsement or regulatory recognition at the time of publication?

The governance artifact is retained. The governance function is not.