A new arXiv paper, "Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions," lays out just how crowded the agent-accountability space has gotten in the past two years. The paper surveys the field and finds that the receipts vocabulary for agent actions has emerged across several projects in 2024-2026, each making different architectural choices. The comparison is useful because it shows where each project cuts corners. Agent Receipts, maintained by Otto Jongerius, signs with Ed25519 and W3C Verifiable Credentials, but the agent platform itself does the signing, which keeps the key on the operator's side of the trust boundary — meaning the entity being audited also controls the proof. Signet, an MCP-focused middleware project, introduced bilateral co-signing where the MCP server holds its own key, which is closer to independent verification, but the paper notes the encryption key isn't separated from the signing identity, there's no public transparency log integration, and the trust bundle is a hand-edited JSON file. Pipelock ships a sidecar mediator signer but hasn't shipped the independent third-party witness variant that would remove the operator from the trust path entirely. The authors propose their own protocol, Sello, built around four properties they say no current system combines: receiver-side signing, encryption to an owner public key bound via JWS, publication to a witness-cosigned Merkle log, and owner-side discovery by token reference. The framing is blunt about the stakes: agents acting on behalf of humans need to be auditable by those humans, and the owner needs to know not just what the agent claims it did, but what it actually did. This matters beyond the specific cryptography. It's a signal that the accountability layer for agentic systems — receipts, delegation proofs, audit trails — is still in a proliferation phase rather than a standards phase. Multiple independent projects (Agent Receipts, Signet, Pipelock, Agent Passport System, plus commercial entrants like Handshake and CertNode) are solving overlapping problems with incompatible trust assumptions. Until one of these converges into something like a co-signed, transparency-logged default — the way TLS certificate transparency did for the web — buyers evaluating any single "signed receipt" claim should ask a specific question: who holds the signing key, and can the audited party unilaterally produce a favorable record without an independent witness.