Signed, Hash-Chained Action Receipts for AI Agents

Signed, Hash-Chained Action Receipts for AI Agents kriya native

India nancysahu@kriyanative.com

Security AI agents audit non-repudiation tamper-evidence receipts This document specifies a format for action receipts: compact, individually signed JSON records that state that a specific AI agent attempted a specific action at a specific time, under a specific policy decision, and what the outcome was. Receipts are linked into an append-only hash chain so that deletion, insertion, reordering, or modification of any previously recorded receipt is detectable by a verifier that holds only the records and the signer's public key. The format is deliberately small and self-contained. Verification requires no network access, no service operated by the producer of the receipts, and no state beyond the records themselves and a trust anchor obtained out of band. This document specifies the record fields, the canonical byte sequence that is signed, the chain linkage rule, the verification procedure, and test vectors.

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: requires automatic recording of events over the lifetime of high-risk systems, and 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:

Attributable. Each record carries a detached signature over its own canonical bytes, verifiable against a public key.
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.
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 ) how external anchoring composes with it where such anchoring is available.

Relationship to Existing Work Signed records of agent actions are an active area with a substantial body of concurrent independent work. Neither hash-chaining such records, nor signing them with Ed25519, nor verifying them offline is novel to this document, and this section states plainly what is shared and what is not. Records that are individually signed and linked to their predecessor are specified in (optionally, as a commitment mode) and required in , which profiles it for regulatory use. specifies an append-only chained evidence record recomputable without trusting the producing runtime, and specifies a newline-delimited JSON audit record with an equivalent linkage member. and specify richer records carried as transparency-service statements while retaining an offline verification mode, and specifies a per-record chain with sequence numbers alongside an independent custodian of the log. Against that body of work this document is distinguished by one construction and one constraint. The construction: the chain link is the digest of the previous record as transmitted, over its exact octets including its signature and including any member the verifier does not recognize (). Every other linkage cited above digests a re-canonicalization of the previous record, or of that record with its signature removed. Digesting the transmitted octets means chain verification is independent of agreement about canonicalization, requires no canonicalizer at all, and covers extension members that a re-canonicalized digest would exclude. The constraint: base verification is specified as a pure function of the records and a trust anchor, with no anchor, log, service, or timestamp authority anywhere in the required path, because the deployments this format serves may have none. This document specifies a record format, not an audit architecture. describes an architecture for auditing agent delegation and interaction without specifying a wire format; the format here is intended to be usable as one concrete realization of records within such an architecture. specifies an architecture for supply-chain integrity, transparency, and trust, including transparency services that issue receipts for registered signed statements. That architecture and this format are complementary: the records specified here are self-anchored by default, and a transparency service can additionally anchor chain heads where one is available and trusted. discusses this.

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 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 .
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.

Receipt Object A receipt is a JSON object . The following members are defined. Receipt members

Member	Type	Presence	Description
step_id	string	REQUIRED	Identifier for this action, unique within the log.
action_id	string	REQUIRED	Identifier for the kind of action, for example a tool name or a namespaced decision identifier.
params	any JSON value	REQUIRED	Structured detail about the action. See .
success	boolean	REQUIRED	Whether the action succeeded.
ts_ms	number	REQUIRED	Time of the action as an integer count of milliseconds since 1970-01-01T00:00:00Z, host-asserted.
actor	object	OPTIONAL	Attribution, with members agent (string) and user (string), in that order.
prev_hash	string	OPTIONAL	Chain link, as specified in . Absent on the first receipt of a log.
public_key	string	REQUIRED	The signer's Ed25519 public key, 32 octets, lowercase base16 .
signature	string	REQUIRED	Detached Ed25519 signature, 64 octets, lowercase base16 .

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 . 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.

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:

step_id
action_id
params
success
ts_ms
actor, omitted entirely if absent
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 , escaping only those characters that 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. records the question of whether a future revision should adopt throughout.

