Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs

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 4 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

An AI agent is a workload whose behaviour is driven, in whole or in part, by a non-deterministic decision process, typically a large language model (LLM), and which acts on the world by invoking tools, services and resources. Every consequential thing an agent does passes through one of two doors: a call to a model (an inference) or a call to a tool. If evidence is produced at those two doors, bound to the agent's identity and to the policy in force, and registered in an append-only, non-equivocating log, a third party can later establish what the agent did, under which rules, and with which configuration, without trusting the operator's own logs.¶

The WIMSE AI Identity Management System [I-D.ietf-wimse-aims] describes how agent identities are established, credentials provisioned and authorization decisions made. It requires tamper-evident audit logs with a minimum set of fields (Section 11) but leaves the format of those logs open; it states that posture evidence formats (Section 8), the policy model and document format (Section 12) and compliance criteria (Section 13) are out of scope. The audit architecture in [I-D.kuehlewind-audit-architecture] identifies SCITT Signed Statements, Receipts and Transparent Statements as the canonical artifacts for non-repudiable custody of audit records and lists a SCITT registration policy profile as a work item. This document is a concrete proposal for that profile.¶

Several individual drafts already profile SCITT for agent actions (Section 13). Each records that an action happened and its disposition. Four gaps remain that this profile addresses:¶

1. An identity that a party other than the operator vouches for, bound to a per-call evidence chain. A workload identifier proves which software is making a call, but the operator of that software issues it to itself, within its own trust domain. It does not say which agent the software is, who is accountable for it, or whether it is the agent that was assessed, and an agent that runs in several environments has several unrelated identifiers (Section 3.1.2 of [I-D.ietf-wimse-arch]). This profile separates a long-term agent identity, issued by an Agent Registration Authority that Relying Parties accept, from the runtime identities under which the operator's software authenticates (Section 4). An Agent Credential Statement records which runtime identities belong to the agent, and every Execution Receipt carries the runtime identifier, the preceding record hash and optionally a per-call agent signature, so that a chain of receipts is bound to one registered agent and cannot be spliced.¶

2. Integrity of instruction files, system prompts and tool manifests. An agent's behaviour is determined as much by its system prompt, instruction files, skills, hooks, tool manifests and memory as by its model, and injection through these inputs, including through invisible Unicode, is a documented attack class. This profile defines a Configuration Integrity Statement that commits to digests of the static inputs after mandatory Unicode normalization, requires every Execution Receipt to reference the configuration in force, and commits to the state of memory at the start and end of each Task.¶

3. Revocable operational assurance bound to running evidence, under supervision. An assessment is useful only while the assessed identity, capabilities, policy, configuration and deployment remain applicable. This profile binds an Assurance Statement to those values, records its risk basis and monitoring coverage, and lets a Supervisory Authority, separate from the assessor, restrict, suspend or withdraw it.¶

4. Evidence where a call is received, and across calls between agents. Agents increasingly call services operated by other parties, and those services are increasingly agents themselves. A request can pass through several agents, each run by a different operator, before it reaches the system that acts on it. For example, an assistant acting for an individual asks a platform's agent to file an application; that agent queries a records service; the records service calls an identity-verification service. Records produced only on the calling side cannot support the decision made on the serving side, and records kept separately on each side cannot show that they describe the same call.¶

A Serving Party decides on every call whether to act. It is the only party that can apply its own conditions whatever the caller's operator does, but it sees one call at a time and not the history that led to it. The decision is made per call, not per session or per credential, because what it depends on changes between calls: an agent's assurance can be suspended within minutes, one agent can act for many Principals with different permissions, and operations on the same service carry different risk. This profile therefore defines an admission record that a Serving Party produces for every call it receives, stating what it checked and what it decided. That record is the Serving Party's evidence of its own conduct and gives an auditor a second, independent record of the call. Only the caller's record shows why a call was made; only the Serving Party's record shows what was admitted and on what basis; comparing the two, when both parties' chains are verified together, shows a call that either side omitted.¶

When a request passes through intermediaries, four questions need answers that no single hop's record supplies: which agent originated the request and for which Principal; whether any intermediary used authority broader than that Principal's; whether suspending an agent stops the work it started further along; and which operator's agent did what. The WIMSE architecture requires that "each hop in the chain MUST explicitly scope and re-bind the security context" and that autonomous actions "MUST be clearly distinguished from delegated ones" (Section 3.4.11 of [I-D.ietf-wimse-arch]). This profile links each hop's records to those of the hop before it and carries the principal of the transaction, a transaction identifier and the sequence of acting agents with the request, so that a verifier can answer these questions from evidence rather than from the operators' accounts.¶

A declared objective, attested runtime and guardrails do not constrain every means an agent may choose. During a 2026 cyber-capability evaluation, agents created an unsanctioned coordination channel, pursued scorer tampering, crossed task boundaries and investigated altering their traces [METR-HF]. This motivates third-party review of whether capabilities and controls are proportionate to purpose.¶

Monitoring is a distinct safeguard after assessment: for highly autonomous or otherwise higher-risk agents, it checks observed operation against the assessed scope and approved controls and supports reassessment, suspension or withdrawal. Article 72 of [EUAIACT] requires proportionate lifetime monitoring for legally classified high-risk AI systems. This profile's higher_risk value is not that legal classification and does not establish compliance.¶

This document is a profile of [RFC9943] and [RFC9942]. It does not change the SCITT architecture and does not define an identifier scheme, how a registry or Supervisory Authority is established, a policy language or an accreditation scheme.¶

2. Terminology

This document uses the terms Artifact, Issuer, Receipt, Registration, Registration Policy, Relying Party, Signed Statement, Statement, Transparency Service (TS), Transparent Statement and Verifiable Data Structure (VDS) as defined in Section 3 of [RFC9943]; Workload, Trust Domain and Workload Identity Credential as defined in Section 2 of [I-D.ietf-wimse-arch]; Actor and Delegation as in Sections 1.1 and 4.1 of [RFC8693]; and Call Chain and Transaction as defined in Section 3 of [I-D.ietf-oauth-transaction-tokens], except that a Call Chain here may cross Trust Domains. The principal of the transaction is the subject named by the sub claim of a Transaction Token (Section 9.2 of [I-D.ietf-oauth-transaction-tokens]). This profile uses delegation semantics only, never impersonation.¶

The terms below are either profiled from existing IETF vocabulary, as stated in each definition, or introduced by this document. Agent Registration Authority, Calling Agent, Caller Reference, Linked Evidence Chains, Linked Verification, Principal Link, Responsible Entity, Serving Party, Sub-agent and Supervisory Authority have no equivalent in the IETF specifications cited here.¶

Actor Chain:

The ordered list of Actors that have acted on a request, least recent first. It is the list form of a chain of delegation expressed by nested act claims (Section 4.1 of [RFC8693]): the most deeply nested act is the first entry and the outermost act, the current actor, is the last. The term "actor chain" is used in Section 3.4.9 of [I-D.ietf-wimse-arch].¶

Admission:

The authorization decision a Serving Party makes for one call, recorded as an Execution Receipt of type admission (Section 6.7.2). It is a policy decision in the sense of [RFC3198], made per call and recorded.¶

Agent:

A workload whose behaviour is driven, in whole or in part, by a non-deterministic decision process (typically an LLM) and that invokes tools, services or resources, as in Section 4 of [I-D.ietf-wimse-aims].¶

Agent Assurance Assessor:

A SCITT Issuer that evaluates an agent and issues Assurance Statements (Section 6.8). It MAY be the Responsible Entity at assurance levels 1 and 2. At levels 3 and 4 it MUST be a Third-Party Agent Assurance Assessor.¶

Agent Registration Authority:

A SCITT Issuer that issues long-term agent identities: it verifies the Responsible Entity, records what was declared for the agent, assigns the logical_agent_id and lineage_id, and maintains the registration's status (Section 4). How an authority is established is out of scope. The name is unrelated to SCITT Registration, which is the act of entering a Signed Statement into a TS.¶

Bundle:

A self-contained set of Transparent Statements and Execution Receipts sufficient for offline verification of a segment of an Evidence Chain (Section 8).¶

Caller Reference:

The member of an admission receipt that identifies the Calling Agent's Execution Receipt for the same call (Section 6.7.3).¶

Calling Agent, Serving Party:

