Signed, Hash-Chained Action Receipts for AI Agents

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 17 February 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Software agents built on large language models now take consequential actions on behalf of organizations: they deploy code, modify databases, send messages, install dependencies, and initiate payments. Organizations deploying such agents are increasingly required to answer, after the fact, a narrow and concrete question: what did this agent do, under whose authority, and can that answer be checked by someone who does not trust the party providing it.¶

Existing telemetry does not answer that question. Application logs, distributed traces, and vendor audit consoles are written by, and mutable by, the same operator whose conduct is in question. A record that the operator can silently edit is evidence of intent, not evidence of fact. Regulatory instruments increasingly assume the existence of something stronger: [EU-AI-ACT] requires automatic recording of events over the lifetime of high-risk systems, and [ISO24970] specifies an information model for AI system logging, but neither prescribes an interoperable record format with integrity properties, and neither can be satisfied by a format that only its author can check.¶

This document specifies such a format. It has three properties, in ascending order of what they cost to provide:¶

1. Attributable. Each record carries a detached signature over its own canonical bytes, verifiable against a public key.¶
2. Tamper-evident as a sequence. Each record commits to the exact bytes of the record before it, so that removing, inserting, reordering, or editing any earlier record invalidates the chain at a determinate position.¶
3. Independently verifiable offline. Verification is a pure function of the records and a trust anchor. It requires no network, no service, and no cooperation from the party that produced the records.¶

The third property is the design constraint that shapes the rest of the format. Deployments in regulated, disconnected, or air-gapped environments cannot rely on a transparency service being reachable, and auditors in adversarial settings cannot rely on one being honest. This document therefore specifies a format whose base verification is self-contained, and identifies (in Section 13) how external anchoring composes with it where such anchoring is available.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following terms are used:¶

Action:

An operation an agent attempts that a deployment has chosen to record, such as executing a command, invoking a tool, or writing a file.¶

Receipt:

One signed JSON object recording one action, as specified in Section 3.¶

Receipt log:

An ordered sequence of receipts produced by one signer, serialized as newline-delimited JSON.¶

Signer:

The entity holding the private key. In deployments motivated by this document the signer is the enforcement point co-located with the agent, not the agent itself.¶

Verifier:

An entity that checks receipts. A verifier holds no private keys and needs no network access.¶

3. Receipt Object

A receipt is a JSON object [RFC8259]. The following members are defined.¶

A receipt MAY contain additional members. A verifier MUST ignore members it does not recognize, and MUST NOT include them in the signed byte sequence. This rule is what permits the format to be extended without invalidating deployed verifiers; an example extension is given in Section 8.¶

The members public_key and signature are carried in the receipt but are not themselves part of the signed byte sequence, for the obvious reason.¶

4. Canonical Byte Sequence

The signature is computed over a canonical byte sequence derived from the receipt. The sequence is the UTF-8 encoding of a compact JSON serialization (no whitespace between tokens) of an object containing exactly the signed members, constructed as follows.¶

The signed members appear in this fixed order, which is NOT lexicographic:¶

1. step_id¶
2. action_id¶
3. params¶
4. success¶
5. ts_ms¶
6. actor, omitted entirely if absent¶
7. prev_hash, omitted entirely if absent¶

Within params, and recursively within every JSON object nested inside params, member names MUST be sorted in ascending order by their Unicode code points. Array element order is semantic and MUST be preserved. Within actor, the members appear in the fixed order agent, then user; they are NOT sorted.¶

Omission is total: an absent actor or prev_hash contributes no member name, no value, and no separator. A receipt with no actor therefore signs identically to how it would have signed had the member never been defined.¶

Numbers MUST be serialized without exponent, without a leading plus sign, and without insignificant trailing zeros. Strings MUST be serialized using the shortest form permitted by [RFC8259], escaping only those characters that [RFC8259] requires to be escaped, using lowercase hexadecimal in \uXXXX escapes.¶

Note on two constructions. The outer member order above is fixed and non-lexicographic, while params is sorted. This asymmetry reflects deployed practice rather than aesthetics, and it is stated normatively here so that independent implementations agree byte-for-byte. Section 13 records the question of whether a future revision should adopt [RFC8785] throughout.¶

5. Signature

