Veridic Inc.

e.pinar@theveridic.ai https://theveridic.ai

Veridic Inc.

f.daniel@theveridic.ai https://theveridic.ai

Security This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper-evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS, and MiFID II.

Introduction

The Post-Execution Evidence Problem Autonomous AI agents execute consequential actions -- payments, trades, contracts, regulated data access -- at machine speed, often without contemporaneous human review. When such an action is later disputed, a counterparty, an auditor, or a regulator needs to be able to establish, without relying on the agent operator, who made the record of it, the latest time at which that record can have been made, and that the record has not been altered since. Operator-controlled audit logs are mutable by the operator, carry no third-party attestation, and are not designed for independent verification. This profile addresses the gap by defining how independently custodied, post-execution evidence records bind to the SCITT architecture. The requirement that an agent's actions be recorded as signed, timestamped entries held by a party other than the agent's operator draws on the triple-entry accounting model , in which a signed receipt, held by a third party as well as by the two transacting parties, becomes the shared record that binds them. Under this profile, an agent that acts without producing a signed record has left the scope of what can be externally verified. This profile does not establish that a record is accurate.

Relationship to SCITT This profile is an application of . It:

• REQUIRES compliance with
• REQUIRES AIRs to be encoded as COSE_Sign1 Signed Statements
• DEFINES domain-specific extensions for AI agent execution evidence

The first item above has one exception in this revision. requires a Transparency Service to produce COSE Receipts as defined in . The Evidence Receipt in is not yet specified in that form. The SCITT architecture's non-equivocation property is particularly significant for this domain: its purpose is that two different Relying Parties cannot be shown two different versions of the same Evidence Chain. This revision does not yet define the proofs on which that property rests (). Combined with the three-role separation (Issuer, Transparency Service, Relying Party), this provides the structural independence required for evidence to withstand institutional scrutiny.

Scope This document specifies:

• AgentInteractionRecord (AIR) schema as COSE_Sign1 payload
• SCITT role mappings for the agent execution context
• Registration Policy requirements for AIR admission
• Hash chain construction and four-step verification algorithm
• Identity binding levels (Minimum, Institutional, Delegation)
• Redaction receipt mechanism for privacy-preserving custody
• Evidence Receipt semantics
• Compliance mappings to applicable regulatory frameworks

This document does not specify:

• General SCITT architecture (see )
• COSE Receipt format (see )
• Capture mechanism (MCP middleware, framework wrappers, proxies are all conforming implementations)
• Storage backend technology
• Identity infrastructure (DIDs, SPIFFE , Verifiable Credentials are external systems)
• Analytics or query APIs
• Specific regulatory requirements applicable to any deployment
• Content evaluation, risk scoring, or analytical interpretation of recorded actions

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

Agent:

An autonomous software system that perceives inputs, makes decisions, and takes actions on behalf of a principal, using one or more AI models.

Agent Operator:

The organisation that deploys, configures, and directs an Agent. Responsible for the Agent's actions in law and contract. The Issuer in this profile.

Material Action:

An action taken by an Agent that creates, modifies, or extinguishes an external obligation, transfers value, accesses regulated data, or produces a consequential output. See .

AgentInteractionRecord (AIR):

A structured, signed, hash-chained record of a single Material Action. The signed statement payload for this profile.

Evidence (in this profile):

Information derived from a signed, hash-chained AgentInteractionRecord that attests to the integrity, provenance, and temporal ordering of a Material Action. Evidence attests to what was recorded and that the record has not been altered; it does not attest to the correctness, legality, or commercial merit of the recorded action.

Evidence Chain:

The ordered, hash-chained sequence of AIRs registered with a Transparency Service for a given agent deployment.

Evidence Custody:

The independent, append-only holding of integrity proofs and signed records on behalf of a principal, without access to, control over, or liability for the underlying assets, transactions, or decisions those records reference.

Evidence Custodian:

The party performing Evidence Custody by operating the Transparency Service. Independent of the Agent Operator. Holds the append-only Evidence Chain.

Evidence Receipt:

A receipt issued by the Transparency Service upon successful registration of an AIR. See .

Redaction Receipt:

A record within the AIR attesting that a specific field was redacted before signing, preserving the SHA-256 hash of the original value.

Principal:

The human or institutional entity on whose behalf the Agent acts.

EES:

Evidence Envelope Specification. The open format specification defining the AIR schema and verification algorithm. See .

SCITT Role Mapping

Issuer -- the Agent Operator The Agent Operator is the Issuer. The Operator's evidence pipeline captures Material Actions at execution time, normalises them to the AIR schema, applies redaction policy, and signs the record using an ECDSA P-256 key pair. The Issuer's signing key MUST be registered with the Transparency Service before first submission, bound to the Operator's organisational identity, and rotated on a schedule no longer than 12 months. Key rotation events MUST themselves be registered as records in the Evidence Chain.