For a given call, the agent that makes it, and the workload, possibly itself an agent, that receives it and decides whether to act on it. These are roles in one call, not kinds of agent: an agent is a Serving Party for the call it receives and a Calling Agent for the calls it then makes. In the terms of [RFC8693], the Calling Agent is the current actor. A Serving Party that verifies evidence before admitting a call acts as a Relying Party.¶

Capability Profile:

The operator's declaration of an agent's purpose and effective model, tool, data, permission and delegation scope, including the functions of any Sub-agents, committed to by digest at registration and in an Assurance Statement.¶

Decision Point:

A point at which a call is intercepted, a policy decision taken and enforced, and an Execution Receipt produced. It combines a Policy Decision Point and a Policy Enforcement Point ([RFC3198]) and adds recording. In a Harness these are the model door (every inference) and the tool door (every tool invocation, its result and any resulting egress); at a Serving Party, the ingress door (every call received).¶

Evidence Chain:

An ordered sequence of Execution Receipts, each carrying the hash of its predecessor, scoped to one Agent Credential or Serving Party Credential Statement (Section 6.7.1).¶

Evidence Service:

The service, operated by or for the Harness or Serving Party operator, that issues Execution Receipt and Execution Epoch Statements and registers them with a TS; the SCITT Issuer for those statements.¶

Execution Receipt:

A single record produced at a Decision Point (Section 6.7); registered with a TS, individually or through an epoch root, it becomes an Execution Receipt Statement.¶

Harness:

The runtime that hosts an agent, mediates its calls to models and tools, and operates the Decision Points.¶

Linked Evidence Chains, Linked Verification:

The Evidence Chains of the parties to one Call Chain, linked through Caller References; and their verification together (Section 9.1).¶

Logical Agent, Runtime Identity:

The persistent identity of an agent across environments, named by a logical_agent_id issued by an Agent Registration Authority; and a workload identifier (Section 3.1.2 of [I-D.ietf-wimse-arch]) under which the agent authenticates in one Trust Domain for one period. A Logical Agent is a logical workload in the sense of Section 2 of [I-D.ietf-wimse-arch] that is an agent. One Logical Agent MAY have several Runtime Identities.¶

Operational Assurance:

Time-bounded confidence that an identified agent's assessed capabilities, deployment and controls remain within their approved scope, based on assessment and, where required, continuing monitoring.¶

Policy Pack:

A versioned document that configures Decision Points, layered by digest reference to a parent (Section 6.5). The policy document format is out of scope.¶

Principal:

The natural person, organization or workload on whose behalf an agent acts for a given Task. It is the "delegated subject (user or system)" of Section 11 of [I-D.ietf-wimse-aims], and is used as in Section 1.1 of [RFC8693].¶

Principal Link:

A digest that lets the two parties to a call show that they recorded the same Principal without revealing it (Section 6.7.3).¶

Responsible Entity:

The legal or natural person accountable for a Logical Agent, as registered in its Agent Registration Statement.¶

Sub-agent:

An agent instantiated by another agent, its parent, to perform a declared function within the parent's Tasks. A Sub-agent has no Logical Agent identity of its own and acts under its parent's (Section 6.3.1).¶

Supervisory Authority:

The Issuer that a Relying Party's or TS's policy designates for a scheme named by scheme_id. It publishes the scheme, holds the status of Assurance Statements issued under it, and alone restricts, suspends or withdraws them (Section 6.8.2).¶

Task:

A unit of agent work delimited by task_start and task_end Execution Receipts and named by the seq of its task_start.¶

Third-Party Agent Assurance Assessor:

An Agent Assurance Assessor that is organizationally independent of the Responsible Entity and agent operator, and whose identity and signing key a Relying Party accepts under its trust policy. This profile-specific role can perform the RATS Verifier role or consume Attestation Results from an accepted RATS Verifier, but also assesses the agent's capabilities, deployment and controls. Existing IETF specifications do not define qualification, independence-testing or accreditation criteria for this role.¶

This profile defines eleven Signed Statement types: Agent Registration, Model Provider, Agent Credential, Serving Party Credential, Policy Pack, Configuration Integrity, Configuration Drift, Execution Receipt, Execution Epoch, Assurance and Revocation Statements (Section 6.1 to Section 6.8).¶

3. Identifiers

This profile imports identifier schemes and does not define one.¶

logical_agent_id:

MUST be a did:web identifier [DID-WEB] whose domain name, the first component of the method-specific identifier after percent-decoding, equals the host component of the iss of the Agent Registration Statement that assigned it, for example did:web:register.example:agent:a1b2c3 issued by https://register.example. The identifier itself thus shows which authority vouches for the agent.¶

Runtime Identity:

SHOULD be a Workload Identifier as defined in [I-D.ietf-wimse-identifier] (the spiffe or wimse scheme). Section 6 of [I-D.ietf-wimse-aims] requires that an agent be assigned exactly one WIMSE identifier; within any one such deployment, that identifier is the agent's Runtime Identity there, and the Logical Agent sits above the Runtime Identities of all its deployments.¶

service_id:

A URI under a domain that the Serving Party controls, using the https, spiffe, wimse or did:web scheme.¶

Implementations MUST treat all identifiers as opaque strings for comparison purposes; two identifiers are equal if and only if their octet sequences are equal.¶

The CWT Claims header parameter (label 15) required by Section 6 of [RFC9943] MUST carry the Issuer in iss (label 1). In sub (label 2), Agent Credential, Configuration Integrity, Configuration Drift, Execution Receipt and Execution Epoch Statements carry the applicable Runtime Identity (or service_id); Agent Registration and Assurance Statements carry logical_agent_id; Serving Party Credential Statements carry service_id; Model Provider Statements carry model_id; Policy Pack Statements carry pack_id; and Revocation Statements repeat the sub of the statement revoked.¶

A Principal is carried as a claim inside the statement payload, not in the COSE header, because a Principal is not an Artifact subject in the SCITT sense and because the header is visible to the TS. A Principal of kind natural person MUST be represented by a 32-octet digest computed as SHA-256 over the concatenation of a pepper held by the statement's Issuer and the canonical identifier of the person (Section 10). A Principal of kind organization or workload MAY be represented in clear text.¶

4. Agent Identification

A Relying Party that must decide whether to act on an agent's request, or hold someone accountable afterwards, needs an identity that persists across environments and that a party other than the operator vouches for. This profile obtains it in the following steps.¶

1. Declaration. The operator submits to an Agent Registration Authority the agent's Capability Profile and, for each model in it, the Model Provider Statement (Section 6.2) where the provider has issued one. The Capability Profile identifies each model by a dated version identifier and, where available, by the digest of that statement.¶

2. Verification. The authority verifies the Responsible Entity by its own identity-proofing procedures, which are out of scope. It SHOULD require the operator to prove possession, at registration, of the agent key it will name in its first Agent Credential Statement.¶

3. Registration. The authority issues an Agent Registration Statement (Section 6.1) assigning the logical_agent_id and lineage_id and committing to what was declared, and registers it on a TS. The registered statement is the authoritative record of the agent's identity.¶

4. Operation. The operator issues Agent Credential Statements (Section 6.3) that reference the registration and list the agent's Runtime Identities, key, Harness, model binding and Sub-agents. These change as the agent moves between environments and its keys rotate; the registration does not.¶

5. Status. The authority maintains the registration's status in a Token Status List [I-D.ietf-oauth-status-list] and ends it, where required, with a Revocation Statement: reason code 5 (closed) for administrative retirement and 3 (withdrawn) for an adverse finding.¶

6. Change and lineage. A change to the declared Capability Profile, or a new Model Provider Statement for a model in it, requires a superseding Agent Registration Statement with the same logical_agent_id and lineage_id, and reassessment; the authority MUST revoke the superseded registration with reason code 2 (superseded), so that credentials naming it cease to verify. A change of Responsible Entity, for example on a transfer between organizations, requires a new registration with a new logical_agent_id and the same lineage_id; the previous registration is closed, and the agent MUST be reassessed before use. The lineage_id keeps the history of earlier registrations, adverse entries included, linked to the agent.¶

A Relying Party is configured with the set of Agent Registration Authorities it accepts. An agent registered by an authority in another jurisdiction is verified identically and accepted only if that authority is in the set; how authorities come to recognize one another is out of scope. An organization MAY act as the Agent Registration Authority for its own agents; whether a Relying Party accepts it is a matter of policy.¶