The signature is a detached Ed25519 signature as specified in [RFC8032], computed over the canonical byte sequence of Section 4, encoded as 128 lowercase base16 characters [RFC4648]. The public key is encoded as 64 lowercase base16 characters. A verifier MUST reject a receipt whose public_key or signature is not of the exact expected length or contains characters outside the set 0-9 and a-f.¶

Ed25519 is deterministic, so a receipt signed by any conforming implementation produces byte-identical signature octets. A verifier therefore need not know which cryptographic module produced a receipt in order to verify it.¶

6. Chain Linkage

A receipt log is a sequence of receipts serialized as newline-delimited JSON: one receipt per line, no line containing an unescaped newline.¶

The first receipt of a log MUST NOT contain prev_hash. Every subsequent receipt MUST contain prev_hash, whose value is the SHA-256 digest [RFC6234] of the exact octets of the immediately preceding line, excluding its terminating newline, encoded as 64 lowercase base16 characters [RFC4648].¶

The digest is computed over the octets as serialized, including public_key and signature and including any member a verifier does not recognize. A verifier MUST NOT re-serialize, reformat, or normalize a line before computing its digest; doing so defeats the check.¶

Because prev_hash is part of the canonical byte sequence, each signature transitively commits to every earlier line in the log.¶

7. Verification

Given a receipt log and a trust anchor, a verifier performs the following. The procedure requires no network access and no state beyond its inputs.¶

For each line, in order:¶

1. Parse the line as JSON. If parsing fails, record a failure at this position and stop treating subsequent prev_hash values as meaningful.¶
2. Check that the required members of Section 3 are present and of the specified types.¶
3. Reconstruct the canonical byte sequence per Section 4 from the parsed members.¶
4. Verify the signature over that sequence using public_key.¶
5. For the first line, check that prev_hash is absent. For every subsequent line, check that prev_hash equals the SHA-256 digest of the previous line's octets.¶
6. Check that public_key matches the trust anchor for the expected signer.¶

A verifier MUST report a failure at a determinate position rather than discarding the offending line, and MUST NOT report an overall success if any line failed. A line that is not a well-formed receipt MUST surface as a failure and MUST NOT be silently skipped: an unparseable or unsigned line inserted into a log is precisely the event the format exists to make visible.¶

Step 6 is not optional. Steps 1 through 5 prove that a log is internally consistent and was produced by the holder of some key; only step 6 connects that key to an identity the verifier cares about. See Section 9.¶

8. Extensions

Additional members MAY be added to a receipt. Members that are not in the signed set of Section 4 are ignored by verifiers implementing this document, which allows deployments to carry correlation identifiers, source labels, or transport metadata without coordination.¶

A member that must be integrity-protected cannot be added this way; it requires a profile that extends the signed set, and such a profile MUST specify its position in the canonical order.¶

An example of an extension that requires no change to the signed set is a second signature over the same canonical bytes using a different algorithm, carried in additional members alongside the Ed25519 signature. A verifier that does not implement the second algorithm ignores those members and still obtains a correct Ed25519 verdict; a verifier that does implement it MUST reject a receipt in which those members are present but incomplete or inconsistent, since a partially-present second signature is indistinguishable from an attempt to strip it.¶

9. Security Considerations

This format provides tamper-evidence, not tamper-proofing. The distinction is load-bearing and implementers are cautioned against describing it otherwise.¶

A compromised signer can produce arbitrary receipts. The private key signs whatever it is given. An adversary who obtains the key, or who executes code with the signer's privileges, can produce a well-formed log of events that never happened, or re-sign an edited history from any point forward. Nothing in this document detects that. What the format provides is that such an adversary must possess the key: a party who holds only the records cannot alter them undetectably.¶

Actions that were never recorded leave no trace. The chain proves that no recorded receipt was removed. It says nothing about actions the signer declined to record, whether by omission, misconfiguration, or suppression before signing. Claims of the form "this log shows everything the agent did" are not supported by this format; claims of the form "this log has not been altered since it was written" are.¶

A log can be truncated at its end. Removing the most recent N receipts leaves a shorter but internally consistent chain, and no property of the presented records reveals the omission. This is a general limit of self-anchored chains rather than a property of this format: detecting head truncation requires state outside the log. The minimal such state is a signed head assertion carrying at least the chain identity, the record count, and the head digest, as described for append-only logs in [I-D.melegassi-opsawg-mvps-logging]; it may be counter-signed by an independent party, bound to a timestamp token [RFC3161], committed to an external ledger [I-D.fassbender-scitt-time-anchor], or registered with a transparency service [RFC9943]. Deployments that require truncation detection MUST provide such an anchor. This document deliberately does not require one, because the deployments it targets may have no reachable anchor at all; Section 13 records the head assertion as work for a future revision.¶

