AI Agent Execution Profile of SCITT

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. Post-execution evidence of agent actions must be complete (omissions detectable), captured at execution time, tamper-evident, and verifiable without depending on the agent operator's cooperation, if it is to withstand scrutiny from regulators, courts, and insurers.¶

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

1.2. Relationship to SCITT

This profile is an application of [I-D.ietf-scitt-architecture]. It:¶

• REQUIRES compliance with [I-D.ietf-scitt-architecture]¶
• REQUIRES AIRs to be encoded as COSE_Sign1 Signed Statements [RFC9052]¶
• DEFINES domain-specific extensions for AI agent execution evidence¶

The SCITT architecture's non-equivocation property is particularly significant for this domain: it guarantees that two different Relying Parties cannot be shown two different versions of the same Evidence Chain. 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)¶
• 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 [I-D.ietf-scitt-architecture])¶
• COSE Receipt format (see [RFC9052])¶
• 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¶

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

The Issuer's signing key MUST be registered with the Transparency Service prior to 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

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

The following action types are defined by this profile:¶

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

; 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 [I-D.ietf-scitt-architecture] Section 5.1.1.1 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. 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 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.¶

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

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: a receipt proves 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). 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 [I-D.ietf-scitt-architecture] Section 5.1.1.1 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 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:¶

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 total ordering guarantee that is cryptographically enforced rather than administratively asserted.¶

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.¶
4. Sequence completeness. Verify sequence_number is exactly one greater than 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.¶