An Agent Registration Authority MAY also publish registrations through other channels. Such channels are not authoritative: the registered statement and its status prevail.¶

5. Common Encoding

Each statement type defined here is a CBOR map with integer keys. Hash algorithm identifiers are taken from the IANA COSE Algorithms registry. The CDDL in this document uses the conventions of [RFC8610]. Every payload is encoded with the deterministic encoding rules of Section 4.2.1 of [RFC8949] ("canonical CBOR" below).¶

aee-statement = agent-credential / policy-pack / config-integrity
              / config-drift / execution-receipt / execution-epoch
              / assurance / revocation / agent-registration
              / serving-party-credential / model-provider

aee-type = &(
  agent-credential:          1,
  policy-pack:               2,
  config-integrity:          3,
  config-drift:              4,
  execution-receipt:         5,
  execution-epoch:           6,
  assurance:                 7,
  revocation:                8,
  agent-registration:        9,
  serving-party-credential: 10,
  model-provider:           11
)

; A digest is a COSE hash algorithm identifier and the digest value.
; SHA-256 is -16 in the IANA COSE Algorithms registry.
digest = [ alg: int, value: bstr ]

validity = {
  1 => uint,    ; nbf, seconds since the Unix epoch
  2 => uint     ; exp, seconds since the Unix epoch
}

principal = {
  1 => principal-kind,  ; kind
  2 => bstr / tstr,  ; id: 32-octet digest for natural persons,
                     ; otherwise an identifier
  ? 3 => principal-assurance,  ; principal_assurance
  ? 4 => delegation-ref        ; delegation_ref
}
principal-kind = &( natural-person: 1, organization: 2, workload: 3 )

; How strongly the Principal was verified, as a Vector of Trust
; (RFC 8485): the vector (at least its identity proofing
; component) and the trustmark URL of the trust framework
; that defines the values.
principal-assurance = {
  1 => tstr,         ; vot, for example "P2"
  2 => tstr,         ; vtm, trustmark URL
  ? 3 => tstr        ; verifier: who performed the proofing
}

; The Principal's grant of authority to this agent.
delegation-ref = {
  1 => digest,       ; token_digest of the delegation token
  ? 2 => status-ref  ; status of this delegation
}

In the JSON form, kind determines whether id is a base64url digest or a clear-text identifier. principal_assurance records how strongly the Principal's identity was verified, using the identity proofing dimension of Section 2.1 of [RFC8485]; each jurisdiction's trust framework, named by the trustmark, defines the values, so that Principals proofed under different trust frameworks are recorded by the same mechanism. delegation_ref lets one Principal's delegation be revoked without revoking the agent: its status entry is maintained by whoever granted the delegation. Both are fixed for a Task, as the rest of principal is (Section 6.7.1).¶

No statement defined here contains a floating-point value, and an Issuer MUST NOT emit one, including NaN or an infinity. Text strings MUST be valid UTF-8. A payload that violates either rule, or that has duplicate map keys, is malformed: an Issuer MUST NOT repair it before signing or hashing, and a TS or Relying Party MUST reject it.¶

Each statement is carried as the payload of a COSE_Sign1 Signed Statement per Section 6 of [RFC9943]. The protected header MUST contain alg (label 1); content type (label 3) set to application/aee-statement+cbor or application/aee-statement+json; kid (label 4), x5t (label 34) or x5chain (label 33) per Section 6 of [RFC9943]; and the CWT Claims header parameter (label 15) with iss, sub and the aee_type claim (Section 12.2), whose value MUST equal key 1 of the payload. Duplicating the type in the header lets a TS apply type-specific Registration Policy (Section 7) from the non-opaque header, as Section 3 of [RFC9943] requires, without parsing the payload.¶

6. Statement Types

agent-registration = {
  1 => 9,                   ; aee-type
  2 => tstr,                ; logical_agent_id (see {{ids}})
  3 => principal,           ; responsible_entity
  4 => tstr,                ; lineage_id
  5 => digest,              ; capability_profile_digest, as declared
  6 => [ * digest ],        ; provider_statement_digests
  7 => validity,            ; validity
  ? 8 => status-ref,        ; status: Token Status List reference
  ? 9 => tstr,              ; scheme_id: registration scheme (URI)
  ? 10 => digest            ; prior_registration_digest
}

model-provider = {
  1 => 11,                  ; aee-type
  2 => tstr,                ; model_id: dated version identifier
  3 => tstr,                ; provider
  ? 4 => digest,            ; weights_digest
  5 => digest,              ; evaluations_digest
  6 => digest,              ; safeguards_digest
  7 => [ + tstr ],          ; permitted_uses
  ? 8 => digest,            ; training_data_summary_digest
  ? 9 => digest,            ; change_commitments_digest
  10 => uint                ; iat, seconds since the Unix epoch
}

agent-credential = {
  1 => 1,                   ; aee-type
  2 => tstr,                ; agent_id (see {{ids}})
  3 => COSE_Key,            ; agent_key, RFC 9052 Section 7
  4 => principal,           ; principal
  5 => harness,             ; harness
  6 => model-binding,       ; model_binding
  7 => validity,            ; validity
  ? 8 => tstr,              ; credential_ref: identifier of the
                            ; workload credential (e.g. WIT jti,
                            ; certificate thumbprint) this binds to
  9 => tstr,                ; logical_agent_id
  10 => principal,          ; responsible_entity
  11 => [ + runtime-identity ],  ; runtime_identities
  12 => lifecycle-class,    ; lifecycle_class
  13 => digest,             ; registration_digest: digest of the
                            ; Agent Registration Statement payload
  ? 14 => [ + subagent ]    ; subagents
}

runtime-identity = {
  1 => tstr,                ; identifier
  2 => id-scheme,           ; scheme
  3 => tstr,                ; trust_domain
  4 => uint,                ; valid_from, seconds since Unix epoch
  5 => uint                 ; valid_until
}
id-scheme = &( wimse: 1, spiffe: 2, did: 3, oidc: 4,
               cloud-native: 5, other: 6 )
lifecycle-class = &( ephemeral: 1, persistent: 2 )

subagent = {
  1 => tstr,                ; subagent_ref, unique within the parent
  2 => tstr,                ; function, as declared
  ? 3 => COSE_Key,          ; subagent_key
  ? 4 => [ + runtime-identity ]  ; runtime_identities
}

harness = {
  1 => tstr,                ; name
  2 => tstr,                ; version
  ? 3 => digest             ; digest: of the harness binary/image
}

model-binding = {
  1 => binding-mode,        ; mode
  ? 2 => digest,            ; weights_digest (mode 1 only)
  ? 3 => tstr,              ; model_id as named by the provider
  ? 4 => tstr,              ; provider
  ? 5 => bstr,              ; tee_evidence: digest of or reference
                            ; to RATS Evidence (mode 3 only)
  ? 6 => digest             ; provider_statement_digest
}
binding-mode = &( weights-digest: 1, api: 2, api-tee: 3 )

serving-party-credential = {
  1 => 10,                  ; aee-type
  2 => tstr,                ; service_id (see {{ids}})
  3 => COSE_Key,            ; service_key
  4 => principal,           ; responsible_entity
  5 => validity,            ; validity
  ? 6 => [ + runtime-identity ]  ; runtime_identities
}

policy-pack = {
  1 => 2,                   ; aee-type
  2 => tstr,                ; pack_id (URI or opaque name)
  3 => tstr,                ; pack_version
  4 => digest,              ; pack_digest over the pack document
  ? 5 => digest,            ; parent_pack_digest
  6 => layer,               ; layer
  ? 7 => tstr               ; pack_content_type of the document
}
layer = &( jurisdiction: 1, sector: 2, institution: 3,
           deployment: 4 )

config-integrity = {
  1 => 3,                   ; aee-type
  2 => tstr,                ; agent_id
  3 => [ + config-entry ],  ; entries, ordered by name (octet order)
  4 => digest,              ; config_digest over canonical entries
  5 => uint,                ; normalization, 1 or 2 (below)
  6 => uint                 ; iat, seconds since the Unix epoch
}
config-entry = [
  name: tstr,               ; path or logical name
  value: digest,            ; digest of the normalized content
  class: config-class
]
config-class = &(
  system_prompt:    1,
  instruction_file: 2,
  skill:            3,
  hook:             4,
  mcp_config:       5,
  tool_manifest:    6,
  tool_description: 7
)