Transparency Service -- the Evidence Custodian The Evidence Custodian is an independent party -- not the Agent Operator, without financial or operational interest in the Agent's behaviour -- that holds the append-only Evidence Chain under custodial SLAs. The Transparency Service MUST maintain the chain as append-only (records once admitted cannot be deleted, modified, or reordered), issue an Evidence Receipt for each admitted record via , and implement the non-equivocation guarantee.

Relying Party Relying Parties arrive after the fact, with zero prior context, and must be able to verify records without operator cooperation.

Role Mapping Summary

SCITT Role	This Profile
Issuer	Agent Operator
Signed Statement	AgentInteractionRecord
Transparency Service	Evidence Custodian
Receipt	Evidence Receipt ()
Relying Party	Auditor / Regulator / Insurer / Counterparty

The Material Action

Definition A Material Action is the unit of record in this profile. Every Material Action MUST produce exactly one AgentInteractionRecord. An action is material if it satisfies one or more of:

(a) Value transfer

initiates, authorises, or confirms a transfer of monetary value or financial instruments.

(b) Contract formation or modification

creates, amends, or terminates a legal obligation between parties.

(c) Regulated data access

accesses, modifies, or transmits data subject to regulatory protection.

(d) Consequential decision

produces a decision that materially affects the rights or interests of a person.

(e) External system commitment

commits state to an external system that cannot be trivially undone.

This list is not exhaustive. Implementations SHOULD treat any autonomous action with externally observable consequences as material.

Action Type Classification This profile defines the following action types:

Action Type	Material Action Category
payment_initiation	Value transfer
payment_execution	Value transfer
trade_execution	Value transfer
contract_execution	Contract formation or modification
regulated_data_access	Regulated data access
regulated_data_export	Regulated data access
credit_decision	Consequential decision
configuration_change	External system commitment

Implementations MAY define additional values using a reverse-DNS namespace (e.g., com.example.custom-action). Values without a namespace prefix are reserved for this profile.

AgentInteractionRecord

Overview The AIR captures eight categories of evidence about a Material Action: what the agent was given; what it produced; what resources it used; what it reasoned; who it is; what authorised it; when it acted; and where it fits in a causal chain.

Schema (CDDL) The following CDDL reproduces the AgentInteractionRecord schema from the Evidence Envelope Specification [EES] for implementer convenience. int, ; -7 for ES256 &(kid: 4) => bstr, ; operator_pubkey_id &(CWT_Claims: 15) => CWT_Claims_Map, ; --- Profile-specific integrity fields --- "content_hash" : bstr, "prev_chain_hash" : bstr, "chain_hash" : bstr, "sequence_number" : uint, "action_timestamp_ms": uint, "agent_id" : tstr, } CWT_Claims_Map = { &(iss: 1) => tstr, ; operator_id &(sub: 2) => tstr, ; agent_id } ]]>

Field Definitions Core Identity Fields:

schema_version REQUIRED:

MUST be "air-1.0". Identifies the AIR schema version for forward compatibility.

record_id REQUIRED:

UUID v7 (), time-ordered. Unique identifier for this record. Enables deduplication on resubmission.

session_id REQUIRED:

UUID grouping related Material Actions within a single workflow or conversation.

agent_id REQUIRED:

Stable deployment identifier for the agent. Assigned by the Agent Operator. Does not change across restarts or model updates. Forms the primary grouping key for the Evidence Chain.

agent_version REQUIRED:

String encoding the model name, model version, agent framework, and framework version. Format is implementation-defined but MUST be deterministic for a given execution environment.

agent_did OPTIONAL:

W3C Decentralized Identifier providing a portable, cryptographically verifiable identity anchor that survives across sessions and operators.

agent_workload_id OPTIONAL:

SPIFFE ID () identifying the specific runtime workload instance. More specific than agent_id; different instances of the same deployment will have different workload IDs.

operator_id REQUIRED:

Identifier for the Agent Operator. Corresponds to the Issuer identity (CWT Claims iss) in the COSE protected header.

operator_pubkey_id REQUIRED:

Key identifier for the signing key used. Corresponds to kid in the COSE protected header.

principal_id OPTIONAL:

Identifier for the human or institutional entity on whose behalf the Agent acts.

Authorisation Fields:

delegation_chain OPTIONAL:

Ordered array of references to Verifiable Credentials establishing the authority chain from Principal to Agent.

intent_attestation OPTIONAL:

Reference to a signed attestation of the principal's intent.

auth_context OPTIONAL:

OAuth/authorisation context at execution time. Contains token_type, scopes, audience, and expires_at_ms. Records which scopes the Agent was operating under at the moment of the Material Action.

Timestamp Fields:

action_timestamp_ms REQUIRED:

