A June 2026 paper on arXiv, "Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions," maps out just how fractured the agent-accountability landscape has gotten. The authors survey five separate receipt specs that have emerged since 2024, all trying to solve the same problem — proving an AI agent did what it claims to have done — and find each one makes different, often incompatible, architectural bets. The core split is about who holds the signing key. In Otto Jongerius's Agent Receipts spec, the agent platform itself signs, which means the signer sits on the operator's side of the trust boundary — exactly the party a receipt is supposed to keep honest. William Hou's Signet project, focused on MCP middleware, moved further: its v0.4 introduced bilateral co-signing where the MCP server holds its own Ed25519 key and signs response receipts independently of the agent operator. Its v0.10 added envelope encryption. But the paper notes even Signet, the closest existing system to its own proposed design, keeps the encryption key tied to the signing identity, has no public transparency log, and stores trust configuration in a hand-edited JSON file. Pipelock, from PipeLab, ships an out-of-process mediator signer — a sidecar to the agent runtime — explicitly distinguishing in-process signing (weakest), operator-deployed mediator signing (what it ships today), and independent third-party witness signing, which is still just roadmap. Tymofii Pidlisnyi's Agent Passport System takes a different tack entirely, defining four distinct receipt types — ActionReceipt, AuthorityBoundaryReceipt, CustodyReceipt, and ContestabilityReceipt — with the action receipt signed by the executing agent rather than the service receiving the call. Meanwhile IETF drafts are multiplying in parallel: a compliance profile binding receipt fields to EU AI Act Article 12 and 26 record-keeping obligations, and a delegation-receipt draft pairing ECDSA signatures with TEE attestation quotes so a receipt can prove a specific model and config were running inside a trusted enclave at execution time. None of this is malicious duplication — it's five groups converging on the same problem from different entry points (MCP tooling, compliance, delegation, physical agents) faster than any one of them can consolidate. But it means an auditor checking agent behavior today has to know which receipt dialect they're reading, and a receipt signed under one scheme carries no guarantee of meaning anything under another. Attestation infrastructure is being built in parallel dialects before anyone has agreed on a lingua franca.