AI Agent Execution Profile of SCITT
draft-emirdag-scitt-ai-agent-execution-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Pinar Emirdag , Daniel Feichtinger | ||
| Last updated | 2026-10-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-emirdag-scitt-ai-agent-execution-01
Network Working Group P. Emirdag
Internet-Draft D. Feichtinger
Intended status: Informational Veridic Inc.
Expires: 15 April 2027 12 October 2026
AI Agent Execution Profile of SCITT
draft-emirdag-scitt-ai-agent-execution-01
Abstract
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.
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 15 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Emirdag & Feichtinger Expires 15 April 2027 [Page 1]
Internet-Draft SCITT AI Agent Execution October 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Post-Execution Evidence Problem . . . . . . . . . . . 3
1.2. Relationship to SCITT . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SCITT Role Mapping . . . . . . . . . . . . . . . . . . . . . 6
3.1. Issuer -- the Agent Operator . . . . . . . . . . . . . . 6
3.2. Transparency Service -- the Evidence Custodian . . . . . 7
3.3. Relying Party . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Role Mapping Summary . . . . . . . . . . . . . . . . . . 7
4. The Material Action . . . . . . . . . . . . . . . . . . . . . 7
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Action Type Classification . . . . . . . . . . . . . . . 8
5. AgentInteractionRecord . . . . . . . . . . . . . . . . . . . 9
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Schema (CDDL) . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Field Definitions . . . . . . . . . . . . . . . . . . . . 11
5.4. Identity Binding Levels . . . . . . . . . . . . . . . . . 14
5.5. Integrity Envelope . . . . . . . . . . . . . . . . . . . 15
5.6. COSE Encoding . . . . . . . . . . . . . . . . . . . . . . 15
5.7. Hash Chain Construction . . . . . . . . . . . . . . . . . 16
5.8. Verification Algorithm . . . . . . . . . . . . . . . . . 17
5.9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . 18
6. Registration Policy . . . . . . . . . . . . . . . . . . . . . 18
7. Evidence Receipt . . . . . . . . . . . . . . . . . . . . . . 19
8. Compliance Mapping . . . . . . . . . . . . . . . . . . . . . 20
8.1. EU AI Act Articles 12 and 19 . . . . . . . . . . . . . . 20
8.2. DORA (Regulation (EU) 2022/2554) . . . . . . . . . . . . 20
8.3. NIST AI Risk Management Framework . . . . . . . . . . . . 20
8.4. US Financial Record-Keeping . . . . . . . . . . . . . . . 20
8.5. MAS AI Risk Management Guidelines (Singapore) . . . . . . 21
8.6. PCI DSS . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.7. MiFID II . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Relationship to the Evidence Envelope Specification . . . . . 21
10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Lifecycle Stage . . . . . . . . . . . . . . . . . . . . 22
10.2. Unit of Record . . . . . . . . . . . . . . . . . . . . . 23
Emirdag & Feichtinger Expires 15 April 2027 [Page 2]
Internet-Draft SCITT AI Agent Execution October 2026
10.3. Custody Model . . . . . . . . . . . . . . . . . . . . . 23
10.4. Formats Verifiable Without a Transparency Service . . . 24
10.5. Domain Profiles . . . . . . . . . . . . . . . . . . . . 24
10.6. Audit Architecture . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 25
11.2. Trust Assumptions . . . . . . . . . . . . . . . . . . . 25
11.3. Signing Key Management . . . . . . . . . . . . . . . . . 25
11.4. Replay Attack Prevention . . . . . . . . . . . . . . . . 25
11.5. Capture Pipeline Compromise . . . . . . . . . . . . . . 25
11.6. Custodian Compromise . . . . . . . . . . . . . . . . . . 25
11.7. Append-Only Integrity . . . . . . . . . . . . . . . . . 26
11.8. Collusion . . . . . . . . . . . . . . . . . . . . . . . 26
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative References . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Changes from -00 . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
1.1. 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 3]
Internet-Draft SCITT AI Agent Execution October 2026
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 [GRIGG-2005], 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.
1.2. Relationship to SCITT
This profile is an application of [RFC9943]. It:
* REQUIRES compliance with [RFC9943]
* REQUIRES AIRs to be encoded as COSE_Sign1 Signed Statements
[RFC9052]
* DEFINES domain-specific extensions for AI agent execution evidence
The first item above has one exception in this revision. Section 5.1
of [RFC9943] requires a Transparency Service to produce COSE Receipts
as defined in [RFC9942]. The Evidence Receipt in Section 7 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 (Section 7). Combined with the three-role
separation (Issuer, Transparency Service, Relying Party), this
provides the structural independence required for evidence to
withstand institutional scrutiny.
1.3. 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)
Emirdag & Feichtinger Expires 15 April 2027 [Page 4]
Internet-Draft SCITT AI Agent Execution October 2026
* 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 [RFC9943])
* COSE Receipt format (see [RFC9942])
* Capture mechanism (MCP middleware, framework wrappers, proxies are
all conforming implementations)
* Storage backend technology
* Identity infrastructure (DIDs, SPIFFE [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
2. 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 [RFC2119] [RFC8174] 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
Section 4.
Emirdag & Feichtinger Expires 15 April 2027 [Page 5]
Internet-Draft SCITT AI Agent Execution October 2026
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 Section 7.
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
Section 9.
3. SCITT Role Mapping
3.1. 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 6]
Internet-Draft SCITT AI Agent Execution October 2026
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.
3.2. 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
[I-D.ietf-scitt-scrapi], and implement the non-equivocation
guarantee.
3.3. Relying Party
Relying Parties arrive after the fact, with zero prior context, and
must be able to verify records without operator cooperation.
3.4. Role Mapping Summary
+======================+==============================+
| SCITT Role | This Profile |
+======================+==============================+
| Issuer | Agent Operator |
+----------------------+------------------------------+
| Signed Statement | AgentInteractionRecord |
+----------------------+------------------------------+
| Transparency Service | Evidence Custodian |
+----------------------+------------------------------+
| Receipt | Evidence Receipt (Section 7) |
+----------------------+------------------------------+
| Relying Party | Auditor / Regulator / |
| | Insurer / Counterparty |
+----------------------+------------------------------+
Table 1
4. The Material Action
Emirdag & Feichtinger Expires 15 April 2027 [Page 7]
Internet-Draft SCITT AI Agent Execution October 2026
4.1. 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.
4.2. Action Type Classification
This profile defines the following action types:
Emirdag & Feichtinger Expires 15 April 2027 [Page 8]
Internet-Draft SCITT AI Agent Execution October 2026
+=======================+====================================+
| 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 |
+-----------------------+------------------------------------+
Table 2
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.
5. AgentInteractionRecord
5.1. 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.
5.2. Schema (CDDL)
The following CDDL [RFC8610] reproduces the AgentInteractionRecord
schema from the Evidence Envelope Specification [EES] for implementer
convenience.
AgentInteractionRecord = {
"schema_version" : tstr, ; MUST be "air-1.0"
"record_id" : tstr, ; UUID v7
"session_id" : tstr,
"action_type" : tstr,
"action_subtype" : tstr / null,
"action_timestamp_ms" : uint, ; Unix epoch, ms
Emirdag & Feichtinger Expires 15 April 2027 [Page 9]
Internet-Draft SCITT AI Agent Execution October 2026
"captured_timestamp_ms" : uint,
"written_timestamp_ms" : uint / null,
"agent_id" : tstr, ; Stable deployment ID
"agent_version" : tstr,
"agent_did" : tstr / null, ; W3C DID
"agent_workload_id" : tstr / null, ; SPIFFE ID
"operator_id" : tstr,
"operator_pubkey_id" : tstr,
"principal_id" : tstr / null,
"delegation_chain" : [* tstr] / null,
"intent_attestation" : tstr / null,
"auth_context" : AuthContext / null,
"input_hash" : bstr, ; SHA-256
"input_summary" : tstr / null,
"outcome_state" : tstr,
"outcome_hash" : bstr,
"outcome_summary" : tstr / null,
"tool_calls" : [* ToolCallRecord],
"jurisdiction" : tstr, ; ISO 3166-1 alpha-2
"retention_class" : tstr,
"policy_refs" : [* tstr],
"external_refs" : [* ExternalRef],
"parent_record_id" : tstr / null,
"workflow_id" : tstr / null,
"trace_id" : tstr / null,
"consumer_instructions" : tstr / null,
"reasoning_hash" : bstr / null, ; SHA-256
"redaction_receipts" : [* RedactionReceipt],
}
; The COSE protected header carries: content_hash, chain_hash,
; prev_chain_hash, sequence_number, action_timestamp_ms, and
; agent_id. The latter two also appear in the payload; the
; protected header copies enable chain verification without
; payload access. See Section 5.6.
AuthContext = { "token_type" : tstr, "scopes" : [* tstr],
"audience" : tstr / null, "expires_at_ms" : uint / null }
ToolCallRecord = { "tool_id" : tstr, "tool_type" : tstr,
"input_hash" : bstr, "output_hash" : bstr,
"is_write" : bool, "timestamp_ms" : uint }
ExternalRef = { "ref_type" : tstr, "ref_value" : tstr,
"ref_system" : tstr / null }
RedactionReceipt = { "field_path" : tstr,
"original_hash" : bstr, "policy_id" : tstr,
"timestamp_ms" : uint }
Emirdag & Feichtinger Expires 15 April 2027 [Page 10]
Internet-Draft SCITT AI Agent Execution October 2026
; COSE protected header fields (not in payload):
; The COSE_Sign1 signature covers this header and the payload
; per RFC 9052; it is not a field within the header itself.
;
; Per RFC 9943 Section 6 and RFC 9597,
; the protected header MUST include CWT Claims (label 15) with
; iss (Issuer, claim 1) and sub (Subject, claim 2), plus key
; identification via kid (label 4), x5t (label 34), or
; x5chain (label 33).
;
; In this profile:
; iss (claim 1) = operator_id (the Agent Operator identity)
; sub (claim 2) = agent_id (the agent deployment identity)
; kid (label 4) = operator_pubkey_id
CoseProtectedFields = {
; --- SCITT-mandated parameters (integer labels) ---
&(alg: 1) => 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
}
5.3. 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 ([RFC9562]), 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 11]
Internet-Draft SCITT AI Agent Execution October 2026
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 ([SPIFFE]) 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
Emirdag & Feichtinger Expires 15 April 2027 [Page 12]
Internet-Draft SCITT AI Agent Execution October 2026
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 Section 4.2.
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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 13]
Internet-Draft SCITT AI Agent Execution October 2026
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.
5.4. 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 14]
Internet-Draft SCITT AI Agent Execution October 2026
5.5. Integrity Envelope
Every AIR is accompanied by integrity fields carried in the COSE
protected header (see Section 5.6): 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 Section 5.6. The COSE_Sign1 signature covers
the protected header and payload per [RFC9052] 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 (Section 6) MUST reject submissions
missing either field.
5.6. COSE Encoding
AIRs are encoded as COSE_Sign1 structures [RFC9052] with algorithm
ES256 (ECDSA with SHA-256 over P-256). The payload is the canonical
JSON serialisation of the AIR ([RFC8785]), encoded as a CBOR byte
string.
The COSE protected header includes both SCITT-mandated parameters and
profile-specific integrity fields. Per Section 6 of [RFC9943] and
[RFC9597], the protected header MUST include CWT Claims (COSE label
15) containing the Issuer claim (iss, claim label 1, as defined in
[RFC8392]) 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
([RFC9360]) 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
Emirdag & Feichtinger Expires 15 April 2027 [Page 15]
Internet-Draft SCITT AI Agent Execution October 2026
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.
5.7. 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:
content_hash = SHA-256(COSE_Sign1.payload)
chain_hash = SHA-256(content_hash || prev_chain_hash ||
action_timestamp_ms || agent_id)
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:
Emirdag & Feichtinger Expires 15 April 2027 [Page 16]
Internet-Draft SCITT AI Agent Execution October 2026
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.
5.8. 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 Section 5.7. Compare to chain_hash. Mismatch = FAIL.
3. Signature validity. Verify the COSE_Sign1 signature per
[RFC9052] using the operator's public key. Invalid = FAIL.
Emirdag & Feichtinger Expires 15 April 2027 [Page 17]
Internet-Draft SCITT AI Agent Execution October 2026
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.
5.9. 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.
6. 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 Section 5.1.1.1 of [RFC9943].
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 [RFC9943] and [RFC9597], 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 18]
Internet-Draft SCITT AI Agent Execution October 2026
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 [I-D.ietf-scitt-scrapi]. The
response SHOULD carry a detail string identifying which of the above
requirements (6.1 through 6.4) the submission failed to satisfy.
7. 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 Section 5.7 as its verifiable data structure. This
revision does not define an inclusion proof in the sense of
[RFC9942]. 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 [RFC9942], 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 Section 7 of [RFC9943], a
Transparent Statement is a Signed Statement with one or more Receipts
embedded in the unprotected header (COSE label 394). [RFC9942]
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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 19]
Internet-Draft SCITT AI Agent Execution October 2026
8. 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.
8.1. 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.
8.2. DORA (Regulation (EU) 2022/2554)
DORA [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 [DORA-RTS], 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.
8.3. 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.
8.4. US Financial Record-Keeping
FINRA Rule 4511 [FINRA-4511] requires member firms to make and
preserve books and records; SEC Rule 17a-4 [SEC-17a-4] prescribes
retention periods (6yr/3yr) and electronic storage requirements.
Emirdag & Feichtinger Expires 15 April 2027 [Page 20]
Internet-Draft SCITT AI Agent Execution October 2026
AIRs with action_type "trade_execution" provide independent execution
records. The retention_class label "regulatory_7yr" covers both
periods.
8.5. MAS AI Risk Management Guidelines (Singapore)
MAS consulted on Guidelines on Artificial Intelligence Risk
Management in November 2025 [MAS-AI-RM]; the consultation paper
explicitly covers AI agents. MAS issued the final Guidelines in
October 2026. In its response to the consultation [MAS-AI-RM-RESP],
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.
8.6. PCI DSS
Requirement 10 of PCI DSS v4.0.1 [PCI-DSS-4] 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
[PCI-AI-SUPP], 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.
8.7. MiFID II
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.
9. 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 21]
Internet-Draft SCITT AI Agent Execution October 2026
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 Section 5.2 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 Section 5.2 is self-contained. The EES provides
additional guidance for implementers building capture interfaces.
The schema in Section 5.2 is taken from EES v0.1 [EES].
10. Related Work
Several individual Internet-Drafts profile [RFC9943] 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.
10.1. Lifecycle Stage
Pre-execution profiles record an authorisation decision before the
action is dispatched. [I-D.munoz-scitt-permit-profile] defines a
Permit that binds an allow, deny, or challenge decision to the
canonical bytes of the request subsequently dispatched, and
[I-D.munoz-wimse-authorization-evidence] applies it to WIMSE-
authorised agent actions. [I-D.nivalto-agentroa-route-authorization]
binds an agent's authorised scope to a signed policy at session start
and produces a receipt at each capability invocation.
[I-D.rampalli-scitt-capsule-provenance-binding] binds per-action
authorisation and memory-provenance records into the Agent Action
Capsule described in Section 10.2.
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. [I-D.munoz-scitt-permit-profile]
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. Section 5.3 defines parent_record_id as the
Emirdag & Feichtinger Expires 15 April 2027 [Page 22]
Internet-Draft SCITT AI Agent Execution October 2026
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.
10.2. Unit of Record
[I-D.mih-scitt-agent-action-capsule] 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.
[I-D.noa-scitt-ai-agent-receipt] 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.
[I-D.sato-soos-gar] defines a Governance Audit Record, and
[I-D.kamimura-scitt-refusal-events] records AI content refusal
events.
The unit of record in this profile is the Material Action
(Section 4): 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.
10.3. 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 (Section 3.2). It treats
that independence as a trust assumption: Section 11 states that if
the same entity operates both roles, the tamper-evidence guarantees
are void.
Emirdag & Feichtinger Expires 15 April 2027 [Page 23]
Internet-Draft SCITT AI Agent Execution October 2026
10.4. Formats Verifiable Without a Transparency Service
Several documents define record formats that are verifiable without a
Transparency Service. [I-D.sahu-agent-action-receipts] 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. [I-D.sparysh-pala-audit] 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.
[I-D.izmaylov-agent-permission-receipts] defines a permission signed
by a person, a receipt signed by the agent for each action, and a
signed log head, all checked offline.
[I-D.sabey-succession-receipts] 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.
10.5. Domain Profiles
[VCP] profiles SCITT for algorithmic trading audit trails and
[I-D.dawkins-scitt-ai-article50] 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.
10.6. Audit Architecture
[I-D.kuehlewind-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 [RFC9943] 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.
11. 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
[RFC9943].
Emirdag & Feichtinger Expires 15 April 2027 [Page 24]
Internet-Draft SCITT AI Agent Execution October 2026
11.1. 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 (Section 11.5).
11.2. 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.
11.3. 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.
11.4. Replay Attack Prevention
The combination of sequence_number, prev_chain_hash, and
captured_timestamp_ms prevents replay attacks.
11.5. 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.
11.6. 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 25]
Internet-Draft SCITT AI Agent Execution October 2026
11.7. 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.
11.8. 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.
12. Privacy Considerations
Access to Evidence Chains MUST be permissioned and purpose-limited.
Checking chain integrity and sequence (steps 2 and 4 of Section 5.8)
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 Section 6 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.
Emirdag & Feichtinger Expires 15 April 2027 [Page 26]
Internet-Draft SCITT AI Agent Execution October 2026
13. 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 Section 5.6, and any registration needed in the "COSE
Verifiable Data Structure Algorithms" and "COSE Verifiable Data
Structure Proofs" registries established by [RFC9942].
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, June 2019,
<https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", RFC 9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, May 2024,
<https://www.rfc-editor.org/rfc/rfc9562>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, May 2018,
<https://www.rfc-editor.org/rfc/rfc8392>.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
COSE Headers", RFC 9597, June 2024,
<https://www.rfc-editor.org/rfc/rfc9597>.
Emirdag & Feichtinger Expires 15 April 2027 [Page 27]
Internet-Draft SCITT AI Agent Execution October 2026
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, February 2023,
<https://www.rfc-editor.org/rfc/rfc9360>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
<https://www.rfc-editor.org/rfc/rfc9942>.
[I-D.ietf-scitt-scrapi]
Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply
Chain Integrity, Transparency, and Trust (SCITT) Reference
APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-
scrapi-11, 26 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
scrapi-11>.
14.2. Informative References
[FINRA-4511]
FINRA, "General Requirements", FINRA Rule 4511.
[SEC-17a-4]
SEC, "Records to be preserved by certain exchange members,
brokers and dealers", 17 CFR 240.17a-4.
[DORA] European Parliament and Council, "Digital Operational
Resilience Act", Regulation (EU) 2022/2554, 2022.
[DORA-RTS] European Commission, "Regulatory technical standards
specifying ICT risk management tools, methods, processes,
and policies and the simplified ICT risk management
framework", Commission Delegated Regulation
(EU) 2024/1774, 13 March 2024.
[MAS-AI-RM-RESP]
Monetary Authority of Singapore, "Response to Feedback
Received on Guidelines on Artificial Intelligence Risk
Management", P017-2025, 7 October 2026.
Emirdag & Feichtinger Expires 15 April 2027 [Page 28]
Internet-Draft SCITT AI Agent Execution October 2026
[MAS-AI-RM]
Monetary Authority of Singapore, "Consultation Paper on
Guidelines on Artificial Intelligence Risk Management",
November 2025.
[PCI-DSS-4]
PCI SSC, "Payment Card Industry Data Security Standard
v4.0.1", June 2024.
[PCI-AI-SUPP]
PCI SSC, "Information Supplement: Security Considerations
for AI Systems", Version 1.0, September 2026.
[MIFID-II] European Parliament and Council, "Markets in Financial
Instruments Directive", Directive 2014/65/EU, 2014.
[EES] Veridic Inc., "Evidence Envelope Specification v0.1", URL
https://theveridic.github.io/VERIDIC/standards/ees/v0.1,
2026.
[SPIFFE] SPIFFE Project, "Secure Production Identity Framework for
Everyone", 2024.
[VCP] Kamimura, T., "A SCITT Profile for Verifiable Audit Trails
in Algorithmic Trading: The VeritasChain Protocol (VCP)",
Work in Progress, Internet-Draft, draft-kamimura-scitt-
vcp-03, July 2026, <https://datatracker.ietf.org/doc/html/
draft-kamimura-scitt-vcp-03>.
[GRIGG-2005]
Grigg, I., "Triple Entry Accounting", Systemics, Inc.,
2005, <https://iang.org/papers/triple_entry.html>.
[I-D.mih-scitt-agent-action-capsule]
Mih, S., "An Agent Action Capsule Profile for SCITT", Work
in Progress, Internet-Draft, draft-mih-scitt-agent-action-
capsule-05, 26 September 2026,
<https://datatracker.ietf.org/doc/html/draft-mih-scitt-
agent-action-capsule-05>.
[I-D.munoz-scitt-permit-profile]
Munoz, C., "A SCITT Profile for Pre-Execution AI Action
Authorization Records", Work in Progress, Internet-Draft,
draft-munoz-scitt-permit-profile-01, 18 July 2026,
<https://datatracker.ietf.org/doc/html/draft-munoz-scitt-
permit-profile-01>.
Emirdag & Feichtinger Expires 15 April 2027 [Page 29]
Internet-Draft SCITT AI Agent Execution October 2026
[I-D.munoz-wimse-authorization-evidence]
Munoz, C., "Signed Authorization-Evidence Records for
WIMSE-Authorized AI Agent Actions", Work in Progress,
Internet-Draft, draft-munoz-wimse-authorization-evidence-
01, 18 July 2026, <https://datatracker.ietf.org/doc/html/
draft-munoz-wimse-authorization-evidence-01>.
[I-D.nivalto-agentroa-route-authorization]
Michalak, J., "Agent Route Origin Authorization
(AgentROA): A Cryptographic Policy Enforcement Framework
for AI Agent Actions", Work in Progress, Internet-Draft,
draft-nivalto-agentroa-route-authorization-01, 16 April
2026, <https://datatracker.ietf.org/doc/html/draft-
nivalto-agentroa-route-authorization-01>.
[I-D.rampalli-scitt-capsule-provenance-binding]
Rampalli, K., "Binding Per-Action Authorization and Memory
Provenance into Agent Action Capsules", Work in Progress,
Internet-Draft, draft-rampalli-scitt-capsule-provenance-
binding-00, July 2026,
<https://datatracker.ietf.org/doc/html/draft-rampalli-
scitt-capsule-provenance-binding-00>.
[I-D.noa-scitt-ai-agent-receipt]
Toraman, T., "A SCITT Profile for AI-Agent Action
Receipts", Work in Progress, Internet-Draft, draft-noa-
scitt-ai-agent-receipt-01, 15 August 2026,
<https://datatracker.ietf.org/doc/html/draft-noa-scitt-ai-
agent-receipt-01>.
[I-D.sato-soos-gar]
Sato, T., "The Governance Audit Record (GAR) for Agentic
AI Systems", Work in Progress, Internet-Draft, draft-sato-
soos-gar-08, 7 September 2026,
<https://datatracker.ietf.org/doc/html/draft-sato-soos-
gar-08>.
[I-D.kamimura-scitt-refusal-events]
Kamimura, T., "Verifiable AI Refusal Events using SCITT",
Work in Progress, Internet-Draft, draft-kamimura-scitt-
refusal-events-03, 2 August 2026,
<https://datatracker.ietf.org/doc/html/draft-kamimura-
scitt-refusal-events-03>.
Emirdag & Feichtinger Expires 15 April 2027 [Page 30]
Internet-Draft SCITT AI Agent Execution October 2026
[I-D.dawkins-scitt-ai-article50]
Dawkins, V. S., "A SCITT Profile for EU AI Act Article 50
Transparency Receipts", Work in Progress, Internet-Draft,
draft-dawkins-scitt-ai-article50-00, May 2026,
<https://datatracker.ietf.org/doc/html/draft-dawkins-
scitt-ai-article50-00>.
[I-D.kuehlewind-audit-architecture]
Kuehlewind, M. and H. Birkholz, "An Architecture for
Auditing Agent Delegation and Interactions", Work in
Progress, Internet-Draft, draft-kuehlewind-audit-
architecture-01, 7 September 2026,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
audit-architecture-01>.
[I-D.sahu-agent-action-receipts]
Sahu, N., "Signed, Hash-Chained Action Receipts for AI
Agents", Work in Progress, Internet-Draft, draft-sahu-
agent-action-receipts-00, 16 August 2026,
<https://datatracker.ietf.org/doc/html/draft-sahu-agent-
action-receipts-00>.
[I-D.sparysh-pala-audit]
Sparysh, A. and O. Verteletskyi, "PALA-1: A Tamper-Evident
Audit Record Format for Constrained and Disconnected
Deployments", Work in Progress, Internet-Draft, draft-
sparysh-pala-audit-01, 2 October 2026,
<https://datatracker.ietf.org/doc/html/draft-sparysh-pala-
audit-01>.
[I-D.izmaylov-agent-permission-receipts]
Izmaylov, P., "Signed Permissions and Action Receipts for
Automated Agents", Work in Progress, Internet-Draft,
draft-izmaylov-agent-permission-receipts-00, 6 October
2026, <https://datatracker.ietf.org/doc/html/draft-
izmaylov-agent-permission-receipts-00>.
[I-D.sabey-succession-receipts]
Sabey, J., "Succession Receipts: Portable Signed Evidence
of Authority Succession Between Autonomous Agents", Work
in Progress, Internet-Draft, draft-sabey-succession-
receipts-05, 23 September 2026,
<https://datatracker.ietf.org/doc/html/draft-sabey-
succession-receipts-05>.
Emirdag & Feichtinger Expires 15 April 2027 [Page 31]
Internet-Draft SCITT AI Agent Execution October 2026
Appendix A. Changes from -00
This section is to be removed before publishing as an RFC.
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 Section 7 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. Section 1.2 states the same gap, and
the definition in Section 2 and the summary in Section 9 no longer
describe the Evidence Receipt as a SCITT Receipt. Table 1 now
points to Section 7 for the Evidence Receipt.
* The error type URN recommended in the error semantics of Section 6
is withdrawn. It does not appear in draft-ietf-scitt-scrapi-11.
Emirdag & Feichtinger Expires 15 April 2027 [Page 32]
Internet-Draft SCITT AI Agent Execution October 2026
* The recommendation in Section 9 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 Section 10.5.
* Section 8 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. Section 1.2
states that this revision does not yet define the proofs on which
non-equivocation rests. Section 5.5 says that the chain_hash, not
a receipt, commits to who, when, and what. Section 11 says that a
sequence gap shows a record that was produced and not registered,
and that an action never recorded leaves no gap. Section 12 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. Section 11 also
says that an Issuer that records an action inaccurately or not at
all is outside the threats addressed, and Section 7 says that the
admission timestamp is assigned by the Transparency Service and
that the timestamps inside the AIR are asserted by the Issuer.
* New Section 10 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 Section 1.1 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
Emirdag & Feichtinger Expires 15 April 2027 [Page 33]
Internet-Draft SCITT AI Agent Execution October 2026
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.
* Section 13 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 (Section 7).
* Integer label registration for the profile-specific protected
header parameters (Section 5.6).
* Post-quantum transition, including ML-DSA as a candidate
additional algorithm (Section 5.9).
* Key compromise recovery semantics distinguishing compromise from
retirement (Section 11.3).
* Worked examples in CBOR Extended Diagnostic Notation.
Authors' Addresses
Pinar Emirdag
Veridic Inc.
Email: e.pinar@theveridic.ai
URI: https://theveridic.ai
Daniel Feichtinger
Veridic Inc.
Emirdag & Feichtinger Expires 15 April 2027 [Page 34]
Internet-Draft SCITT AI Agent Execution October 2026
Email: f.daniel@theveridic.ai
URI: https://theveridic.ai
Emirdag & Feichtinger Expires 15 April 2027 [Page 35]