Non-repudiation for AI agents: no party can credibly deny what happened.

What non-repudiation means, plainly

A record has non-repudiation when the party behind an action cannot credibly deny it later. Two denials get ruled out:

• "That wasn't me." The record is bound to an identity, so authorship cannot be disowned.
• "That never happened." The record is captured at execution time and tamper-evident, so the event cannot be erased or rewritten.

Note what it is not: it is not a claim that the action was authorized, wise, or correct. Non-repudiation covers the record of what happened. Authorization and correctness are separate layers that sit on top of it.

Why agents need it

Chatbots needed conversation history. Agents need evidence, because agents act:

• Agents move money and change state. Payments, API calls, database writes, messages sent. Every consequential action is a future dispute waiting for a record.
• Multi-agent handoffs blur responsibility. When work passes from one agent to another, "which agent did what, under whose authority" becomes unanswerable without per-action records.
• "My agent did it" is the new dispute. When an agent makes a purchase nobody wanted or takes an action nobody approved, the first question is always what the agent actually did. Without a non-repudiable record, that question has no reliable answer.

A log tells you what your own system claims happened. A non-repudiable record tells a skeptic, an auditor, or a counterparty what happened, in a form they can check without trusting you.

The three ingredients

Non-repudiation is not one mechanism. It is three properties composed:

1. Identity binding. The record names which agent acted and which operator authorized it, bound with a cryptographic signature so authorship cannot be disowned later. Without identity, you have an event with no one behind it.
2. Capture at execution. The record is written when the action happens, not reconstructed afterward from a summary. A reconstructed record is a story; a captured record is evidence.
3. Commitment plus tamper-evidence. The record carries the canonical bytes of what the tool returned and a SHA-256 commitment over them. Anyone can recompute the hash and confirm the stored result was not changed. Any edit after the fact breaks verification, which rules out "that never happened."

Miss any one and the property collapses: identity without tamper-evidence gives you signed claims about editable history; tamper-evidence without identity gives you an undeniable event with no one behind it; capture without either gives you a log.

What AER-1 gives you

AER-1 is an IETF Internet-Draft (draft-zambo-aer1) for verifiable execution receipts: one receipt per agent tool call, carrying the canonical bytes and a SHA-256 output commitment anyone can recompute. That is ingredients two and three, standardized in an open format: capture at execution and tamper-evident commitment, checkable by a third party with no account and no trust in the agent.

Because the format is open, the check does not depend on any single vendor. A receipt produced by one implementation verifies against the same draft as a receipt from another, which is what makes the record credible to counterparties who do not use your stack.

What you add on top

AER-1 standardizes the receipt. A complete non-repudiation story needs three things from your side:

• Identity and authorization records. Bind each receipt to the agent identity and the operator or policy that authorized the action. The receipt proves what happened; your identity layer proves who is behind it.
• Anchoring and retention. Decide how long records live and where the tamper-evidence is anchored: hash-chained ordering, periodic anchoring to a write-once store, or public anchoring for the highest stakes. Match the mechanism to the dispute you expect, not the one you hope for.
• Key management. Signatures are only as credible as the keys behind them. Short-lived credentials, scoped keys, and a revocation story keep the identity binding meaningful.

For implementers

If you are building agent infrastructure, receipts are the fastest path to non-repudiable action records: emit one AER-1 receipt per tool call, bind it to your agent identity, and your users get evidence instead of logs. Framework collectors already exist for the major agent frameworks, and the implementations registry tracks independent implementations. Ship another implementation and claim your row: the standard wins on implementation count, and every new one makes the receipt format more credible to the skeptics your users answer to.