Key binding is out of scope. A valid signature proves the record was signed by the holder of the key in public_key, and nothing more. A verifier that omits step 6 of Section 7 verifies only that an adversary is internally consistent. Trust anchors MUST be obtained through a channel independent of the log.¶

Timestamps are asserted, not attested. The ts_ms member is the signer's clock reading. It is not evidence of time and MUST NOT be relied on where an adversary controls the host. Where bounded time is required, an external timestamp token [RFC3161] over chain heads provides an upper bound.¶

One writer per chain. The linkage rule assumes a single writer appending to one log. Concurrent writers produce forks that verify individually but break the chain. Each signer SHOULD maintain its own log; merging across signers is a verifier-side concern and MUST NOT be done by rewriting lines.¶

Canonicalization is an attack surface. An implementation that reconstructs the canonical sequence differently from the signer will report spurious failures; one that is lenient where the signer is strict may accept two distinct receipts as equivalent. The constraints in Section 4 exist for this reason and implementations SHOULD test against the vectors in Appendix A.¶

10. Privacy Considerations

The params member is the one most likely to carry sensitive content, and deployments control what it contains. Receipts are evidence that an action occurred and how it was decided; they need not, and generally SHOULD NOT, contain the content the action operated on. Deployments SHOULD record identifiers, digests, counts, and decisions rather than payloads, prompts, message bodies, file contents, credentials, or personal data.¶

This is not merely advice about hygiene. Receipts are designed to be retained for long periods, exported to auditors, and verified by parties outside the organization that produced them, so content placed in params propagates further and lives longer than content in ordinary logs. Where a receipt must commit to content, it SHOULD carry a digest of that content rather than the content itself.¶

Where a deployment must retain a value rather than replace it with a digest, and disclose it to some verifiers but not others, a per-field selective-disclosure construction such as [I-D.mih-scitt-agent-action-capsule-sel-disc] can be applied to the params value. Such a construction changes the value of params and not the set of signed members, so it composes with this format without altering the signature or the chain: the chain link is computed over the transmitted octets whatever those octets contain. Chain linkage members MUST NOT be made concealable by any such profile.¶

The actor member attributes an action to a named agent and user. Unless bound to an external identity system, these values are self-asserted by the signer and constitute attribution, not authentication. Deployments SHOULD treat them accordingly, and MAY omit actor entirely where attribution is not required.¶

11. IANA Considerations

This document requests registration of the following media type in the "Media Types" registry.¶

Type name:

application¶

Subtype name:

agent-receipt+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary; the content is UTF-8 encoded JSON.¶

Security considerations:

See Section 9 of this document.¶

Interoperability considerations:

See Section 4 of this document.¶

Published specification:

This document.¶

Applications that use this media type:

AI agent governance, audit, and compliance tooling.¶

Fragment identifier considerations:

N/A¶

Person and email address to contact for further information:

The author of this document.¶

Intended usage:

COMMON¶

Author/Change controller:

IETF¶

Whether the action_id member warrants an IANA registry of namespaces is left open; see Section 13.¶

12. Implementation Status

This section records the implementation status of the format at the time of writing, in the spirit of [RFC7942]. It is intended to be removed before publication as an RFC.¶

The format is implemented and deployed in commercially available software for macOS that records governed agent actions on end-user devices and in enterprise fleets. Four independent verifier implementations exist: a compiled implementation used by the producing software and by a standalone command-line auditor that holds no keys and makes no network calls; a second implementation in TypeScript using platform cryptography, used for browser-side verification; a self-contained HTML export that re-verifies its own embedded receipts with no network access; and the command-line auditor's bundle and range verification modes.¶

The vectors in Appendix A were produced by one implementation and verified by another.¶

13. Open Issues

This section is intended to be removed before publication as an RFC.¶