config-drift = {
  1 => 4,                   ; aee-type
  2 => tstr,                ; agent_id
  3 => digest,              ; prev_config_digest
  4 => digest,              ; new_config_digest
  5 => [ + drift-entry ],   ; changes
  6 => uint                 ; iat
}
drift-entry = [
  name: tstr,
  class: config-class,
  change: &( added: 1, modified: 2, removed: 3 ),
  ? old: digest,
  ? new: digest
]

execution-receipt = {
  1 => 5,                   ; aee-type
  2 => uint,                ; seq, per Evidence Chain, from 0
  3 => bstr .size 32,       ; prev_hash: record-hash of seq-1,
                            ; or 32 zero octets when seq = 0
  4 => record-type,         ; record_type
  ? 5 => uint,              ; parent_seq (see below)
  6 => decision,            ; decision
  7 => digest,              ; policy_pack_digest in force
  8 => digest,              ; config_integrity_digest in force
  9 => tstr,                ; agent_id: Runtime Identity in force
  10 => principal,          ; principal
  11 => uint,               ; task_seq: seq of the Task's task_start
  ? 12 => digest,           ; request_digest
  ? 13 => digest,           ; response_digest
  14 => uint,               ; ts, milliseconds since the Unix epoch
  ? 15 => bstr .cbor COSE_Sign1,  ; agent_sig (per-call signature)
  ? 16 => tstr,             ; target: model_id or tool name
  ? 17 => tstr,            ; egress_host (lowercase A-label, no port)
  ? 18 => decision-point,   ; decision_point
  ? 19 => uint,             ; confirm_seq: the confirm it resolves
  ? 20 => tstr,             ; caller_agent_id (admission only)
  ? 21 => caller-ref,       ; caller_ref (admission only)
  ? 22 => admission-basis,  ; admission_basis (admission only)
  ? 23 => [ + tstr ],       ; actor_chain, least recent first
  ? 24 => bstr .size 32,    ; principal_link
  ? 25 => tstr,             ; txn: transaction identifier
  ? 26 => digest,           ; memory_digest (task_start, task_end)
  ? 27 => subagent-ref,     ; subagent
  ? 28 => uint              ; delegated_from (task_start only)
}
record-type = &(
  task_start:  1,
  task_end:    2,
  inference:   3,
  tool_call:   4,
  tool_result: 5,
  egress:      6,
  admission:   7
)
decision = &( allow: 1, block: 2, confirm: 3, record: 4 )
decision-point = &( model: 1, tool: 2, network: 3, ingress: 4 )

caller-ref = {
  1 => tstr,                ; evidence_service: the caller's
                            ; Evidence Service (its Issuer)
  2 => uint,                ; seq of the caller's receipt
  3 => bstr .size 32        ; record_hash of the caller's receipt
}
admission-basis = {
  ? 1 => digest,            ; assurance_statement_digest
  ? 2 => 1..4,              ; assurance_level relied on
  3 => uint,                ; status_checked_at, seconds since
                            ; the Unix epoch
  ? 4 => uint,              ; status_value observed
  ? 5 => digest,            ; registration_digest
  ? 6 => digest             ; token_digest of the token presented
}
subagent-ref = {
  1 => tstr,                ; subagent_ref
  2 => tstr,                ; function
  ? 3 => uint               ; instance
}

execution-epoch = {
  1 => 6,                   ; aee-type
  2 => tstr,                ; agent_id
  3 => uint,                ; first_seq
  4 => uint,                ; last_seq
  5 => bstr .size 32,       ; first_prev_hash: prev_hash of first_seq
  6 => bstr .size 32,       ; last_hash: record-hash of last_seq
  7 => bstr .size 32,       ; epoch_root
  8 => uint                 ; count = last_seq - first_seq + 1
}

assurance = {
  1 => 7,                   ; aee-type
  2 => tstr,                ; assessor: Agent Assurance Assessor ID
  3 => digest,              ; agent_credential_digest: digest of the
                            ; Agent Credential Statement payload
  4 => digest,              ; policy_pack_digest
  5 => digest,              ; config_integrity_digest
  6 => tstr,                ; suite_id (URI)
  7 => tstr,                ; suite_version
  8 => &( pass: 1, fail: 2, partial: 3 ),  ; result
  ? 9 => digest,            ; report_digest of the full report
  10 => validity,           ; validity
  ? 11 => status-ref,       ; status: Token Status List reference
  12 => 1..4,               ; assurance_level
  13 => assessed-scope,     ; assessed_scope
  14 => risk-assessment,    ; risk_assessment
  ? 15 => monitoring-summary, ; monitoring_summary
  16 => tstr,               ; logical_agent_id
  ? 17 => digest            ; independence_declaration_digest
}
assessed-scope = {
  1 => digest,              ; capability_profile_digest
  2 => digest,              ; approved_model_scope_digest
  3 => digest,              ; approved_tool_scope_digest
  4 => &( public-cloud: 1, private-cloud: 2, on-prem: 3,
          air-gapped: 4, edge: 5 ),  ; deployment_class
  5 => tstr,                ; declared_purpose
  6 => [ + tstr ],          ; objectives
  7 => [ + tstr ],          ; intended_use
  8 => digest,              ; approved_data_scope_digest
  9 => digest,              ; approved_permission_scope_digest
  10 => digest              ; approved_delegation_scope_digest
}
risk-assessment = {
  1 => tstr,                ; scheme_id (URI)
  2 => tstr,                ; tier in that scheme
  3 => bool,                ; higher_risk
  4 => digest               ; risk_assessment_digest
}
monitoring-summary = {
  1 => uint,                ; period_start
  2 => uint,                ; period_end
  3 => uint,                ; review_frequency, seconds
  4 => [ + monitoring-dimension ], ; coverage
  5 => digest,              ; evidence_digest
  6 => uint,                ; deviation_count
  7 => &( continue: 1, reassess: 2, suspend: 3, withdraw: 4 ),
                              ; disposition
  ? 8 => digest             ; findings_digest
}
monitoring-dimension = &( purpose: 1, model: 2, tool: 3, data: 4,
  permission: 5, delegation: 6, policy: 7, configuration: 8,
  deployment: 9, control: 10, execution: 11 )
; status-ref is the value of the "status" claim for CWT Referenced
; Tokens as defined in [I-D.ietf-oauth-status-list].
status-ref = { * any => any }

revocation = {
  1 => 8,                   ; aee-type
  2 => digest,              ; subject_digest: digest of the
                            ; payload of the revoked statement
  3 => uint,                ; reason_code (1 key-compromise,
                            ; 2 superseded, 3 withdrawn, 4 other,
                            ; 5 closed)
  4 => uint,                ; iat
  ? 5 => tstr               ; reason
}

7. Registration Policy

Section 5.1.1 of [RFC9943] requires a TS to apply a Registration Policy and to make that policy transparent. A TS that accepts statements of this profile MUST perform the mandatory checks of Section 5.1.1.1 of [RFC9943] and the following type-specific checks, keyed on the aee_type claim in the protected header. A failing check MUST result in refusal to register; with [I-D.ietf-scitt-scrapi] this is a 400 response with Concise Problem Details.¶

All types:

The aee_type claim MUST match key 1 of the payload; the content type MUST be one of the statement media types of Section 12.1; and the payload MUST be well-formed. sub MUST match the type-specific subject defined in Section 3.¶

Agent Credential (1):

validity.nbf MUST be less than validity.exp. The agent_key MUST be a COSE_Key whose alg is in the TS's accepted set. If the TS is configured to require it, credential_ref MUST be present. agent_id MUST appear in runtime_identities, and each entry's valid_from MUST be less than its valid_until. An Agent Registration Statement whose payload digest equals registration_digest MUST already be registered, and its logical_agent_id and responsible_entity MUST equal this credential's. If present, provider_statement_digest MUST be among that registration's provider_statement_digests. subagent_ref values MUST be unique, and each Sub-agent's runtime_identities entries MUST have valid_from less than valid_until.¶

Policy Pack (2):

If parent_pack_digest is present, a Policy Pack Statement whose pack_digest equals it MUST already be registered on this TS, and its layer MUST be strictly less than this pack's layer. The TS MUST NOT register a pack that references itself, directly or through its ancestors.¶

Configuration Integrity (3):

config_digest MUST equal the digest of the canonical encoding of entries. entries MUST be ordered by name in octet order and MUST NOT contain duplicate names. normalization MUST be 1 or 2.¶