Unix epoch in milliseconds. The moment the Material Action completed. Distinct from captured_timestamp_ms and written_timestamp_ms. Also carried in the COSE protected header for chain verification without payload access.

captured_timestamp_ms REQUIRED:

Unix epoch in milliseconds. When the capture pipeline recorded the action.

written_timestamp_ms OPTIONAL:

Unix epoch in milliseconds. When the Transparency Service admitted the record. Null until admission.

Action Classification Fields:

action_type REQUIRED:

Classification of the Material Action. Values defined by this profile are listed in . Implementations MAY define additional values using a reverse-DNS namespace.

action_subtype OPTIONAL:

Refinement of the action type. Implementation-defined.

Input and Outcome Fields:

input_hash REQUIRED:

SHA-256 hash of the raw input to the agent. Preserves evidence of input without storing the input itself.

input_summary OPTIONAL:

Human-readable summary of the input, post-redaction.

outcome_state REQUIRED:

Terminal state of the Material Action. MUST be one of: completed, failed, partially_completed, reversed, pending_confirmation.

outcome_hash REQUIRED:

SHA-256 hash of the raw output.

outcome_summary OPTIONAL:

Human-readable summary of the outcome, post-redaction.

tool_calls REQUIRED:

Array of ToolCallRecord objects. Each records a single tool or API invocation: tool_id, tool_type, input_hash, output_hash, is_write, timestamp_ms. MAY be empty if no tools were invoked.

Reasoning Fields:

reasoning_hash OPTIONAL:

SHA-256 hash of the reasoning trace. Preserves evidence of reasoning without requiring the raw trace in the AIR.

Regulatory and Policy Fields:

jurisdiction REQUIRED:

ISO 3166-1 alpha-2 country code identifying the applicable jurisdiction.

retention_class REQUIRED:

Retention period label: regulatory_7yr, regulatory_5yr, regulatory_3yr, operational_1yr, custom. These are informational classification labels.

policy_refs REQUIRED:

Array of references to policies governing this action. MAY be empty.

consumer_instructions OPTIONAL:

Principal-defined constraints for agentic commerce: price thresholds, merchant restrictions, product scope, recurrence limits.

Provenance and Correlation Fields:

external_refs REQUIRED:

Array of ExternalRef objects cross-referencing external systems (trade IDs, payment references). MAY be empty.

parent_record_id OPTIONAL:

UUID of the parent AIR in a multi-step workflow. Enables causal chain reconstruction.

workflow_id OPTIONAL:

Identifier for the broader workflow this action belongs to.

trace_id OPTIONAL:

OpenTelemetry trace ID for observability correlation.

Privacy Fields:

redaction_receipts REQUIRED:

Array of RedactionReceipt objects attesting to redacted fields. MAY be empty.

Identity Binding Levels Level 1 -- Minimum: agent_id and operator_id present. Signing key pre-registered and signature verifies. Level 2 -- Institutional: Level 1 plus auth_context present with valid scopes and non-expired token claims. Level 3 -- Delegation: Level 2 plus at least one resolvable Verifiable Credential in delegation_chain.

