Signed Execution Receipts for AI Agent Tool Calls (XAIP Receipts)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

2. Receipt Structure

A receipt is a JSON object with the following fields:¶

{
  "agentDid": "did:web:myagent.example",
  "callerDid": "did:key:z6Mk...",
  "toolName": "translate",
  "taskHash":
"9b74c9897bac770ffc029102a200c5de5f2a1b3c4d5e6f708192a3b4c5d6e7f8",
  "resultHash":
"f0e1d2c3b4a5987612345678abcdef00112233445566778899aabbccddeeff00",
  "success": true,
  "latencyMs": 142,
  "failureType": "",
  "timestamp": "2026-05-14T10:30:00.000Z",
  "signature": "...",
  "callerSignature": "..."
}

3. Canonical Payload and Signing

agentDid, callerDid, failureType, latencyMs, resultHash,
success, taskHash, timestamp, toolName

4. SigningDelegate Pattern (Caller Co-signature)

To produce a co-signed receipt, a Caller MUST NOT transmit private key material to the Executor. Instead, the Caller exposes a SigningDelegate interface:¶

interface SigningDelegate {
  did: DIDString
  sign(payload: string): Promise<HexString>
}

The Executor sends the canonical payload string to the Caller's sign method and receives the signature. The private key never leaves the Caller's process boundary.¶

When the Caller and Executor are not co-located, the transport carrying canonical payloads to the Caller MUST use TLS or an equivalent confidentiality and integrity layer.¶

A Caller MAY decline to sign -- for example, if the Caller does not consent to the receipt's contents. In that case the Executor publishes the receipt with only its own signature and no callerSignature. Such receipts remain syntactically valid; consumers may weight them differently as a matter of deployment policy.¶

By producing callerSignature, a conforming Caller attests that it accepts the canonical record as representing the identified Caller-to-Agent delegation. This attestation does not, by itself, imply that the Caller independently recomputed taskHash, observed the result committed to by resultHash, or validated success, latencyMs, or failureType, unless a deployment defines and enforces those checks. Section 8 discusses the resulting trust boundary.¶

5. Failure Type Classification

When success is false, failureType MUST be one of:¶

failureType MAY be extended by deployments with additional values. Receiving implementations MUST treat unknown failureType values as error for the purposes of any deployment-policy decision they make.¶

When success is true, failureType MUST be the empty string. This is a deliberate choice over a null value: it keeps the canonical payload's value type stable (always string) so that JCS canonicalization produces a predictable byte sequence regardless of success state. A verifier that substitutes a null value for an empty failureType will compute a different canonical payload and will fail to verify legitimate receipts.¶

6. Tool Metadata (Optional)

A receipt MAY carry a toolMetadata object describing class or capability hints about the tool. This document does not standardize the schema of toolMetadata. A deployment may use it to convey:¶

• A tool class (e.g., advisory, data-retrieval, mutation, settlement).¶
• A settlement layer identifier when the tool executes on-chain transactions.¶
• A verifiability hint indicating whether the tool's outcome is externally anchored.¶