Configuration Drift (4):

Configuration Integrity Statements with config_digest equal to prev_config_digest and to new_config_digest MUST both already be registered for the same agent_id.¶

Execution Receipt (5) and Execution Epoch (6):

An Agent Credential or Serving Party Credential Statement for agent_id with the same Issuer, or an Issuer the TS's policy accepts for that agent, MUST already be registered. For an individually registered Execution Receipt, a Policy Pack Statement with pack_digest equal to policy_pack_digest MUST already be registered, and a Configuration Integrity Statement with config_digest equal to config_integrity_digest MUST already be registered, its registration preceding this registration. An Execution Epoch carries neither digest, so for receipts sealed in an epoch these two checks are made by the Relying Party (Section 9, steps 11 and 12). For an Execution Epoch, count MUST equal last_seq - first_seq + 1, and if an epoch for the same agent_id and Issuer has already been registered, this epoch's first_seq MUST equal that epoch's last_seq + 1 and its first_prev_hash MUST equal that epoch's last_hash. The TS cannot check receipt contents it does not see; the precedence and continuity checks are what it can and MUST enforce.¶

Assurance (7):

assessor MUST equal the protected iss. Statements whose payload digests equal policy_pack_digest and config_integrity_digest MUST already be registered on this TS. The referenced Agent Credential Statement MUST already be registered, its logical_agent_id MUST match key 16 and sub, and capability_profile_digest MUST equal that of the Agent Registration Statement it names. At operational assurance level 3 or 4, independence_declaration_digest MUST be present and, where the registered responsible_entity is an organization, assessor MUST differ from it. validity.nbf MUST be less than validity.exp; scheme_id, tier, declared_purpose, objectives and intended_use MUST be nonempty. If present, a monitoring period MUST end after it starts and review_frequency MUST be non-zero. A higher-risk pass MUST meet the level 4, monitoring, status and disposition requirements of Section 6.8.¶

Revocation (8):

A statement whose payload digest equals subject_digest MUST already be registered. The Issuer of the Revocation Statement MUST be the Issuer of that statement or, for an Assurance Statement, the Supervisory Authority that the TS's policy designates for its scheme_id.¶

Agent Registration (9):

logical_agent_id MUST be a did:web identifier whose domain name equals the host of the protected iss (Section 3). lineage_id MUST be nonempty, and validity.nbf MUST be less than validity.exp. If prior_registration_digest is present, a registration with that payload digest and the same lineage_id MUST already be registered. If the TS's policy requires it, each of provider_statement_digests MUST name a registered Model Provider Statement.¶

Serving Party Credential (10):

validity.nbf MUST be less than validity.exp, and the service_key MUST be a COSE_Key whose alg is in the TS's accepted set.¶

Model Provider (11):

model_id, provider and permitted_uses MUST be nonempty.¶

A TS MUST make these checks reproducible by Auditors as required by Section 5.1.1.2 of [RFC9943]; publishing the Registration Policy as a Signed Statement that cites this document by name and version is sufficient.¶

8. Bundle

A Bundle is the unit a Relying Party verifies. It is a CBOR map.¶

aee-bundle = {
  1 => [ + Transparent_Statement ],  ; statements (RFC 9943 Sec. 7)
  2 => [ * execution-receipt ],      ; chain segment, ascending seq
  ? 3 => { * uint => inclusion-path },  ; seq => path into its epoch
  ? 4 => [ * bstr .cbor COSE_Sign1 ]    ; Status List Tokens
}
inclusion-path = [
  tree-size: uint,
  leaf-index: uint,
  path: [ * bstr .size 32 ]
]

