The Receipt Is Not the Record: Audit, Privacy, and Real-World Use
An agent payment is not accountable merely because a blockchain explorer can display its transaction hash. This chapter asks what a serious agentic commerce or finance workflow must remember after settlement: which principal authorized the action, how the agent and counterparty were identified, what policy and tools shaped the decision, whether the service was delivered, and who can challenge the result. It also applies that model to paid product information, data procurement, compliance, treasury, and other workflows so the reader can distinguish a bounded use case from a speculative promise.
Conditional settlement improves the timing of trust, but it does not finish the record. A transfer can be held until a proof is accepted and still leave an auditor unable to connect that proof to the mandate. A detailed log can explain the tool calls and still expose a firm's strategy or a person's private information. The practical problem is to preserve enough evidence for accountability while disclosing it only to the parties who need it.
What a serious payment must remember
A transaction hash is good evidence of a ledger event. It can show that an amount of an asset moved to a particular address, subject to the rail's confirmation and finality rules. It usually cannot show why the payment happened, which agent selected the recipient, what information the agent relied on, which policy was active, whether a service was delivered, or which person or institution is responsible for the consequences.
That missing causal chain is the difference between settlement evidence and accountability evidence. A payment system needs to connect the action to its origin and result. The origin includes the principal, the agent identity, the mandate, the quote or terms, and the wallet policy. The execution record may include the tools called, policy checks, timestamps, retries, and service response. The result includes delivery metadata, reconciliation, an explanation of any exception, and the action available if the result is disputed.
A useful way to hold these relationships together is an evidence envelope. The term describes a structured record that can bind the mandate and budget to the counterparty identity, policy version, quote, payment transaction, service-delivery receipt, reconciliation result, and escalation outcome. It need not be fully public. A firm may keep sensitive fields private while making a verifiable commitment available to an auditor, counterparty, supervisor, or dispute process. What matters is that the evidence exists, is connected to the same obligation, and can be disclosed under a defined authority.
This record also needs a governance identity, not only a cryptographic one. The Know Your Agent framework proposed in the field-level research divides that identity into five dimensions.
- Identity: who operates the agent, what persistent identifier and endpoint it has, and which legal person ultimately stands behind it.
- Capability: what the software, model, and tool stack can technically do, under which operating limits, and with what testing record.
- Authority: what the agent is permitted to do for this principal, including its mandate, wallet scope, transaction limits, approved counterparties, policy version, and revocation path.
- Provenance: how a particular action was generated, including the instruction, data source, model or software version, tool calls, payment, and delivery evidence.
- Recourse: who can pause, revoke, dispute, or remediate the action, and what contractual, insurance, or human process applies.
The five dimensions prevent a common category error. Capability is not authority. An agent may be capable of routing a trade or querying a sanctions database without being permitted to do either in a given mandate.