toolMetadata is NOT part of the canonical payload and is NOT signed. Consumers that wish to trust toolMetadata MUST validate it through out-of-band means (e.g., the tool's published manifest, signed separately).¶

A future revision of this document, or a companion document, MAY standardize a portion of the toolMetadata schema if interoperability needs emerge.¶

7. Identity (DID) Requirements

Both agentDid and callerDid MUST be syntactically valid DIDs per [DID-CORE]. This document does not constrain the DID method. Common choices in production include did:key, did:web, and ledger-anchored methods such as did:xrpl or did:ethr.¶

A deployment MAY apply policy based on DID method -- for example, treating ledger-anchored identities differently from cryptographic-only identities. Such policy is out of scope for this document; the wire format treats all DID methods uniformly.¶

8. Security Considerations

9. Known Limitations

The following are known limitations of this format. They are recorded so that implementers and reviewers can account for them; a future revision or companion document may address them.¶

• Key rotation and historical verification. A receipt carries no verification-method identifier. When a DID document exposes multiple applicable verification methods, a verifier may need to try multiple candidate keys, and the receipt provides no stable reference to the key used at issuance. If that key is later removed from the DID document, a legitimately issued receipt can become unverifiable. A deployment that needs long-lived verifiability must retain historical key material or pin keys out of band. Carrying an explicit key identifier in the receipt is a candidate for a future revision.¶
• Tool identity. Only the opaque toolName is part of the signed payload; toolMetadata is not signed. Two implementations, providers, or versions that share a toolName are not distinguishable from the receipt alone. Binding a stable tool identifier, a provider or endpoint identity, or a version or manifest digest into the signed payload is a candidate for a future revision.¶
• Format versioning. A receipt carries no explicit format-version field and therefore does not, by itself, identify which revision's processing rules apply. Deployments that need to process receipts under more than one revision must convey the applicable revision or profile out of band. Adding an explicit version field is a candidate for a future revision.¶
• Hash preimage encoding. This document fixes the digest algorithm but does not define one canonical preimage encoding for every task-input and result type. Different deployments can therefore produce different hashes for semantically equivalent values. Cross-deployment comparison or later disclosure verification requires the parties to agree on the preimage encoding out of band.¶

10. IANA Considerations

This document has no IANA actions in its current form. A future revision may register a media type (e.g., application/xaip-receipt+json) and a failureType registry.¶

Appendix A. Relationship to the XAIP Reference Implementation

The XAIP reference implementation [XAIP-IMPL] wraps this wire format with an aggregator, a Bayesian trust score, optional metadata display, risk-flag logic, and a decision engine that ranks candidate tools. None of those components are required to produce or consume receipts conformant to this document. A consumer that only wants to verify and store receipts does not need to import any of them.¶

A consumer that wants a turnkey aggregator and scoring layer may use the reference implementation. A consumer that disagrees with any of those design choices is free to substitute its own implementation while remaining interoperable at the receipt-format layer.¶

The single-observer dominance failure mode discussed earlier in this document was first surfaced in the public dataset of that reference implementation [XAIP-CASE-2026-05].¶

Appendix B. Adoption Path for Agent-Payment Protocols

This format is intended to be useful to agent-payment protocols (for example, agent-to-agent payment protocols, agent-mediated commerce protocols, and agent escrow systems) that need a "trust precondition" check before committing to a transaction. Such a protocol can:¶

1. Require that an Agent present a set of recent receipts before being allowed to initiate a payment.¶
2. Define its own scoring policy over the receipt set, or consult an external scoring service.¶
3. Require that receipts above a certain transaction value include callerSignature (co-signed).¶
4. Require that receipts for settlement-class tools (declared via toolMetadata) be additionally anchored to an external ledger.¶

Each of those is a policy decision local to the agent-payment protocol. This document only defines the receipt wire format; it does not define a payment mechanism, a settlement rail, or any value-transfer system.¶

Appendix C. Relationship to Adjacent Receipt and Audit Formats

Other efforts also record evidence about AI agent actions. They differ from this document mainly in two dimensions: the unit of evidence (a single call versus a whole session) and which party attests to the record. This appendix is informative and describes that adjacent work for context; this document does not depend on any of these formats.¶

Session-level integrity bundles record an entire agent session as a single hash-chained, signed archive, answering post-hoc audit questions about a completed workflow. A per-call receipt as defined here and a session-level bundle are composable: a bundle may embed or reference per-call receipts, and a per-call receipt may carry a reference to the session in which it occurred.¶

Receiver-attested receipts are signed by the service that received the call and produced the result; obtaining such an attestation requires the invoked service to participate in the receipt protocol. The caller co-signature model in this document (the SigningDelegate pattern) instead lets the party that delegated the work sign the same canonical per-call record as the executing Agent, so that -- when both signatures are present -- the record is attributable to both parties to the Caller-to-Agent delegation without requiring the invoked Tool or service to sign. A further pattern places the signature on a mediator at the communication boundary between the Agent and the tool. These approaches represent different observation and control boundaries: a caller co-signature, in particular, does not imply that the Caller independently observed every field, and its evidentiary value depends in part on the operational separation between the Caller and the Agent.¶

In that space, this document occupies the per-call point at which the executing Agent and the delegating Caller can co-attest the same record. It does not subsume executor-only assertion, receiver attestation, mediator attestation, or session-level bundles; a single deployment may combine more than one of them.¶

Appendix D. Change Log

• -02 (2026-06-19): Scoped to define precisely what a caller co-signature establishes and what it does not. The Abstract no longer states that co-signature prevents unilateral fabrication outright; it now states that two valid signatures bind the identified Caller and Agent to the same canonical record, and that this does not establish independent observation of every field, execution correctness, or absence of collusion. Clarified caller-signature semantics (SigningDelegate Pattern), separated attribution from operational independence in Security Considerations (added operational-separation and collusion text), scoped the adjacent-formats appendix to the Caller-to-Agent delegation, and named the executor / delegator / receiver / mediator / session-bundle attestation axis. Softened the privacy design principle to a content-minimizing claim. Normative clarification: taskHash and resultHash MUST be computed with SHA-256 (now referencing RFC 6234) and encoded as exactly 64 lowercase hexadecimal characters, because the receipt carries no hash-algorithm identifier; this narrows the -00/-01 wording, which only RECOMMENDED SHA-256. Receipts that use SHA-256 remain compatible with this revision; receipts using another hash algorithm permitted by the earlier wording do not conform to -02. Added a Known Limitations section (key rotation, signed tool-identity binding, format versioning, hash-preimage encoding). No wire fields were added or changed.¶
• -01 (2026-06-19): Foregrounded caller co-signature (mutual attestation) as a distinguishing property of the format in the Abstract, and added an informative appendix relating per-call, caller-co-signed receipts to session-level integrity bundles and receiver-attested receipts. No wire-format or normative changes; receipts valid under -00 remain valid under -01.¶
• -00 (2026-05-22): Initial individual draft. Split out from the XAIP reference implementation specification, focused on the receipt wire format only. Removed aggregator, scoring, and decision-engine content; left those to deployment policy.¶

Author's Address