Key 1 MUST contain, as Transparent Statements, the Agent Credential or Serving Party Credential Statement, the Agent Registration Statement an Agent Credential names, every Policy Pack Statement in the lineage of every policy_pack_digest in key 2, every Configuration Integrity Statement referenced, every Execution Epoch Statement covering a receipt in key 2 (or the receipt's own Transparent Statement), and any Assurance and Revocation Statements the producer wishes considered. Key 3 is REQUIRED for any receipt whose epoch is not wholly present in key 2. Key 4 carries a snapshot of each Status List Token referenced by an Assurance or Agent Registration Statement, or by a delegation_ref, for offline evaluation as of the snapshot time. Model Provider Statements MAY be included.¶

A Linked Bundle is an ordered array of Bundles, one for each Evidence Chain of a Call Chain, each sufficient on its own, with media type application/aee-linked-bundle+cbor. It is verified as in Section 9.1.¶

aee-linked-bundle = [ 2* aee-bundle ]

The media type of a Bundle is application/aee-bundle+cbor. A JSON form with the member names statements, receipts, proofs and status_tokens, Transparent Statements as base64url COSE_Sign1, has media type application/aee-bundle+json.¶

9. Verification

A Relying Party verifies a Bundle by the following steps. The steps are ordered; the first failure terminates verification with the named error. Verification requires the TS's public key(s), the trust anchors for Issuers the Relying Party accepts, and the Relying Party's own lists of accepted Agent Registration Authorities, Agent Assurance Assessors, levels and suites, and of the Supervisory Authority designated for each accepted scheme, all obtained out of band. No network access is required. A verifier that does not perform a step MUST NOT report PASS, and input that is malformed at any step fails that step rather than leaving the result undefined.¶

1. For every Transparent Statement in key 1, verify every Receipt in its receipts header (label 394) per Section 5.2.1 of [RFC9942] against a trusted TS key, confirming that the Signed Statement is included in the VDS. On failure: E_RECEIPT_SIG.¶

2. For every Transparent Statement, verify the Issuer's COSE signature per [RFC9052] against an Issuer key reached from a trust anchor. On failure: E_ISSUER_SIG.¶

3. For every Transparent Statement, check that the aee_type claim, the content type and key 1 of the payload agree and that the payload is well-formed. On failure: E_TYPE_MISMATCH.¶

4. Identify exactly one Agent Credential or Serving Party Credential Statement whose Issuer the Relying Party accepts and whose identifiers include the agent_id of the first receipt in key 2. Check that no Revocation Statement in the Bundle, from the same Issuer, names its payload digest. On failure: E_CREDENTIAL. For an Agent Credential, identify the Agent Registration Statement named by registration_digest, and check that its Issuer is an accepted Agent Registration Authority, that the domain of its logical_agent_id matches that Issuer (Section 3), that its logical_agent_id and responsible_entity equal the credential's, that its validity contains every receipt's ts, that any status it carries is 0x00 in the Status List Token in key 4 as of that token's snapshot, that no Revocation Statement from its Issuer names it, and that any provider_statement_digest in the credential is among its provider_statement_digests. On failure: E_REGISTRATION.¶

5. For each receipt in key 2, check that its agent_id appears, with valid_from <= ts < valid_until, in the runtime_identities of the credential or of the Sub-agent named by the receipt's subagent, or equals the service_id of a Serving Party Credential. On failure: E_RUNTIME_IDENTITY.¶

6. For each receipt in key 2, in ascending seq: check that seq is one greater than the preceding receipt's (or that the segment starts at a boundary stated by an Execution Epoch Statement), and that prev_hash equals the record-hash of the preceding receipt (or, for the first receipt, the first_prev_hash of its epoch, or 32 zero octets at seq 0). On failure: E_CHAIN_GAP or E_CHAIN_HASH.¶

7. For each receipt, locate the Execution Epoch Statement whose [first_seq, last_seq] contains its seq, or its individual Transparent Statement. If the whole epoch is present in key 2, recompute epoch_root and compare. Otherwise verify the inclusion path from key 3 against epoch_root. Check that consecutive epochs are continuous (first_prev_hash equals the previous last_hash). On failure: E_EPOCH_ROOT.¶

8. For each receipt with parent_seq: check that parent_seq < seq, that the referenced receipt is present in key 2, and that its record_type is the one required by Section 6.7. For each tool_result, check that a tool_call parent exists and is the parent of no other tool_result. On failure: E_PARENT_SEQ or E_PARENT_TYPE. Check the Task rules of Section 6.7.1 for every receipt whose Task's task_start is in key 2. Check that every confirm_seq names an earlier confirm receipt in key 2 with the same parent_seq, target, request_digest and Task, and that each confirm has at most one outcome. A confirm without an outcome in key 2 fails only if its Task's task_end is in key 2, or a later receipt of that Task names the confirm receipt as its parent; otherwise the call is reported as not proceeded, which does not prevent PASS. On failure of the Task rules or of confirm/outcome pairing: E_TASK.¶

9. For each receipt, check that ts is within the validity of the credential identified in step 4 and is not less than the preceding receipt's ts. On failure: E_KEY_CURRENCY.¶

10. For each receipt carrying agent_sig, verify the COSE_Sign1 over the canonical encoding of the receipt without key 15, with the subagent_key of the Sub-agent named by subagent where one is listed, otherwise with the agent_key of the Agent Credential Statement or the service_key of the Serving Party Credential Statement. On failure: E_AGENT_SIG.¶

11. For each distinct policy_pack_digest in key 2, locate the Policy Pack Statement and walk parent_pack_digest to a root. Every pack on the path MUST be present as a Transparent Statement, layers MUST strictly increase from root to leaf, and the walk MUST terminate. On failure: E_POLICY_UNREGISTERED or E_POLICY_LINEAGE.¶

12. For each distinct config_integrity_digest in key 2, locate the Configuration Integrity Statement, recompute config_digest from entries, and check that the TS registration of that statement precedes, in the VDS, the registration of each receipt that references it, or of the Execution Epoch Statement that contains that receipt. Where the VDS exposes leaf indices through the inclusion proof, as RFC9162_SHA256 does, precedence is established by comparing them. On failure: E_CONFIG_UNREGISTERED or E_CONFIG_PRECEDENCE.¶

13. If the Relying Party requires assurance: for each (credential, pack, config) triple observed in key 2, locate an Assurance Statement whose assessor equals its protected iss, from an accepted Agent Assurance Assessor and suite, with result pass, sufficient operational assurance level, matching logical_agent_id and digests, and validity containing every receipt timestamp in that triple. Check the declared purpose and capability scope against policy. Check that its capability_profile_digest equals the registration's. At levels 3 and 4, require an accepted Third-Party Agent Assurance Assessor and independence_declaration_digest, and, where the registered responsible_entity is an organization, check that the assessor's identifier differs from it. Where a monitoring summary is present, require its disposition to be continue. For higher-risk agents, also require level 4 and a monitoring summary whose required coverage is accepted, and whose period_end is no more than review_frequency before each receipt time after conversion to seconds. On failure: E_ASSURANCE_BINDING, E_SCOPE_MISMATCH or E_MONITORING_STALE.¶

14. For each Assurance Statement relied upon: if it carries status, evaluate it against the Status List Token in key 4, verifying the token's signature and iat and, where a Supervisory Authority is designated for its scheme, that the token was issued by it. Require status 0x00; status 0x03 (RESTRICTED) is accepted only for receipts whose operations the Relying Party's policy places within the scheme's restricted class. In any case, require that no Revocation Statement from its Issuer or from the designated Supervisory Authority names its payload digest. On failure: E_ASSURANCE_STATUS or E_RESTRICTED.¶

15. For each receipt carrying subagent, check that subagent_ref and function match an entry of the governing Agent Credential Statement. For each delegated Task whose task_start is in key 2, check the rules for delegated Tasks in Section 6.7.1. On failure: E_SUBAGENT.¶

16. For each admission receipt, check that decision_point is ingress, that decision is allow or block, that every allow carries caller_agent_id, that the last entry of actor_chain, if present, equals caller_agent_id, and, if the Relying Party requires that the Serving Party enforce assurance, that every allow carries admission_basis with assurance_statement_digest, assurance_level and registration_digest. On failure: E_ADMISSION.¶

17. For each principal carrying a delegation_ref with status, evaluate it against the Status List Token in key 4 and require 0x00 as of that token's snapshot. On failure: E_DELEGATION_STATUS.¶

18. If all steps succeed, the result is PASS.¶

10. Privacy Considerations

No content:

Execution Receipts carry digests of requests and responses, never their content. Model prompts and tool arguments routinely contain personal data; the design keeps that data in the operator's custody and places only commitments on the TS.¶

Principal hashing:

A natural-person Principal, and a natural-person responsible_entity, is represented by SHA-256 over a pepper held by the statement's Issuer and the identifier. The pepper MUST be at least 16 octets of entropy, MUST NOT be registered on the TS, and SHOULD be rotated per deployment. The same Principal is linkable across receipts of one deployment by design, and not across deployments with different peppers.¶

Linking across parties:

principal_link lets the two parties to one call show that they recorded the same Principal without either revealing it, because it is a digest of a token both already hold. It does not link the Principal across calls unless the same token is presented again. txn and actor_chain correlate all hops of one transaction and reveal which operators' agents took part; parties SHOULD forward them only to the parties they call, and a Serving Party SHOULD register epoch roots rather than individual admission receipts. caller_ref reveals the caller's Evidence Service to the Serving Party.¶

Registration and principal assurance:

An Agent Registration Authority can link all agents of one Responsible Entity. Resolving a did:web identifier live tells the authority which agent is being checked and by whom; verifiers SHOULD rely on the registered statement in the Bundle instead. principal_assurance reveals how a Principal was verified, which can indicate residence or nationality; it SHOULD be carried only where a Serving Party's policy requires it.¶

Data minimization:

target and egress_host are the only free-text members of a receipt and MUST NOT contain query, user, argument or parameter-value components; a tool name derived from an HTTP operation MAY carry its method and path template. Issuers MUST NOT place Principal identifiers or content in identifiers. Purpose, objective, intended-use and risk-tier strings SHOULD use concise categories or URIs rather than sensitive operational detail.¶

Retention:

Statements registered on a TS cannot be removed. Operators SHOULD prefer registering epoch roots, which reveal only counts and digests, over individual receipts.¶

Jurisdictional packs:

A Policy Pack at the jurisdiction or sector layer MUST NOT require that Execution Receipts identify natural persons in clear text.¶

Transparency Service visibility:

A TS sees the protected header of every statement: Issuer, agent identifier, type and key identifier. Operators for whom the existence of an agent is sensitive SHOULD use opaque identifiers under their own trust domain.¶

11. Security Considerations

The security considerations of [RFC9943] and [RFC9942] apply.¶

Replay:

A receipt is bound by prev_hash to its position and by agent_id and ts to its credential. Replaying it into another chain fails at step 6 of Section 9; replaying it in the same chain fails because seq cannot repeat.¶

Equivocation:

An operator who shows different chains to different Relying Parties is detected because both must be sealed into the same non-equivocating VDS (Section 5.1.3 of [RFC9943]), and the continuity check in Section 7 refuses the second epoch. This profile relies on the VDS properties and adds nothing to them.¶

Omission:

A Harness that does not produce a receipt for a call leaves no trace. Mitigation is outside the chain: attestation of the Harness (Section 9), independent recording at the Serving Party by admission receipts (Section 6.7.2), and reconciliation of egress receipts against network telemetry. A call recorded by one party and not by the other is reported by Linked Verification when both chains are present; neither party can remove the other's record.¶

Confused deputy:

An agent serving several Principals can be induced to use one Principal's authority for another's request. Recording the Principal on every receipt of a Task, carrying the Actor Chain, and requiring a Serving Party to evaluate every Actor (Section 6.7.2) make the substitution visible and let the Serving Party refuse it; they do not prevent an agent from misusing authority it legitimately holds.¶

Forged or replayed caller references:

A caller_ref, actor_chain or principal_link received with a call is the caller's claim until checked against the caller's registered chain. A forged reference fails Linked Verification; a replayed one names a caller receipt that another admission already names, which is detected when both admissions are in the same Linked Bundle. Actors removed from or inserted into the chain are detected when the chains of all hops are verified together.¶

Status freshness at admission:

An admission decision based on a token or status list older than the suspension of the agent admits a suspended agent. A Serving Party bounds this by the freshness its policy requires and SHOULD check the status list itself for operations its policy marks as high-risk.¶

Flooding a Serving Party:

Because a Serving Party records every call, including refusals, a caller can inflate its records. Serving Parties SHOULD rate-limit before the Ingress Decision Point; a call dropped there is not received and produces no receipt.¶

Memory poisoning:

memory_digest makes changes to memory between Tasks visible after the fact; it does not prevent poisoned memory from influencing the next Task. A Policy Pack MAY require review of memory changes between Tasks for higher-risk agents.¶

Fail-closed evaluation:

A Decision Point that cannot evaluate a call MUST NOT let it proceed: for example an input over a size limit, a request it cannot parse, a response item it does not recognise, or an Evidence Service that cannot be reached. It MUST NOT evaluate a truncated or repaired form of the input instead. Where the Evidence Service is reachable, the refusal is recorded as block.¶

Result alteration:

response_digest commits to what the Decision Point received, not to what the agent was given. A Harness that rebuilds, truncates or withholds a result before passing it on is not distinguishable from the receipt alone.¶

Key compromise:

Compromise of the Evidence Service key allows forged receipts from the time of compromise; earlier epochs remain protected by the TS's Receipts. Compromise of the agent key allows forged agent_sig values but not forged receipts. Operators MUST register a Revocation Statement on compromise and SHOULD use short validity windows.¶

Identity substitution:

An attacker who obtains a workload identity in some trust domain cannot have receipts under it accepted for a Logical Agent unless the Agent Credential Statement lists that identity for that time (step 5 of Section 9). Issuers SHOULD keep runtime_identities minimal and windows short.¶

Session binding:

The Evidence Service MUST authenticate each Decision Point that submits receipts. An agent session at a Decision Point bound only to a network address protects little, since addresses are shared and change. Sessions SHOULD instead be bound to possession of the agent key, for example with a per-request proof of possession [RFC9449] or a certificate-bound session [RFC8705], so that a captured session identifier is useless without the key.¶

Principal attribution:

The principal in a receipt is asserted by the Evidence Service after it validated the Principal's token; the receipt does not carry a proof. An Evidence Service SHOULD retain, outside the receipt, a digest of each token as presented and of the key set it was verified with, so that an Auditor can repeat the validation. Token lifetime is judged at validation time, not at receipt time, since a Task can outlive the token that opened it; any clock-skew allowance MUST be bounded and stated in the Policy Pack or the Evidence Service's published configuration.¶

Policy downgrade:

Loading a weaker Policy Pack produces receipts naming a different policy_pack_digest; a Relying Party that requires a specific root pack detects this at step 11. A Relying Party SHOULD reject chains whose policy_pack_digest changes within a Task.¶

Configuration substitution:

The precedence check at step 12 ensures the Configuration Integrity Statement predates the receipts. The Harness MUST compute and compare digests at load time and SHOULD re-check them at a bounded interval during a run; a mismatch MUST produce a Configuration Drift Statement and a new Configuration Integrity Statement before any further receipt. Blocking calls to tools absent from the committed tool manifest (Section 6.6) prevents a tool server from evading the commitment by not listing a tool.¶

Domain allowlist exfiltration:

Allowing egress to a list of trusted hosts does not stop exfiltration to an attacker-controlled account on an allowed host, or through path and query components. A receipt that records only decision: allow does not help an investigator. This profile therefore requires egress_host in egress receipts and request_digest over the full request, so that which host received data in which call is answerable from evidence rather than from the operator's account. It does not prevent the exfiltration.¶

Unicode-based injection:

The rule in Section 6.6.1 makes invisible code points either irrelevant to the digest (profile 1) or a rejection (profile 2). It does not detect injection through visible but misleading text, homoglyphs, or content loaded at runtime outside the configuration set.¶

Assessment independence:

Level 1 can be self-asserted. At level 2, the Agent Assurance Assessor can still be the Responsible Entity, but accepted RATS Evidence adds technical runtime evidence. Levels 3 and 4 require a Third-Party Agent Assurance Assessor because an operator assessing controls it designed can share their assumptions and blind spots. The presence of an independence declaration is checkable, and identifier separation for an organization is only a weak signal; organizational independence, competence and accreditation are not established by this protocol.¶

Supervisory and registration authorities:

Compromise of a Supervisory Authority's or Agent Registration Authority's key allows agents under it to be suspended, restricted or closed, or unregistered agents to appear registered. Relying Parties accept each authority only for the schemes or namespaces it is designated for, and the domain-match rule of Section 3 prevents one authority from issuing identifiers in another's namespace.¶

Transfer without reassessment:

A change of Responsible Entity produces a new registration and requires reassessment (Section 4). lineage_id lets an authority keep a history of adverse findings linked to the agent; it cannot prevent re-registration with another authority that does not share that history.¶

Sub-agents:

A Sub-agent without its own key signs as its parent, so its compromise is its parent's. A Sub-agent not listed in the credential fails verification; whether its declared function is within the Capability Profile is checked by the assessor, not by the verifier.¶

Key binding:

An assurance level and the protection of the credential key are independent. An agent assessed at level 4 whose key is held in software can be impersonated by any process that copies the key, and its records then carry that level. Relying Parties MUST NOT infer key protection from the level.¶

Monitoring limits:

Monitoring detects only deviations visible in its declared coverage. An agent can behave maliciously within an approved scope, evade an instrumented Decision Point, or exploit a control that is present but ineffective. Relying Parties MUST evaluate coverage, evidence sources, review frequency and control enforcement rather than treating level 4 as a guarantee of safe behaviour.¶

Limits:

This profile produces evidence about calls that pass through Decision Points. Behaviour entirely inside the model, inside a tool, or through a channel the Harness does not mediate is not recorded.¶

12. IANA Considerations

13. Related Work

This section states what each related document covers and how this profile composes with it. The intent is to coordinate, not to replace.¶

WIMSE AIMS [I-D.ietf-wimse-aims]:

Identity management functions and minimum audit fields for agents. This profile supplies the evidence format AIMS leaves open; [I-D.thaha-wimse-agent-evidence-binding] maps the AIMS fields to the Execution Receipt and proposes a credential claim pointing at the Evidence Service.¶

RATS [RFC9334] and EAT [RFC9711]:

RATS supplies roles and procedures for technical attestation, and EAT can convey claims about a measured runtime. This profile can bind that evidence to an identity or operational assurance claim, but does not replace RATS appraisal or turn runtime integrity into a behavioural guarantee.¶

Standards boundaries:

SCITT provides statement transparency, WIMSE provides workload identity, and RATS provides technical attestation and the Verifier role. None defines a Third-Party Agent Assurance Assessor, a universal agent risk classification, a capability-audit method, or assessor qualification and accreditation criteria. This profile defines the assessor role and carries the identifiers, commitments and results needed for interoperability, while leaving recognition and accreditation to relying-party policy, applicable external governance, and possible future work coordinated across the relevant communities.¶

Audit architecture [I-D.kuehlewind-audit-architecture]:

Roles and four record types (Interaction, Action, Delegation, Authorization Transition). The Execution Receipt is an Action Record at the Harness vantage, and the admission receipt is the corresponding record at the serving side; this profile is a candidate for that document's WI-3. A Delegation record composes with actor_chain and delegation_ref.¶

OAuth Token Exchange [RFC8693], Transaction Tokens [I-D.ietf-oauth-transaction-tokens] and Identity and Authorization Chaining [I-D.ietf-oauth-identity-chaining]:

Token Exchange expresses a chain of delegation by nested act claims; this profile records it as actor_chain and, unlike that specification, requires a Serving Party to evaluate prior actors. Transaction Tokens propagate the principal of the transaction and a txn identifier along a Call Chain within one Trust Domain; this profile records txn on both sides of every call and extends the Call Chain across Trust Domains. Identity and Authorization Chaining carries identity across Trust Domains and leaves the format of transcribed claims open; the Actor Chain is one concrete record of what it carries. This profile complements these specifications with evidence and does not change them.¶

Agent audit record [I-D.gilda-wimse-agent-audit-record]:

A JCS-canonicalized in-toto Statement in a DSSE envelope, richer per event and oriented to authorization decisions. [I-D.thaha-wimse-agent-evidence-binding] defines an in-toto [IN-TOTO] predicate type for Execution Receipts, and an audit record's correlation.externalAnchor of kind transparency-log can point at the SCITT Receipt of the enclosing epoch.¶

Agent Action Capsule [I-D.mih-scitt-agent-action-capsule]:

A JSON Capsule per action with disposition and an Effect Record, registered by Capsule ID. Its may/did distinction is finer than decision plus tool_result; a Capsule ID can be the request_digest of a tool_call receipt. This profile defers effect tracking to the Capsule.¶

AI-Agent Action Receipts [I-D.noa-scitt-ai-agent-receipt]:

JCS JSON receipts with Ed25519 signatures, a principal class, a lifecycle verdict and hash chaining. This profile shares that posture and adds credential, configuration and assurance statements and epochs. Alignment of verdict vocabularies is desirable.¶

Execution Profile [I-D.emirdag-scitt-ai-agent-execution]:

The AgentInteractionRecord with inputs, outputs, reasoning traces and redaction receipts, and the same SCITT role mapping as here. This profile excludes content from statements; an AIR can be the retained content whose digest appears in a receipt.¶

Agent Passport System [I-D.pidlisnyi-aps] and Agent Audit Trail [I-D.sharif-agent-audit-trail]:

A broad authority-and-evidence framework and a logging format respectively. This profile could serve as the evidence layer of the former and commits to entries of the latter by digest; no dependency is created.¶

AP2 Mandates [AP2]:

User-signed credentials expressing purchase authorization. A Mandate is an input to a tool_call; its digest belongs in request_digest, and the confirmation it embodies corresponds to decision confirm.¶

14. Open Issues

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

• Delegation scope: a mechanical test that a delegated Task's, or a later Actor's, effective scope is no wider than its parent's needs a common representation of scopes (Section 6.7.1, Section 6.7.2).¶

• Supervisory Decision statement: a statement by which a Supervisory Authority grants, restricts, suspends, restores or withdraws assurance.¶

• Trust List statement: a statement by which a Supervisory Authority registers the assessors, schemes and foreign authorities it accepts.¶

• Registering RESTRICTED in the OAuth Status Types registry instead of using the application-specific value 0x03.¶

• A registry of record types, so that other profiles can extend them.¶

• A reputation statement linked through lineage_id, and whether identifier forms other than did:web should be allowed for logical_agent_id.¶

• Whether Serving Parties should also be registered by an authority.¶

15. Implementation Status

This section records the status of known implementations per [RFC7942] and is to be removed before publication as an RFC.¶

Sijil's record model is the basis of the Execution Receipt; no export to the encoding defined here exists yet. Implemented: Harness-side Decision Points (model and tool doors); a hash-chained, signed record of every call, with Tasks, refusals and separately recorded approvals; and an offline verifier that checks the chain, the Task rules, and declared runtime identities with agent registration, key rotation proofs and revocation. Not implemented: COSE wrapping, epochs, Bundles, registration through [I-D.ietf-scitt-scrapi], per-call agent_sig, validity-window identity checks, Assurance Statement checks, Principal peppering, and everything this revision adds: Agent Registration, Model Provider and Serving Party Credential Statements, Sub-agent records, memory_digest, Supervisory Authority status, admission receipts, linking across calls and Linked Verification. A separate script generates the vectors in Appendix A. Maturity: prototype. Licence: verifier, agent guard and rule packs Apache 2.0; other components Business Source License 1.1. Contact: see Authors' Addresses.¶

16. References

Appendix A. Test Vectors

The vectors below were generated with a script included in the repository named in the document header. Keys are Ed25519 (COSE alg -8, EdDSA, [RFC9053]). Diagnostic notation shows maps in the order written; the canonical encoding sorts keys as required by Section 4.2.1 of [RFC8949], and the hashes and signatures are over that canonical encoding. The CWT claim aee_type uses its text-string key pending assignment of TBD1.¶

{
  1: 9,
  2: "did:web:register.example:agent:billing-assistant",
  3: {1: 2, 2: "acme-finance.example"},
  4: "lineage-7f3c2a",
  5: [-16, h'a8e360e1532afc9025ff475f5a5f4d96
             e99586a1955e7cdd6b6d0b22a338a0e7'],
  6: [],
  7: {1: 1790000000, 2: 1824128000}
}

{
  1: 1,
  2: "wimse://agents.example.com/agent/billing-assistant",
  3: {1: 1, 3: -8, -1: 6,
      -2: h'a09aa5f47a6759802ff955f8dc2d2a14
         a5c99d23be97f864127ff9383455a4f0'},
  4: {1: 1,
      2: h'355acb442721073848a4b78577b31cd2
         958587696cf8378ab050011c8a042638'},
  5: {1: "example-harness", 2: "3.2.0"},
  6: {1: 2, 3: "example-model-2026-06", 4: "model-provider.example"},
  7: {1: 1790000000, 2: 1792592000},
  9: "did:web:register.example:agent:billing-assistant",
  10: {1: 2, 2: "acme-finance.example"},
  11: [
    {1: "wimse://agents.example.com/agent/billing-assistant", 2: 1,
     3: "agents.example.com", 4: 1790000000, 5: 1792592000},
    {1: "spiffe://prod.example.net/ns/finance/sa/billing", 2: 2,
     3: "prod.example.net", 4: 1790000000, 5: 1792592000}
  ],
  12: 2,
  13: [-16, h'f994b20f8c780fcd2b2981784c79e1af
              a1591a1a33d2a9ce90739b0d622716ec']
}

INSTRUCTIONS.md         2  b7151d3ad953353923932e171b27567b
                           a78524f13ba853e6c912ea3d43653610
SYSTEM_PROMPT           1  fe6ff403a894e40e32eacf012889e4bf
                           1cc74be70216ceb8250cf3419f6434ff
tools/send_invoice.json 6  1c9c542a99e6804c6ce08d17c38fa2f3
                           068507cf2c6f7d97a092e111a1651707
config_digest              654e7b4e605a07c8657d5f2c01360d23
                           67022d18a2ee2dfce1a6489e1c6b6781

{
  1: 5, 2: 2,
  3: h'3d3b1f63cb07c710049eed093e439600
       464a47a36b37175372e1fc734f6d39a9',
  4: 4, 5: 1, 6: 3,
  7: [-16, h'563a0a3a0c09b773b7f07dd66931dc56
             605cb0e56d53d1da9cdefe6ae4c56f4d'],
  8: [-16, h'654e7b4e605a07c8657d5f2c01360d23
             67022d18a2ee2dfce1a6489e1c6b6781'],
  9: "wimse://agents.example.com/agent/billing-assistant",
  10: {1: 1,
       2: h'355acb442721073848a4b78577b31cd2
            958587696cf8378ab050011c8a042638'},
  11: 0,
  12: [-16, h'989a658a232f0329b3372261bdd4d3be
              c9e31d57094015433bf54fbd2aeca8f5'],
  14: 1790001000350,
  15: h'...',   / COSE_Sign1, 226 octets, see below /
  16: "send_invoice",
  17: "api.customer.example",
  18: 2
}

{
  1: 5, 2: 0, 3: h'00...00',   / 32 zero octets /
  4: 7, 6: 1,
  7: [-16, h'5b582ac36c7eb1ee98d6be83fe7594a8
             0ae9c11d65a4da796810897772123dce'],
  8: [-16, h'db4faed7cf5ef7b1127006d60afda3d4
             7e4970f7f89baf37eb233ec665dc6c68'],
  9: "https://api.customer.example",
  10: {1: 1,
       2: h'461e46747b2b36f5a21c8ef5d0526c9d
            4c8b8d4d561b92ed4cef35f80b14f3f0'},
  11: 0,
  12: [-16, h'989a658a232f0329b3372261bdd4d3be
              c9e31d57094015433bf54fbd2aeca8f5'],
  14: 1790001009050,
  16: "POST /invoices",
  18: 4,
  20: "wimse://agents.example.com/agent/billing-assistant",
  21: {1: "https://harness.example/issuer", 2: 3,
       3: h'1b68ca2bcc5f4814ce870f75419b79d8
            f66b51e13df185ca41cf371c31ab1bf3'},
  22: {3: 1790001009, 4: 0,
       5: [-16, h'f994b20f8c780fcd2b2981784c79e1af
                  a1591a1a33d2a9ce90739b0d622716ec'],
       6: [-16, h'1c8ec66d31e2260b8ebe9e7c602773d0
                  b7b8803689e8a935c3d7d22002cd813d']},
  23: ["wimse://agents.example.com/agent/billing-assistant"],
  24: h'1c8ec66d31e2260b8ebe9e7c602773d0
        b7b8803689e8a935c3d7d22002cd813d',
  25: "txn-0001"
}

Appendix B. Mapping to Regulatory and Standards Contexts

This informative mapping does not claim compliance. Execution Receipts, Evidence Chains and TS registration relate to Article 12 event recording under [EUAIACT]; confirm, block and the policy per receipt relate to Article 14 oversight. The open format relates to pillar 2 of [NIST-AASI].¶

Acknowledgements

The authors thank the SCITT, WIMSE and RATS communities and the authors cited in Section 13.¶

Authors' Addresses