A SCITT Profile for AI-Agent Action 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 25 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. 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

Agent connectivity and orchestration standards (MCP, A2A) and agent runtimes leave the accountability layer — a standardized, tamper-evident, non-repudiable record of an agent's actions — open. OWASP classifies "Lack of Audit and Telemetry" (MCP08:2025) as CRITICAL, and A2A explicitly states it "does not address non-repudiation." Several recent efforts emit signed PERMIT/DENY decision receipts for agent actions; what is missing is a single, SCITT-native, COSE-based profile for per-action receipts that is (a) registrable in a Transparency Service and (b) honest about exactly what a receipt does and does not prove.¶

This profile does NOT invent a new wire format. A receipt is a SCITT Signed Statement (COSE_Sign1), so it verifies in any conforming COSE implementation and composes with any SCITT Transparency Service.¶

2. Terminology

• Action receipt: a COSE_Sign1 Signed Statement attesting one agent action.¶
• Principal: the authority on whose behalf the action occurred (HUMAN, SERVICE, POLICY, or a sandbox simulation marker).¶
• Policy: a deterministic, side-effect-free decision rule set with a stable content hash (policyHash) used as its published identity.¶
• Identity manifest: an out-of-band, operator-vouched binding of agent.id to its authorized key identifier(s) (kid), used to authenticate which agent acted, not merely that a trusted key signed.¶
• Genesis-bound chain: a per-scope hash chain whose checkpoint authority is bound to the key that opened the chain (sequence 0), so a re-heading attacker cannot substitute a foreign checkpoint.¶
• Transparency Service (TS): as defined by the SCITT Architecture.¶

3. Receipt structure (payload)

The COSE_Sign1 payload is the RFC 8785 (JCS) canonical serialization of a JSON object. All numbers MUST be integers (no floating-point); all strings MUST be Unicode NFC. The fields:¶

{
  "spec":   "noa.receipt/0.1",
  "id":     "<receipt id>",
  "ts":     "<RFC 3339 UTC timestamp>",
  "scope":  { "tenant": "<id>", "chain": "<chain id>" },
  "agent":  { "id": "<agent id>", "model": "<vendor/model|null>",
              "principal": "HUMAN|SERVICE|POLICY|SANDBOX_SIM" },
  "action": { "id": "<tool/action id>", "canonical": "<risk-table key>",
              "riskClass": "LOW|MEDIUM|HIGH|CRITICAL|IRREVERSIBLE",
              "paramsHash": "sha256:<hex>|hmac-sha256:<hex>",
              "reversible": <bool>, "rollbackRef": "<id|null>" },
  "governance": { "mode": "<governance mode>", "verdict": "<terminal verdict>",
                  "ruleId": "<id>",
                  "approval": { "by": "<approver>", "at": "<RFC 3339 UTC>" }|null,
                  "sandboxed": <bool> },
  "chain":  { "seq": <int>, "prevHash": "sha256:<hex>|null", "hash": "sha256:<hex>" }
}

Receipts carry only hashes of action parameters and policy inputs, never raw prompts, tool arguments, secrets, or other sensitive parameters (this aligns with the ACTA "MUST NOT include raw inputs" rule). paramsHash MAY be hmac-sha256:<hex> with a tenant-scoped key where a plain SHA-256 over a low-entropy value (an amount, an id, a boolean) would be guessable.¶

chain.hash is computed as "sha256:" + SHA-256( JCS( receipt WITHOUT chain.hash AND WITHOUT sig.value ) ). Receipts in one scope are linked by prevHash; prevHash is null only at the genesis receipt (seq == 0).¶

4. COSE Signed Statement profile

5. Hash-chaining and completeness

Each receipt carries a monotonic chain.seq (genesis = 0) and prevHash. A verifier checking a range of receipts MUST verify: each prevHash equals the prior receipt's chain.hash; the genesis receipt has prevHash == null; and, when a signed checkpoint is present, the checkpoint authority is bound to the genesis key (the key authorized at seq == 0), so a foreign checkpoint produced by a re-heading attacker is rejected. This profile detects in-band tampering and tail truncation within a presented chain; it does NOT, by itself, detect equivocation (an issuer signing two divergent chains) — that requires registration in a SCITT Transparency Service or an equivalent external witness.¶

6. Identity binding

agent.id is a signer-asserted label. To authenticate WHICH agent acted (not merely that a trusted key signed), a verifier MAY be supplied an identity manifest binding agent.id to its authorized kid(s). When a manifest is present, a receipt or checkpoint whose (agent.id, sig.kid) pairing is not authorized MUST be rejected as UNTRUSTED. Without a manifest, attribution is key-level only, and implementations MUST surface that limitation to the relying party.¶