Integrity Envelope Every AIR is accompanied by integrity fields carried in the COSE protected header (see ): content_hash (SHA-256 of the payload), prev_chain_hash (preceding record's chain hash), chain_hash, sequence_number (monotonically increasing, 0-based), action_timestamp_ms, and agent_id. The protected header also carries the SCITT-mandated CWT Claims (iss and sub) and key identification (kid) as specified in . The COSE_Sign1 signature covers the protected header and payload per and is the fourth element of the COSE_Sign1 array, not a field within the protected header. These fields are structurally separate from the payload, enabling full chain verification -- including identity and temporal ordering -- without payload access, and supporting payload redaction without breaking the chain. The chain_hash construction uses four inputs: SHA-256(content_hash || prev_chain_hash || action_timestamp_ms || agent_id). This binds identity and temporal ordering into the chain at the cryptographic level: the chain_hash commits to who, when, and what without requiring payload access. Both agent_id and action_timestamp_ms are mandatory fields supplied by the upstream agent platform at capture time; the Registration Policy () MUST reject submissions missing either field.

COSE Encoding AIRs are encoded as COSE_Sign1 structures with algorithm ES256 (ECDSA with SHA-256 over P-256). The payload is the canonical JSON serialisation of the AIR (), encoded as a CBOR byte string. The COSE protected header includes both SCITT-mandated parameters and profile-specific integrity fields. Per and , the protected header MUST include CWT Claims (COSE label 15) containing the Issuer claim (iss, claim label 1, as defined in ) set to the operator_id, and the Subject claim (sub, claim label 2) set to the agent_id. The protected header MUST also include key identification via kid (COSE label 4) set to the operator_pubkey_id. Implementations MAY use x5t or x5chain () as alternatives to kid when X.509 certificates are used. In addition, the protected header carries the profile-specific integrity fields: content_hash, prev_chain_hash, chain_hash, sequence_number, action_timestamp_ms, and agent_id. The agent_id value in the protected header is identical to the CWT Claims sub value; the protected header copy enables chain verification without CWT Claims parsing. The payload contains only the remaining AIR content fields. This separation allows the Transparency Service to validate chain integrity from the protected header without parsing the payload, and supports Selective Disclosure and payload redaction without breaking the chain. The profile-specific integrity fields use string labels in this revision for readability. A subsequent revision will propose integer label registration via IANA for these fields.

Hash Chain Construction For sequence_number = 0: prev_chain_hash = 32 zero bytes. For all subsequent records: prev_chain_hash = chain_hash of preceding record. For every record: COSE_Sign1.payload is the raw byte string from the COSE structure's payload field -- the CBOR-encoded canonical JSON serialisation (RFC 8785) of the AIR content fields. The concatenation inputs are encoded as follows:

content_hash (32 bytes)

Raw SHA-256 digest bytes.

prev_chain_hash (32 bytes)

Raw SHA-256 digest bytes. For the first record in a chain (sequence_number = 0), 32 zero bytes (0x00 * 32).

action_timestamp_ms (8 bytes)

Unsigned 64-bit integer in big-endian (network) byte order.

agent_id (4 + N bytes)

Length-prefixed UTF-8 string: a 4-byte big-endian unsigned 32-bit integer containing the byte length of the UTF-8 encoding, followed by the UTF-8 encoded bytes. No null terminator.

The total input to SHA-256 is exactly 76 + len(agent_id) bytes. This encoding is deterministic: two conforming implementations given the same field values MUST produce the same chain_hash. The Transparency Service MUST verify hash chain continuity before admitting each record. Concurrency and Serialisation: The hash chain construction requires sequential production of records within a single Evidence Chain. Because each record's chain_hash depends on the preceding record's chain_hash via prev_chain_hash, a conforming implementation cannot produce record N+1 until record N has been finalised and signed. This dependency provides a cryptographically enforced total ordering guarantee rather than an administratively asserted one. Evidence Chains are scoped per agent_id. Agents with distinct agent_id values operate independent chains with no cross-chain ordering dependency. Concurrent agent deployments do not contend with each other. Within a single agent_id, implementations MUST serialise record production. Two conforming patterns exist: (a) the Issuer's capture pipeline maintains a per-agent_id serialisation point (queue or mutex) and produces fully signed, sequenced records before submission to the Transparency Service; or (b) the Transparency Service assigns sequence numbers at admission time and returns chain_hash to the Issuer for use in the next record. Pattern (a) requires Issuer-side state but minimises round trips. Pattern (b) centralises ordering but introduces a synchronous dependency on the Transparency Service for each record. If an agent produces multiple Material Actions concurrently, the capture pipeline queues them and serialises into the chain in arrival order. Records MAY share the same action_timestamp_ms; the sequence_number provides the authoritative total ordering.

Verification Algorithm Four-step algorithm. Requires only the record, preceding chain_hash (or Evidence Receipt), and the Issuer's public key.

1. Payload integrity. Compute SHA-256 of the COSE payload directly. Compare to content_hash in the COSE protected header. Mismatch = FAIL.
2. Chain integrity. From the COSE protected header, extract content_hash, prev_chain_hash, action_timestamp_ms, and agent_id. Compute SHA-256(content_hash || prev_chain_hash || action_timestamp_ms || agent_id) using the byte encoding defined in . Compare to chain_hash. Mismatch = FAIL.
3. Signature validity. Verify the COSE_Sign1 signature per using the operator's public key. Invalid = FAIL.
4. Sequence completeness. Verify sequence_number is exactly one greater than the preceding record (or zero). Gap = FAIL.

If all four steps pass: the record is VERIFIED -- intact, untampered, correctly positioned, and signed by the claimed Issuer.

Algorithm Agility This profile mandates ES256 (ECDSA with SHA-256 over P-256) as the mandatory-to-implement algorithm. Implementations SHOULD design for algorithm transition. The schema_version field in the AIR payload and the alg parameter in the COSE protected header together provide the mechanism for introducing new algorithms in future revisions without breaking existing chains. A chain MAY contain a key rotation record (action_type: key_rotation) that transitions to a new algorithm. Records before and after the transition point are verified with their respective algorithms as indicated by the alg parameter in each record's COSE protected header. Transparency Services MUST retain the prior public key and algorithm identifier to enable verification of pre-transition records. A future revision of this profile will specify post-quantum transition mechanisms, including ML-DSA (FIPS 204) as a candidate additional algorithm for Evidence Receipt signatures.

Registration Policy A Transparency Service operating this profile MUST enforce the following policy. Records failing any requirement MUST be rejected. The Registration Policy and associated trust anchors MUST be registered as Signed Statements on the Transparency Service's verifiable data structure, per . 6.1. Schema Conformance: Valid COSE_Sign1 with ES256; protected header MUST include CWT Claims (label 15) with iss and sub per Section 6 of and , and key identification via kid, x5t, or x5chain; valid AIR per CDDL; schema_version "air-1.0"; all REQUIRED fields non-null; valid action_type. 6.2. Identity Binding: Minimum Level 1. Services MAY require Level 2 or 3 for specific categories. 6.3. Temporal Ordering: action_timestamp_ms <= captured_timestamp_ms; captured within 300s of submission; prev_chain_hash matches; sequence_number correct. 6.4. Redaction Receipt Requirement: For regulated_data_access, regulated_data_export, payment_initiation, payment_execution, and credit_decision, at least one RedactionReceipt MUST be present. 6.5. Error Semantics: A Transparency Service rejecting a submission MUST return an error response per . The response SHOULD carry a detail string identifying which of the above requirements (6.1 through 6.4) the submission failed to satisfy.

Evidence Receipt Upon successful admission, the Transparency Service issues an Evidence Receipt (COSE_Sign1 signed by the Service's own key) containing: record_id, chain_hash, sequence_number, admission_timestamp_ms, and Service operator identifier. The admission_timestamp_ms is assigned by the Transparency Service. The AIR existed no later than that time. The timestamps inside the AIR are asserted by the Issuer. The Evidence Receipt is the primary artefact presented in verification, audit, or legal proceedings. 7.1. Verifiable Data Structure: This profile uses the hash chain defined in as its verifiable data structure. This revision does not define an inclusion proof in the sense of . Instead, the Evidence Receipt attests the chain_hash, which binds the record to a position in the Evidence Chain. Evidence Receipts are intended to align with the COSE Receipts structure defined in , with the verifiable data structure identifier carried in the protected header (COSE label 395) and the inclusion proof in the unprotected header (COSE label 396). The choice of registered verifiable data structure, and the resulting proof encoding, is deferred to a subsequent revision of this profile. Until then, the Evidence Receipt described in this section remains the receipt for this profile. Implementers are advised to retain the information needed to re-issue receipts in the RFC 9942 form once the structure is specified. 7.2. Transparent Statement: Per , a Transparent Statement is a Signed Statement with one or more Receipts embedded in the unprotected header (COSE label 394). defines the value of that header parameter as an array of COSE Receipts. The Evidence Receipt described in this section is not yet in that form, and is therefore stored and presented as a standalone artefact, independent of the AIR. Once a subsequent revision specifies the Evidence Receipt as a COSE Receipt, it can be attached to the AIR to form a Transparent Statement.

Compliance Mapping The mappings in this section are informational and illustrative. They describe how properties of this profile may be relevant to specific regulatory frameworks. They do not constitute legal advice, regulatory interpretation, or a claim of compliance with any regulation. The frameworks listed below are representative examples; they do not form an exhaustive list of potentially applicable regulations.

EU AI Act Articles 12 and 19 AIRs provide properties relevant to Article 12 (record-keeping: automatic recording of events over the lifetime of a high-risk AI system) and to the retention of automatically generated logs by providers (Article 19) and by deployers (Article 26(6)). Annex III, point 5, classifies credit scoring and life/health insurance pricing AI as high-risk.

DORA (Regulation (EU) 2022/2554) DORA sets requirements for ICT risk management, ICT-related incident reporting, and ICT third-party risk for financial entities. Article 30(3)(e) requires contracts for ICT services supporting critical or important functions to provide rights of access, inspection, and audit. Commission Delegated Regulation (EU) 2024/1774 , which supplements DORA, requires in its Article 12 (Logging) that the logging procedures, protocols, and tools of financial entities include measures to protect logging systems and log information against tampering, deletion, and unauthorised access. AIRs provide records relevant to reconstructing ICT-related incidents.

NIST AI Risk Management Framework The framework organises outcomes under four functions: Govern, Map, Measure, and Manage. Issuer/Custodian separation and identity binding are relevant to accountability under Govern. Evidence Chains provide a tamper-evident record of the behaviour of a deployed system, relevant to Measure. Evidence Receipts support incident reconstruction, relevant to Manage.

US Financial Record-Keeping FINRA Rule 4511 requires member firms to make and preserve books and records; SEC Rule 17a-4 prescribes retention periods (6yr/3yr) and electronic storage requirements. AIRs with action_type "trade_execution" provide independent execution records. The retention_class label "regulatory_7yr" covers both periods.

MAS AI Risk Management Guidelines (Singapore) MAS consulted on Guidelines on Artificial Intelligence Risk Management in November 2025 ; the consultation paper explicitly covers AI agents. MAS issued the final Guidelines in October 2026. In its response to the consultation , MAS states that clear records should also be kept of post-deployment activities such as actions, decisions, recommendations, and outputs made by, or with the assistance of, AI, and that monitoring of agentic AI should extend, where relevant, to actions taken and tools used. AIRs are records of this kind.

PCI DSS Requirement 10 of PCI DSS v4.0.1 covers logging and monitoring of all access to system components and cardholder data. The PCI SSC AI Principles (September 2025), which are guidance, discuss agentic AI systems that make payments on behalf of cardholders. A PCI SSC information supplement of September 2026 , which is guidance, recommends logging AI systems in enough detail to support investigation, attribution, and reconstruction of AI-assisted actions without storing account data, and says that logs of actions an AI system takes autonomously should not be removable. The supplement does not address the use of AI to perform payments.

MiFID II MiFID II Article 16(6), record-keeping; Regulation (EU) No 600/2014 (MiFIR) Article 25(1), five-year retention of order and transaction data; Delegated Regulation (EU) 2017/565 Article 72, records retained in a form that cannot be manipulated or altered.

Relationship to the Evidence Envelope Specification The Evidence Envelope Specification (EES) is an open format specification for independently custodied AI agent execution records, defining the AIR schema, verification algorithm, and capture interface contract. This SCITT profile and the EES complement each other. The EES defines the canonical schema (JSON Schema), verification algorithm (pseudocode + reference implementation), and writer interface contract (IDL). This profile defines the SCITT binding: COSE encoding, Transparency Service submission, and the Evidence Receipt. The AgentInteractionRecord schema reproduced in is a conformant subset of the EES schema. The canonical definition, including the full field set and extensibility model, is maintained in the EES. Implementations of this profile do not require the EES; the AIR schema in is self-contained. The EES provides additional guidance for implementers building capture interfaces. The schema in is taken from EES v0.1 .

Related Work Several individual Internet-Drafts profile for AI agent actions or define adjacent record formats. This section positions the AgentInteractionRecord relative to each. All are individual submissions at the time of writing, and the comparisons below describe the published revisions cited. The documents differ along three axes: the lifecycle stage they record, the unit of record, and the custody model they assume.

Lifecycle Stage Pre-execution profiles record an authorisation decision before the action is dispatched. defines a Permit that binds an allow, deny, or challenge decision to the canonical bytes of the request subsequently dispatched, and applies it to WIMSE-authorised agent actions. binds an agent's authorised scope to a signed policy at session start and produces a receipt at each capability invocation. binds per-action authorisation and memory-provenance records into the Agent Action Capsule described in . This profile records what was executed. It is complementary to pre-execution profiles: an AIR can carry a reference to a Permit or equivalent authorisation record in external_refs, so that a Relying Party can pair the authorisation record with the execution record for the same Material Action. recommends that an Issuer emitting both records carry the Permit's identifier in parent_record_id and a reference to a paired Closure Record in external_refs. defines parent_record_id as the identifier of a parent AIR, and external_refs as the field for references into other systems. This revision changes neither field. This profile does not define the authorisation record itself.

Unit of Record defines the Agent Action Capsule, a digest-committed record of one agent action carrying a verdict-level disposition (executed, blocked, denied, errored, timed out), the constraints evaluated, and a confirmed-effect binding. defines an AI-agent action receipt as a signed, JCS-canonical JSON object, hash-chained for ordering, which can be carried in a COSE_Sign1 to form a Signed Statement. defines a Governance Audit Record, and records AI content refusal events. The unit of record in this profile is the Material Action (): an action that transfers value, forms or modifies a contract, accesses regulated data, produces a consequential decision, or commits state to an external system. The AIR field set is designed for institutional Relying Parties who arrive after the fact: it carries jurisdiction, retention class, policy references, delegation chain, authorisation context at execution time, and redaction receipts that preserve a hash of each redacted field. The Capsule's disposition vocabulary includes blocked and denied actions; this profile's outcome_state has no corresponding values. The Capsule's constraint evaluation and confirmed-effect binding have no direct equivalent here. The two are distinct statement profiles. A deployment can record both a Capsule and an AIR for the same action and correlate them by trace_id or external_refs.

Custody Model This profile is narrower on purpose than a general SCITT statement profile. It defines the Transparency Service as an Evidence Custodian independent of the Agent Operator (). It treats that independence as a trust assumption: states that if the same entity operates both roles, the tamper-evidence guarantees are void.

Formats Verifiable Without a Transparency Service Several documents define record formats that are verifiable without a Transparency Service. specifies individually signed JSON action receipts linked into an append-only hash chain and verifiable offline from the records and the signer's public key. specifies PALA-1, a compact binary, hash-chained audit record format for constrained and disconnected deployments. Both describe registration of a chain head with a Transparency Service as optional. defines a permission signed by a person, a receipt signed by the agent for each action, and a signed log head, all checked offline. defines a signed receipt for a completed transfer of authority between two agents. This profile addresses cases where registration with an independent Evidence Custodian is required. It does not define a binding from those formats to an Evidence Custodian.

Domain Profiles profiles SCITT for algorithmic trading audit trails and for EU AI Act Article 50 transparency receipts. Both are domain-specific and can coexist with this profile: a trade_execution AIR and a VCP event describing the same trade are distinct Signed Statements that a Relying Party correlates through external_refs.

Audit Architecture describes an architecture for auditing agent delegation and interactions. It sets out Interaction, Action, Delegation, and Authorization Transition records and an Auditing Service that is logically distinct from the parties it records, and it follows the SCITT architecture so that the existence of a record cannot later be denied. This revision does not define a mapping of the AIR or of the Evidence Custodian role to that architecture.

Security Considerations This section describes the threat model, trust assumptions, and required security controls for implementations of this profile. It supplements the security considerations in the SCITT architecture .

Threat Model This profile addresses the following threats: (a) Evidence fabrication, (b) Evidence suppression, (c) Evidence modification, (d) Timing manipulation. This profile does not address threats arising from compromise of the AI agent model itself (prompt injection, goal misalignment, adversarial inputs). It does not address an Issuer that records an action inaccurately or not at all ().

Trust Assumptions (a) The Transparency Service (Evidence Custodian) is structurally independent of the Issuer (Agent Operator). If the same entity operates both roles, the tamper-evidence guarantees are void. (b) The Transparency Service is operationally honest. (c) The Issuer's signing key is not compromised at the time of signing.

Signing Key Management Implementations MUST store signing keys in hardware security modules (HSMs) or equivalent tamper-resistant environments. Keys MUST be rotated at least annually.

Replay Attack Prevention The combination of sequence_number, prev_chain_hash, and captured_timestamp_ms prevents replay attacks.

Capture Pipeline Compromise If the capture pipeline is compromised, an attacker can fabricate or suppress AIRs before they are signed. This threat is mitigated by the Issuer's signing key being held in an HSM separate from the capture pipeline, and by the Transparency Service's Registration Policy validating temporal ordering and sequence completeness. A gap in sequence_number is evidence that a record was produced and not registered. An action that was never recorded leaves no gap.

Custodian Compromise If the Transparency Service itself is compromised, the attacker cannot forge Issuer signatures on existing AIRs or retroactively alter hash chain values without detection by any Relying Party holding a prior Evidence Receipt.

Append-Only Integrity Append-only integrity is enforced by both the hash chain structure and the Transparency Service operational policy. Neither alone is sufficient. Storage backends MUST implement write-once-read-many (WORM) semantics or equivalent immutability guarantees.

Collusion If the Issuer and the Transparency Service collude, they can jointly fabricate, suppress, or modify evidence without detection by Relying Parties who rely solely on receipts from the compromised Transparency Service. This is the fundamental limitation of any two-party evidence system.

Privacy Considerations Access to Evidence Chains MUST be permissioned and purpose-limited. Checking chain integrity and sequence (steps 2 and 4 of ) does not require access to record content. Payload integrity and signature validation (steps 1 and 3) do. Transparency Services SHOULD expose verification endpoints that do not expose payloads. The redaction receipt requirement in is intended to keep raw PII out of signed records for action types involving regulated data or payment information. The content_hash covers the redacted form; the original_hash in the Redaction Receipt allows authorised parties to verify specific field values without the Transparency Service holding the raw data. Even without payload access, the COSE protected header exposes agent_id, action_timestamp_ms, and sequence_number. An observer with access to chain metadata can infer activity frequency, timing patterns, and action volume for a given agent deployment. Transparency Services SHOULD apply access controls to chain metadata with the same rigour as payload content. This profile does not define data subject access or erasure mechanisms. These are operational responsibilities of the Transparency Service operator and are outside the scope of this specification.

IANA Considerations This document has no IANA actions. If this profile progresses beyond Informational status, the authors will propose an IANA registry for action_type values. A subsequent revision is expected to request integer labels for the profile-specific protected header parameters listed in , and any registration needed in the "COSE Verifiable Data Structure Algorithms" and "COSE Verifiable Data Structure Proofs" registries established by .

References Normative References Informative References FINRA SEC European Parliament and Council European Commission Monetary Authority of Singapore P017-2025 Monetary Authority of Singapore PCI SSC PCI SSC Version 1.0 European Parliament and Council Veridic Inc. SPIFFE Project Systemics, Inc.

Changes from -00 This is a maintenance revision. It updates references, positions the profile against related drafts, narrows several statements to what the mechanisms deliver, and records deferred items. It makes no change to the AIR schema, the hash chain construction, the verification algorithm, or the admission requirements of the Registration Policy. No field of the AIR schema is renamed, retyped, or removed, and no normative requirement is added. Three recommendations are withdrawn, as listed below.

• Normative references updated: draft-ietf-scitt-architecture-22 replaced by RFC 9943; draft-ietf-cose-merkle-tree-proofs-18 replaced by RFC 9942; draft-ietf-scitt-scrapi pinned to -11, which is in the RFC Editor queue.
• Pointers into RFC 9943 checked against the published text. The CWT Claims requirement is now cited to Section 6 of RFC 9943, and the requirement that Registration Policies be made transparent to Section 5.1.1.1 of RFC 9943. The Scope list cites RFC 9942 for the COSE Receipt format.
• The Verifiable Data Structure paragraph of now references the RFC 9942 COSE Receipts structure (labels 395 and 396). The statement in -00 that a subsequent revision will register the hash chain as a verifiable data structure is replaced by a statement that the choice of registered structure is deferred. The statement that the hash chain provides the same structural guarantee as a Merkle tree inclusion proof is removed, and the statement that the chain_hash serves as the inclusion proof is replaced by a statement that this revision does not define an inclusion proof in the sense of RFC 9942. The paragraph also advises implementers to retain the information needed to re-issue receipts in the RFC 9942 form.
• The recommendation to attach the Evidence Receipt to the AIR under COSE header parameter 394 is withdrawn until the Evidence Receipt is specified as a COSE Receipt (RFC 9942). Until then, the Evidence Receipt is presented as a standalone artefact, which -00 permitted as an alternative. states the same gap, and the definition in and the summary in no longer describe the Evidence Receipt as a SCITT Receipt. Table 1 now points to for the Evidence Receipt.
• The error type URN recommended in the error semantics of is withdrawn. It does not appear in draft-ietf-scitt-scrapi-11.
• The recommendation in to reference EES v0.1 is withdrawn and replaced by a statement that the schema in this document is taken from it. That section already states that implementations do not require the EES. Its pointer to the VCP profile is removed; that profile is covered in .
• corrected: the EU AI Act and DORA descriptions and article pointers, the status of the MAS Guidelines, the PCI DSS version and date, and the MiFID II and MiFIR pointers. NIST AI RMF subcategory numbers are removed and the mapping is restated at the level of the framework's functions. The retention_class sentence in the US record-keeping mapping is restated as a description. A statement about demand for custody is removed from the EU AI Act mapping, the MAS mapping now cites the MAS response to its consultation, the DORA mapping now cites the logging provision of Commission Delegated Regulation (EU) 2024/1774, and the PCI DSS mapping is restated in the terms of Requirement 10 and of the PCI SSC guidance and now cites the PCI SSC information supplement on AI systems of September 2026.
• Statements narrowed to what the mechanisms deliver. states that this revision does not yet define the proofs on which non-equivocation rests. says that the chain_hash, not a receipt, commits to who, when, and what. says that a sequence gap shows a record that was produced and not registered, and that an action never recorded leaves no gap. says that the chain checks, not the full algorithm, work without record content, and describes the redaction receipt requirement as intended to keep raw PII out of signed records. also says that an Issuer that records an action inaccurately or not at all is outside the threats addressed, and says that the admission timestamp is assigned by the Transparency Service and that the timestamps inside the AIR are asserted by the Issuer.
• New positioning the AgentInteractionRecord against the Agent Action Capsule, Permit, WIMSE authorisation evidence, AgentROA, capsule provenance binding, AI-agent action receipt, GAR, refusal event, VCP, and Article 50 profiles, against four record formats that are verifiable without a Transparency Service, and against the audit architecture of draft-kuehlewind-audit-architecture. The section is informative. Later sections are renumbered.
• The second sentence of is restated as what a Relying Party needs to be able to establish without relying on the agent operator, in place of the properties listed in -00, among them completeness. The section now cites the triple-entry accounting model (Grigg 2005), on which the requirement for third-party-held signed records draws, states that an action without a signed record is outside what can be externally verified, and states that this profile does not establish that a record is accurate.
• expanded to list the registrations a subsequent revision is expected to request.
• The VCP reference is updated to its current revision.
• Editorial corrections, including reference titles and the capitalisation of the organisation name, and wording changes that do not alter meaning. The note naming a discussion list is removed.
• Daniel Feichtinger joins as an author.

The record encoding, the mechanism for selective disclosure of record fields, the representation of lineage between records, and the verifiable data structure used for Evidence Receipts are under revision. A subsequent revision may change them. This revision changes none of them. Deferred to a subsequent revision:

• Registered verifiable data structure and COSE Receipts proof encoding for Evidence Receipts ().
• Integer label registration for the profile-specific protected header parameters ().
• Post-quantum transition, including ML-DSA as a candidate additional algorithm ().
• Key compromise recovery semantics distinguishing compromise from retirement ().
• Worked examples in CBOR Extended Diagnostic Notation.