Interoperability Constraints Implementations that construct or verify the canonical sequence MUST be able to reproduce these cases identically, and deployments SHOULD avoid the two constructions below until a future revision resolves them:

Non-ASCII member names inside params. Sorting by Unicode code point and sorting by UTF-8 byte sequence agree for all code points; implementations that sort by UTF-16 code unit do not agree for code points above U+FFFF.
Non-integer numbers anywhere in the signed members. Shortest-round-trip formatting of binary floating-point values differs between implementations. Deployments SHOULD represent quantities as integers in a stated minor unit, or as strings.

Signature The signature is a detached Ed25519 signature as specified in , computed over the canonical byte sequence of , encoded as 128 lowercase base16 characters . 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.

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 of the exact octets of the immediately preceding line, excluding its terminating newline, encoded as 64 lowercase base16 characters . 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.

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:

Parse the line as JSON. If parsing fails, record a failure at this position and stop treating subsequent prev_hash values as meaningful.
Check that the required members of are present and of the specified types.
Reconstruct the canonical byte sequence per from the parsed members.
Verify the signature over that sequence using public_key.
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.
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 .

Extensions Additional members MAY be added to a receipt. Members that are not in the signed set of 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.

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 ; it may be counter-signed by an independent party, bound to a timestamp token , committed to an external ledger , or registered with a transparency service . 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; 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 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 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 exist for this reason and implementations SHOULD test against the vectors in .

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 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.

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 of this document.
Interoperability considerations:: See 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 .

Implementation Status This section records the implementation status of the format at the time of writing, in the spirit of . 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 were produced by one implementation and verified by another.

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

Canonicalization. Much concurrent work in this space uses . The construction in 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 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 , 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 .
Algorithm agility. Whether to specify a general signature-algorithm member rather than fixing Ed25519, and how such a member would interact with .
Relationship to logging standards. A mapping annex from these fields to the information model of , to make the format usable as an implementation of that model. No published work in this space appears to have made such a mapping.

Normative References Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words The JavaScript Object Notation (JSON) Data Interchange Format Edwards-Curve Digital Signature Algorithm (EdDSA) US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) The Base16, Base32, and Base64 Data Encodings Informative References JSON Canonicalization Scheme (JCS) Improving Awareness of Running Code: The Implementation Status Section Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) An Architecture for Trustworthy and Transparent Digital Supply Chains Signed Decision Receipts for Machine-to-Machine Access Control Compliance Profile of Signed Action Receipts for AI Agents The evidence.* Family: Post-Hoc, Independently Recomputable Evidence Records for AI Agent Actions Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems A SCITT Profile for AI-Agent Action Receipts An Agent Action Capsule Profile for SCITT Selective Disclosure Profile for Agent Action Capsules AI Agent Execution Profile of SCITT An Architecture for Auditing AI Agent Delegation and Interactions The MVPS Operational Log Format: Append-Only, Hash-Chained, Externally-Anchored Audit Logs Bitcoin-Anchored Temporal Proof for Transparency Services Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) European Parliament and Council of the European Union Information technology - Artificial intelligence - AI system logging ISO/IEC JTC 1/SC 42

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.

Vector 1: Genesis Receipt Canonical byte sequence (UTF-8, no trailing newline; line-wrapped here for presentation only): Note that params appears sorted (class, rule_id, tier) in the canonical sequence while the serialized line below carries the members in their original order, and that prev_hash is absent entirely. Serialized line: SHA-256 of that line's octets, which is the prev_hash of vector 2:

Vector 2: Chained Receipt Canonical byte sequence: Serialized line:

Vector 3: Detection of Modification Replacing the string alice with mallory in the actor.user member of vector 1 produces a line whose signature verification fails, and whose SHA-256 digest no longer equals the prev_hash of vector 2. A conforming verifier reports a signature failure at line 1 and a chain break at line 2.

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 , and notes that the convergence of several unrelated efforts on similar constructions is itself evidence that the requirement is real.