• Canonicalization. Much concurrent work in this space uses [RFC8785]. The construction in Section 4 is what deployed implementations sign, and it permits a signer to emit a record in one pass without a canonicalizer; a future revision should either state that rationale normatively or adopt JCS and accept incompatibility with already-signed records. Note that the choice affects only the signature: chain linkage per Section 6 is over transmitted octets and is unaffected either way.¶
• Domain separation. The signature is computed over the canonical bytes directly, with no protocol-identifying prefix. A future revision should consider a domain separation tag so that these bytes cannot be replayed as, or confused with, a signature in another protocol.¶
• Sequence numbers. Linkage alone detects modification, reordering, and removal of interior records, but cannot distinguish a gap from a duplicate position, and cannot express per-signer ordering independently of the file. Whether to add a monotonic sequence member to the signed set is open.¶
• Head assertions. A signed head object (chain identity, record count, head digest) addressing the truncation limit in Section 9, together with the anchoring transports named there, for deployments that have somewhere to anchor it.¶
• The action_id namespaces. Whether cross-organization interoperability requires a registry, or whether unregistered reverse-DNS-style namespacing is sufficient. A useful precedent is a Specification Required registry that governs shared meaning while requiring verifiers to accept unregistered values, as used in [I-D.mih-scitt-agent-action-capsule].¶
• Algorithm agility. Whether to specify a general signature-algorithm member rather than fixing Ed25519, and how such a member would interact with Section 4.¶
• Relationship to logging standards. A mapping annex from these fields to the information model of [ISO24970], to make the format usable as an implementation of that model. No published work in this space appears to have made such a mapping.¶

Appendix A. Test Vectors

The signing key below is a test key and MUST NOT be used for any other purpose. It is a 32-octet Ed25519 seed consisting of the octet 0x01 repeated 32 times.¶

seed:
0101010101010101010101010101010101010101010101010101010101010101
public_key:
8a88e3dd7409f195fd52db2d3cba5d72ca6709bf1d94121bf3748801b40f6f5c

{"step_id":"01J8Z7QX9K","action_id":"kriya.gate.decision","params"
:{"class":"publish","rule_id":"npm-publish","tier":"approve"},"suc
cess":true,"ts_ms":1755300000000,"actor":{"agent":"claude-code","u
ser":"alice"}}

{"step_id":"01J8Z7QX9K","action_id":"kriya.gate.decision","params"
:{"rule_id":"npm-publish","tier":"approve","class":"publish"},"suc
cess":true,"ts_ms":1755300000000,"actor":{"agent":"claude-code","u
ser":"alice"},"public_key":"8a88e3dd7409f195fd52db2d3cba5d72ca6709
bf1d94121bf3748801b40f6f5c","signature":"ab6afa750440d38f72dc5601f
45b1df918de60049b2accbb438dd909222f42755a534ee67e2eb1397f9d3ca6bd0
bf67f1ec078ecc60c08c92438acd2b7dc5802"}

18a2a79ac5e4dcc31172783a0f33efc1518d426c5cf0ccd24982d41c9aa3ee4c

{"step_id":"01J8Z7QXB2","action_id":"kriya.gate.approval","params"
:{"approver":"alice","decision":"approved","rule_id":"npm-publish"
},"success":true,"ts_ms":1755300012000,"actor":{"agent":"claude-co
de","user":"alice"},"prev_hash":"18a2a79ac5e4dcc31172783a0f33efc15
18d426c5cf0ccd24982d41c9aa3ee4c"}

{"step_id":"01J8Z7QXB2","action_id":"kriya.gate.approval","params"
:{"rule_id":"npm-publish","approver":"alice","decision":"approved"
},"success":true,"ts_ms":1755300012000,"actor":{"agent":"claude-co
de","user":"alice"},"prev_hash":"18a2a79ac5e4dcc31172783a0f33efc15
18d426c5cf0ccd24982d41c9aa3ee4c","public_key":"8a88e3dd7409f195fd5
2db2d3cba5d72ca6709bf1d94121bf3748801b40f6f5c","signature":"891dc8
8a6dc93507faca8d52eceb0baf107f325a1b3bb5c60e3e357cac86d6ccfd2a0bcf
3cee3b7237040483fe1b8c4f049fa72c6a59eb97a22d2c7e97d2cc02"}

Acknowledgments

A considerable body of concurrent independent work established signed records of agent actions as a subject worth specifying, and sharpened the problem statement this document responds to. The author thanks the authors of that work, cited throughout and surveyed in Section 1.1, and notes that the convergence of several unrelated efforts on similar constructions is itself evidence that the requirement is real.¶

Author's Address