7. Registration in a Transparency Service

A receipt is a SCITT Signed Statement and MAY be submitted to a Transparency Service. The Registration Policy for this profile is: the TS MUST verify the COSE_Sign1 signature; MUST verify the protected header conforms to {{cose}} (an alg of -19, deterministic CBOR, a resolvable key identifier); and SHOULD verify the CWT_Claims iss/sub against the registering identity. On success the TS returns a Transparency Receipt that provides the non-equivocation and inclusion properties a self-signed chain cannot provide alone.¶

8. Relationship to ACTA signed receipts (equivalence)

draft-farley-acta-signed-receipts catalogues receipt fields in a custom JSON envelope (not COSE_Sign1). The mapping to this SCITT-native profile:¶

ACTA receipts can be registered as SCITT Signed Statements only via an adapter; receipts in this profile are COSE_Sign1 natively.¶

9. Policy-replay is OUT OF SCOPE for this revision

A deterministic, offline policy-REPLAY capability — a verifier re-running the in-force policy over the recorded inputs to re-derive the recorded verdict, with no access to the agent, model, or any service — is a distinct capability that this revision deliberately does NOT specify. A separate companion profile will define the policy-commitment field(s) needed to enable such a check; this revision does not carry them. The replay construction (the deterministic evaluation grammar, operator set, evaluation order, input-commitment scheme, and conformance vectors) is left to that separate companion profile and is not normative here. Implementations MUST NOT represent a receipt under this profile as carrying a re-derivable verdict.¶

10. Security Considerations

This profile attests exactly two things: (1) the record is tamper-evident and signature-verifiable under the issuer's key; and (2) the recorded fields (action, principal, policy identity, verdict) are bound into that signature. It does NOT attest that the recorded inputs are true, complete, or timely (no capture-completeness); that the policy was adequate; that no action occurred outside the instrumented boundary; that the agent was correct, safe, or wise; or any real-world outcome. These non-goals are NORMATIVE: implementations and relying parties MUST NOT imply the stronger claims from a receipt.¶

Equivocation, fork, and cross-chain tail-truncation are detectable only with an external witness or a SCITT Transparency Service. Identity attribution above key level requires the out-of-band identity manifest. Algorithm-confusion and key-confusion attacks are mitigated by the strict alg = -19 and pinned-curve requirements of {{cose}}. Raw prompts, tool arguments, and secrets MUST NOT appear on a receipt; only hashes (optionally HMAC for low-entropy values) are carried.¶

11. IANA Considerations

This document has no IANA actions in this revision. It uses the existing IANA COSE Algorithms registry value -19 (Ed25519) and the existing COSE/CWT header parameters. A future revision MAY request registration of a media type for the action-receipt payload and/or of CWT or COSE claims for the payload fields.¶

Appendix A. Implementation status

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

A zero-runtime-dependency reference implementation (signer, offline verifier, deterministic CBOR, COSE_Sign1 profile, JCS canonicalizer, conformance vectors, and a second independent verifier in another language) is available under the Apache-2.0 license at https://github.com/NordenSoft/noa. Two independent VERIFIERS currently agree byte-for-byte on the receipt-chain conformance vectors; a second independent signer/evaluator and a shared conformance vector pack are the interoperability bar this profile is working toward.¶

NOTE (alg migration): the current reference implementation emits the now-deprecated polymorphic EdDSA identifier -8 ([RFC9053], protected header bytes a10127). Migration to the fully-specified -19 ([RFC9864], protected header bytes a10132), with regenerated cross-implementation conformance vectors, is in progress and is a precondition for any normative revision.¶

Appendix B. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597.
[RFC9864] Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JOSE and COSE", RFC 9864.
[SCITT-ARCH] Birkholz, H., et al., "An Architecture for Trustworthy and Transparent Digital Supply Chains", draft-ietf-scitt-architecture.

Appendix C. Informative References

[ACTA] Farley, T., "ACTA Signed Receipts", draft-farley-acta-signed-receipts.
[SCITT-VCP] Kamimura, T., "A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading", draft-kamimura-scitt-vcp.
[AI-ART50] Dawkins, V., "A SCITT Profile for EU AI Act Article 50 Transparency Receipts", draft-dawkins-scitt-ai-article50.
[AIVS] Stone, B., "AIVS: Agentic Integrity Verification Standard", draft-stone-aivs.
[OWASP-MCP] OWASP, "MCP Top 10 (MCP08:2025 — Lack of Audit and Telemetry)".

Author's Address