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 3 January 2027.¶

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:¶

A receipt SHOULD NOT carry top-level members other than those defined above. Consumers MUST treat any unknown top-level member as unauthenticated data: unknown members are not part of the canonical payload and are not covered by any signature. Producers MUST NOT rely on unknown members being preserved by intermediaries.¶

{
  "formatVersion": "1",
  "agentDid": "did:web:translator.example",
  "callerDid": "did:web:orchestrator.example",
  "toolName": "translate",
  "taskHash":
"a1f15dbb98240bfcd2ae4e21497f0fc011e99397929d2836bff327ff09254103",
  "resultHash":
"125aeadf27b0459b8760c13a3d80912dfa8a81a68261906f60d87f4a0268646c",
  "success": true,
  "latencyMs": 142,
  "failureType": "",
  "timestamp": "2026-07-02T01:23:45.678Z",
  "signature": "1fbf11f917c6404db0476f4542f981b0bd00f3391ffa2a
859f1f700b520228ac13f6d1b8a09394012290830c908d7b7906c4e3498d9dc4
1f2badb8bc7de97905",
  "callerSignature": "5dadd87738832b65557072e15877ace0abe74f9c21
ea7c32cc64b838e4379f6e15f974ff05aa65f4adcc320c01a4b0d4dc72bc154f
cc12af7b696b485a51c40c"
}

3. Canonical Payload and Signing

agentDid, callerDid, failureType, formatVersion, 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.¶

Before signing, a conforming Caller SHOULD at minimum parse the canonical payload and confirm that callerDid identifies itself and that the payload corresponds to a delegation it actually issued (for example, by matching toolName and recomputing taskHash from the input it delegated). A Caller that signs whatever it is handed adds attribution but no verification; Section 8.7 discusses the resulting trust boundary.¶

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. The Security Considerations discuss the resulting trust boundary.¶

5. Failure Type Classification

When success is false, failureType MUST be either one of the following registry values or a deployment-defined extension value:¶

Receiving implementations MUST treat unknown failureType values as error for the purposes of any deployment-policy decision they make. Deployments defining extension values should note that extensions carry meaning only within that deployment.¶

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 (Section 3.1) 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. A formatVersion "1" receipt with success true and a non-empty failureType, or success false and an empty failureType, is malformed and MUST be rejected (Section 3.3).¶

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.¶
• Receipt uniqueness. The format carries no nonce or per-receipt identifier. Two executions whose field values coincide exactly are represented by byte-identical receipts (Section 8.2) and cannot be distinguished or counted separately. Deployments for which double-counting or under-counting such coincidences matters must add an out-of-band identifier; a nonce field is a candidate for a future revision.¶
• Cross-profile hash comparison. Section 3.5 pins one preimage profile for formatVersion "1", which makes hashes comparable across producers within this format. Comparing hashes against records produced under a different profile (including legacy truncated hashes, and formats that hash JSON-string serializations) remains undefined and requires out-of-band agreement.¶

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, a class-aware risk-flag evaluator, 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.¶

As of this revision, the reference implementation (SDK middleware, four client emitters, and the aggregation service) produces and fail-closed-validates formatVersion "1" receipts, and its behavior is locked to the conformance vectors of Appendix D.¶

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, which is unsigned and therefore validated out of band per Section 6) 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, Section 4) 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. Conformance Test Vectors

Executable test vectors for this revision are published in the reference repository [XAIP-VECTORS]:¶

• docs/spec/test-vectors/receipts-v1-vectors.json -- the vectors. Every hash, canonical payload byte string, and Ed25519 signature is real; test keys are embedded (and marked as such).¶
• docs/spec/test-vectors/check.mjs -- a dependency-free checker (Node.js 18 or later, standard library only) that re-derives every value from the vectors file and verifies all signatures, failing loudly on any drift.¶

The vectors pin, as executable bytes: the preimage profile of Section 3.5 (raw-UTF-8 text hashing with the JSON-form value shown as the explicit wrong answer; JCS member-order invariance; the empty-input sentinel); canonical payload construction with and without formatVersion, including the byte-identity of payloads with and without toolMetadata; a complete co-signed receipt (the example in Section 2), a failure receipt using the sentinel, and a legacy receipt; a tamper case whose signatures must fail; and the fail-closed rejections of Section 3.3 (truncated hash, uppercase hash, failureType inconsistent with success).¶

The vectors are the executable form of this document's processing rules: an implementation that reproduces them byte-for-byte conforms to the hashing and canonicalization layers of this revision, without needing to interpret prose. The example in Section 2 and the vectors are generated from the same values, so the example cannot silently drift from the specification.¶

Appendix E. Change Log

• -03 (2026-07-02): Versioned the wire format and made it mechanically checkable. Added the formatVersion member (value "1"), carried inside the signed payload, and defined legacy-receipt handling. Pinned the hash preimage profile -- scalar content hashes its content bytes, structured JSON hashes its JCS form, absent values hash the empty-input sentinel -- narrowing the -02 known limitation on preimage encoding. Made verification of formatVersion "1" receipts fail-closed for hash format and failureType consistency. Pinned: no Unicode normalization at verification, NFKC/NFKD prohibited at any layer, NFC recommended for producers; signature encoding exactly 128 lowercase hex characters; latencyMs range [0, 2^53 - 1]; a single RECOMMENDED RFC 3339 rendering for timestamp; unknown top-level members are unauthenticated. Resolved the -02 contradiction between the closed failureType value set and deployment extensions, and required rejection of success/failureType-inconsistent receipts. Required the empty-input sentinel for failure receipts committing to no output. Added a SHOULD-level minimum check list for Callers before co-signing. Corrected the replay-section uniqueness claim and added the receipt-uniqueness (no nonce) known limitation; removed the format-versioning known limitation (resolved by formatVersion). Replaced the example receipt -- whose hash values did not conform to this document's own length requirement in -00 through -02 -- with a complete receipt that verifies against published test keys. Added executable conformance test vectors and a dependency-free checker. No changes to the signing algorithm, canonicalization scheme, or trust-boundary language of -02.¶
• -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, separated attribution from operational independence in the Security Considerations, 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 and encoded as exactly 64 lowercase hexadecimal characters; this narrows the -00/-01 wording, which only RECOMMENDED SHA-256. Added a Known Limitations section. 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