<?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-singh-psi-agent-01" ipr="trust200902" submissionType="IETF" version="3" xml:lang="en">
<front><title abbrev="PSI Agent">PSI Receipts for AI Agent Actions</title><seriesInfo name="Internet-Draft" value="draft-singh-psi-agent-01"/><author fullname="Kawaljeet Singh" initials="K." surname="Singh"><organization>APEX Infrastructure</organization>
<address><postal><city>Melbourne</city><region>Victoria</region><country>Australia</country></postal>
<email>kawaljeet.singh3008@gmail.com</email><uri>https://ai-governance-standard.com</uri></address></author>
<date year="2026" month="October" day="13"/>
<abstract><t>This document defines a profile of Proof of Stateful Integrity (PSI) for recording actions taken by software agents, including calls to language models and tools.  The agent runtime computes a digest of each action locally and seals only the digest, so later alteration or omission of a recorded action is detectable.  A receipt shows that a specific action record existed unchanged at a time; it does not show that the action was correct, safe, authorised, or lawful, and it allocates no liability.</t><t>This revision withdraws the liability-allocation language of revision 00 and aligns the Merkle commitment with draft-singh-psi-merkle-01.</t></abstract></front><middle><section><name>Introduction</name><t>Agents act without a human reviewing each step.  When a result is disputed, parties need to know which actions were recorded and whether the record was edited.  The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>SHOULD</bcp14>", and "<bcp14>MAY</bcp14>" in this document are to be interpreted as described in BCP&#160;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t></section><section><name>Action Record</name><t>An action record is a JSON object that MUST contain <tt>event</tt> (for example <tt>llm_end</tt>, <tt>tool_end</tt>, <tt>decision</tt>), <tt>name</tt> (the function or tool), and <tt>result</tt> or <tt>outputs</tt>; it MAY contain <tt>args</tt> and <tt>prev</tt>, the digest of the previous action in the same run.  The digest is SHA-256 over the canonical form of <xref target="RFC8785"/>.  Records SHOULD NOT contain personal data; if they must, a salt of at least 128 bits MUST be included.</t></section><section><name>Sealing</name><t>The runtime submits <tt>sha256:&lt;digest&gt;</tt> to the issuer and receives a receipt per <xref target="PSI"/>.  Sealing SHOULD be asynchronous so the agent does not wait on the network, and a sealing failure MUST NOT alter the agent's action.  A run is chained by including <tt>prev</tt>; sealing the final digest of the chain commits the whole run.</t></section><section><name>Verification</name><t>A verifier recomputes the digest from the held record, checks the receipt signature (Ed25519 <xref target="RFC8032"/>, and ML-DSA-65 <xref target="FIPS204"/> when present), and checks inclusion per <xref target="I-D.merkle"/>.</t></section><section><name>Security Considerations</name><t>A runtime that is compromised can seal false records; sealing does not attest to the runtime.  Unsealed actions are not detected unless runs are chained.  Digests of low-entropy records can be guessed; use a salt.</t></section><section><name>IANA Considerations</name><t>This document has no IANA actions.</t></section></middle><back><references><name>References</name><references><name>Normative References</name><reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"><front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner"/><date year="1997" month="March"/></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/></reference><reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"><front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title><author initials="B." surname="Leiba"/><date year="2017" month="May"/></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="8174"/></reference><reference anchor="RFC8785" target="https://www.rfc-editor.org/info/rfc8785"><front><title>JSON Canonicalization Scheme (JCS)</title><author initials="A." surname="Rundgren"/><author initials="B." surname="Jordan"/><author initials="S." surname="Erdtman"/><date year="2020" month="June"/></front><seriesInfo name="RFC" value="8785"/></reference><reference anchor="PSI" target="https://datatracker.ietf.org/doc/draft-singh-psi/"><front><title>Proof of Stateful Integrity (PSI): Signed, Merkle-Committed Receipts for Digital Records</title><author initials="K." surname="Singh"/><date year="2026" month="October"/></front><seriesInfo name="Internet-Draft" value="draft-singh-psi-02"/></reference></references><references><name>Informative References</name><reference anchor="I-D.merkle" target="https://datatracker.ietf.org/doc/draft-singh-psi-merkle/"><front><title>PSI Merkle Commitment Profile (RFC6962-SHA256)</title><author initials="K." surname="Singh"/><date year="2026" month="October"/></front><seriesInfo name="Internet-Draft" value="draft-singh-psi-merkle-01"/></reference><reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032"><front><title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title><author initials="S." surname="Josefsson"/><author initials="I." surname="Liusvaara"/><date year="2017" month="January"/></front><seriesInfo name="RFC" value="8032"/></reference><reference anchor="FIPS204" target="https://doi.org/10.6028/NIST.FIPS.204"><front><title>Module-Lattice-Based Digital Signature Standard</title><author initials="" surname="NIST"/><date year="2024" month="August"/></front><seriesInfo name="FIPS" value="204"/></reference></references></references></back></rfc>