]> Action State Group, Inc.

spec@actionstate.ai

Security SCITT SCITT AI agent transparency audit verdict This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest-committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in-the-loop flag. Capsules are expressed as SCITT Signed Statements (COSE_Sign1) and made transparent by registration in a SCITT Transparency Service. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Note to Readers This document is an individual submission. The intended venue for discussion is the SCITT Working Group (scitt@ietf.org).

Introduction AI agents increasingly take actions with external consequences: writing records, sending payments, filing documents. Two distinct evidentiary questions follow. The question "was this action permitted?" is answered by authorization records produced before execution. The question this profile answers is different: "what did the agent actually do?" — including the cases where the answer is "it was stopped." This document profiles SCITT Signed Statements to carry an Agent Action Capsule: a digest-committed record of one agent action and its verdict-level disposition. The profile's central design commitments are:

1. The may/did distinction. A Capsule records what occurred, with an effect-state binding () that structurally distinguishes "the effect was dispatched" from "the effect's result was observed and bound." A producer cannot present an attempt as a completion.
2. A Capsule on every verdict (). Capsules are recorded for refusals, blocks, errors, and timeouts — not only for executed effects. An evidence trail that records only successes is survivorship-biased and cannot prove its gates ever fired.
3. Independent verifiability. The substrate guarantees (envelope signature, registration, receipt) are SCITT's and are verified by reference; the agent-domain checks defined here (, ) are deterministic and reproducible by any verifier from the record's own bytes, in two conformance classes ().

The terms "statement profile" and "profile" in this document always mean a SCITT statement profile in the sense of : a constraint on the protected header and payload of a Signed Statement. The word is never used in any other sense in this document.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Capsule:

The Agent Action Capsule — the JSON payload of a profiled Signed Statement, recording one agent action.

Verdict:

The terminal outcome of one agent action — what the decision gate concluded and what is consequently known about the effect.

Disposition:

The digest-committed block within a Capsule recording how the decision was disposed: the gate outcome, who disposed it, an honest human-in-the-loop flag, and optionally a verdict reason-class.

Producer:

The party that constructs, signs, and (for the transparent tier) registers Capsules.

Verifier:

Any party that validates a Capsule from its bytes, without trusting the Producer. Verifier conformance is split into two classes ().

This profile computes every digest using the jcs-n algorithm of exclusively. The canonical form, normalization rules, monetary/quantity decimal-string requirement, and float prohibition for jcs-n are defined in that document; this profile MUST NOT restate or alter them.

The SCITT Signed Statement envelope

Protected header and payload media type A Capsule is carried as the payload of a SCITT Signed Statement — a COSE_Sign1 (a CBOR structure, ). The protected header MUST carry the CWT Claims parameter (label 15) with:

Claim	Req	Meaning
iss (CWT 1)	REQUIRED	The signing agent identity (the Capsule's developer).
sub (CWT 2)	REQUIRED	urn:agent-action-capsule:OPERATOR:ACTION_ID — the tenant-scoped action subject (provisional URN namespace; see below).
capsule_statement_type	REQUIRED	"agent_action" or "outcome". Additional values are reserved ().
capsule_action_type	RECOMMENDED	"fyi" or "decide" — lets a registration policy gate by action class without parsing the payload.
capsule_decision_id	RECOMMENDED	Correlates the statements of one decision (and its outcomes) at the SCITT layer.

plus alg, kid, and content_type per COSE. The content_type MUST be application/agent-action-capsule+json (or the outcome media type, ). The capsule_* protected-header claim set is CLOSED: extensions are payload-only (). The capsule_* claim labels are provisional string-keyed names pending registration in the existing IANA "CWT Claims" registry; a future revision pins integer labels. The urn:agent-action-capsule: namespace of the sub claim is likewise provisional and used here by example; a future revision either registers a formal URN namespace () or replaces it with a profile-defined subject scheme. A plain structured-string subject (no URN form) is under consideration for that revision, since the CWT sub claim does not require URN syntax; the choice is deferred to avoid churning the protected-header subject format in this revision. The envelope-discipline principle governing protected-header claim placement is defined in 's Envelope Conventions section and is instantiated by the closed capsule_* claim set above.

Issuer Binding A Capsule's iss claim (CWT protected header) identifies the producer. Registration policies SHOULD authenticate that the signing key belongs to the claimed issuer; three supported binding patterns exist:

1. did:web — iss is a DID URI; the verifier resolves it at verification time to obtain the current signing key. Handles rotation without pinning a certificate.
2. x5chain — an X.509 certificate chain in the COSE x5chain protected header; the leaf's public key MUST match the signing key; the chain is anchored to a configured CA trust root.
3. SPIFFE SVID — a variant of x5chain in which the leaf MUST carry a SPIFFE ID URI in its Subject Alternative Name; iss MUST equal that SPIFFE ID URI. Trust anchor is a SPIFFE trust bundle. Rotation is SPIRE-managed; the SPIFFE ID persists across certificate renewals.

A Capsule whose signing key is a bare, unresolvable kid with no x5chain and no resolvable DID maps to a degraded assurance grade in the producing registration policy; this state MUST be reported, not silenced. The reference anchor (anchor.agentactioncapsule.org) runs an open registration policy and does not enforce issuer binding; production deployments SHOULD enforce at least one of the patterns above. No cross-pattern substitution is valid: a did:web resolution result does not satisfy x5chain trust-chain verification, and neither satisfies SPIFFE trust-bundle verification.

Registration and Receipts A producer makes a Capsule transparent by registering its Signed Statement with a SCITT Transparency Service per and attaching the returned Receipt (COSE Receipts, ) to the unprotected header, forming a Transparent Statement. This profile does not define receipt formats or proof verification; both are the substrate's, by reference. A verifier MUST NOT report attestation_mode: "anchored" without having verified a Receipt from a Transparency Service whose key it trusts. A conforming anchor is any SCITT Transparency Service; this profile requires no specific operator. The transport of registration requests is likewise out of scope: defines a reference registration API, and a Transparency Service may employ a receipt profile such as ; this profile is indifferent to both choices. Statement-to-Receipt Binding, VDS-agnosticism, and the leaf construction rule are defined in 's Statement-to-Receipt Binding section (and its Leaf Construction subsection). This profile imposes no VDS requirement; a Capsule submitted to any conforming SCITT Transparency Service produces a valid Transparent Statement, and leaf construction over the derived identifier MUST follow that subsection's rule. An optional unprotected-header discovery parameter mirroring the derived identifier MAY be included per 's Discovery Mirror section.

Outcomes An asynchronously observed consequence — a reversal, dispute, correction, or confirmation — is recorded as its own Signed Statement (capsule_statement_type: "outcome", content type application/agent-action-capsule-outcome+json) whose sub equals the original action's sub. Correlation is by subject and decision id, never by mutating the original statement: the log is append-only and the original is immutable.

Registries of this profile (summary) Six vocabularies of this profile are registry-governed under a Specification Required policy (, Section 4.6): verdict_class, disposition.decision, effect.type, irreversibility_class, effect_attestation, and chain.relation. The registries and their initial contents are defined in , kept at the back of this document per convention. The binding invariant, stated once here and again in : verifiers MUST treat unregistered values as informational and MUST NOT reject a Capsule for carrying one. Registration governs shared meaning, never acceptance. Every registry check in this profile is performable from the Capsule's own bytes and the registry contents alone.

The Agent Action Capsule A Capsule is a JSON object: the envelope that is disclosed and digest-committed. Sensitive content (model reasoning, evaluated evidence, raw tool payloads) is not carried in the envelope; it is committed to by digest only. A Capsule also carries Constraint Records — the public verdicts of the deterministic checks that ran against the action; their detail is specified in .

Identity and parties

Field	Type	Req	Meaning
spec_version	string	REQUIRED	The profile prose version the Capsule conforms to. The value defined by this profile version is "draft-mih-scitt-agent-action-capsule-03"; it tracks the document name and advances with each revision.
format_version	string	REQUIRED	The serialization-suite version of the envelope. The value defined by this profile version is "2"; the value reflects the pre-IETF reference-implementation serialization lineage this profile inherits, which is why a -00 document begins at "2" rather than "1".
capsule_id	string (64 hex)	REQUIRED	The CPB derived identifier, exclusion set {capsule_id, chain}, per 's Derived Identifier section. Verifiers MUST recompute; carried values MUST NOT be trusted.
action_id	string	REQUIRED	Stable identifier of the action; unique within one producer ledger.
action_type	string	REQUIRED	"fyi" (informational) or "decide" (a disposition was required).
operator	string	REQUIRED	The accountable tenant the action was performed for.
developer	string	REQUIRED	The agent identity and version that performed the action.
timestamp	string	REQUIRED	UTC with "Z" suffix.
epoch_id	string	OPTIONAL	An operator-assigned epoch identifier, stable within one operational configuration of the agent system. Producers SHOULD populate this field and rotate its value — together with an epoch-boundary Capsule () — when a configuration change that materially alters agent behavior occurs (for example, a model-version swap, a policy-manifest revision, or a significant constraint-schema change). A verifier or ledger consumer scopes a history window to a specific operational configuration by filtering on operator and epoch_id. Absent epoch_id implies a single, unnamed epoch; a producer MUST NOT back-fill epoch_id on Capsules already sealed.

Monetary and quantity values are subject to the exact-decimal-string requirement of the jcs-n algorithm (; see ).

Configuration epochs A configuration epoch is the contiguous sequence of Capsules produced by one agent configuration — one model version, one policy-manifest version, one runtime variant — before any of those configuration dimensions changes. Epochs exist because a model swap or policy revision is a behavioral discontinuity; without a recorded epoch boundary, pre- and post-change history blend silently and a verifier cannot scope a query to "the current configuration."

The epoch_id field The epoch_id payload field () carries the current epoch identifier. It is committed to capsule_id and is therefore tamper-evident. Producers that operate across multiple epochs SHOULD populate epoch_id and rotate its value on every configuration change. Producers that do not anticipate epoch changes MAY omit it; absent epoch_id implies a single, unnamed epoch. A producer MUST NOT assign the same epoch_id value across a configuration boundary. The invariant "all Capsules sharing an operator and epoch_id were produced under the same configuration" is what makes epoch-scoped history queries meaningful; violating it makes pre- and post-change records indistinguishable by epoch_id alone.

Epoch-boundary Capsules When an epoch opens, a producer SHOULD emit a single epoch-boundary Capsule before resuming normal action recording. An epoch-boundary Capsule is a regular Capsule (no new statement type) with:

• action_type: "fyi" (it is an administrative record, not a decided action);
• the new epoch_id value — the epoch it opens;
• chain.relation: "epoch_opens" linking to the last Capsule produced under the prior epoch (registry-governed, ); and
• a RECOMMENDED model_attestation block () recording the new model and provider, so the transition is commit-addressed and verifiable from the Capsule's own bytes.

An epoch-boundary Capsule MAY additionally carry disposition.verdict_class: "epoch_boundary" (registry-governed, ) and a reason_digest committing to a machine-readable record of what changed — at minimum the prior epoch_id, the new model identity, and the new policy-manifest version — so that a verifier can distinguish a configuration-change record from an ordinary fyi action.

Epoch-scoped verification A verifier scoping a query to a specific epoch filters by operator and epoch_id. An epoch-boundary Capsule carrying chain.relation: "epoch_opens" marks the temporal left edge of that epoch; the next epoch-boundary Capsule whose chain parent lies within this epoch marks its right edge. A verifier SHOULD report, as an informational finding, any action Capsule whose epoch_id differs from the prevailing epoch established by the most recent epoch-boundary Capsule for that operator; such a discrepancy is not a verification failure (an epoch change mid-stream is not structurally non-conforming), but it is evidence that a configuration boundary occurred without a corresponding epoch-boundary Capsule. The chain block is excluded from capsule_id per the exclusion-set discipline of 's Derived Identifier section. The excluded chain block is nonetheless signed within the COSE_Sign1 envelope () along with the rest of the payload, so the chain linkage remains tamper-evident even though it is outside the content-address.

Effect Record and the confirmed-effect binding The Effect Record describes the side effect the action committed. Its status member takes one of five values:

status	Meaning	Binding requirement
planned	Intended, not dispatched.	request_digest and response_digest MUST be absent.
dispatched	Sent; result not observed.	request_digest SHOULD be present; response_digest MUST be absent.
confirmed	Result observed and bound.	response_digest MUST be present and MUST be a jcs-n digest () of the actual response.
failed	Attempted; runtime reported failure (state known).	response_digest, when present, digests the failure response.
reverted	A committed effect was undone.	Correlated via external_ref / decision_id.

The confirmed-effect invariant: a producer MUST NOT emit status: "confirmed" without a response_digest over the actually observed response. A verifier MUST treat confirmed with a missing response_digest as a verification failure. This is the byte-level mechanism behind the may/did distinction: "confirmed" is an observed result, never a promise. The Effect Record also carries the logical type (registry-governed, ), an optional external_ref join key for later outcomes, and an irreversibility_class — an ordered consequence enumeration (two_way, one_way_recoverable, one_way_consequential, one_way_terminal; registry-governed, ). The Effect Record additionally carries effect_attestation: WHO vouches for the effect's execution — the evidence grade of the effect claim. The vocabulary is registry-governed (; Specification Required), seeded with two values:

effect_attestation	Meaning
gate_executed	The commit transited the gate; the engine observed the effect boundary directly.
runtime_claimed	The gate issued a verdict only; the executing runtime asserted completion; the capsule records that claim, not an observation.

Validity is checked against the assurance effect_mode ():

effect_mode	effect_attestation
confirmed	REQUIRED (states WHO confirmed)
dispatched_unconfirmed	REQUIRED
not_applicable	MUST be absent — nothing executed, there is no claim to grade

The planned carve: effect.status: "planned" asserts no execution, so effect_attestation MUST be absent — there is nothing to grade, and a phantom grade would poison grade-based queries. It becomes REQUIRED the moment dispatch occurs. The matrix is total over the effect.status values of . An effect.status of failed (the effect was dispatched and the runtime reported a failure; state known) derives effect_mode: "dispatched_unconfirmed" — the effect was dispatched and its result, though a failure, was not gate-confirmed; therefore effect_attestation is REQUIRED. reverted (a previously-committed effect was undone) likewise derives effect_mode: "dispatched_unconfirmed" and REQUIRES effect_attestation; the underlying committed effect it reverses is correlated separately via external_ref / decision_id (the Effect Record fields, ), not by a distinct effect_mode. So every effect.status other than planned (carved above) and the no-effect case (not_applicable) requires effect_attestation. Consumers MUST treat an unregistered or unrecognized effect_attestation value as no stronger than runtime_claimed; unknown values are informational, never a verification failure, and unknown never grades up. The grade is digest-committed in the Capsule payload and is available to any payload-bearing verifier, which can thereby distinguish gate-observed execution from runtime-claimed execution; promotion of the grade to a protected-header (CWT claim) position is an explicit candidate for a -02 revision, to be decided once real transparency-log consumers exist. This version deliberately claims no header-level visibility for the grade. References to external authorization records carried in the Effect Record (for example, permit receipts per , or machine mandates) are typed digest references per 's Typed Digest References section, with artifact types drawn from the CPB Artifact Type registry. Cross-profile comparability of digest values (comparable only under compatible declared digest contexts; otherwise indeterminate/deny, never equal-looking-hex) follows that document's Cross-Profile Comparability subsection. This profile's own chain.parent_capsule_id, reason_digest, evidence_digest, and external_ref fields are a distinct concept from the typed digest reference above: they are bare intra-profile digests and join keys — a jcs-n digest or an opaque correlation string — not {type, digest_alg, digest} objects citing an external artifact by registered artifact type. They MUST NOT be interpreted as CPB typed digest references. Only the external-authorization references described in this paragraph use the CPB typed-reference mechanism.

Assurance Every Capsule carries an assurance object stating, as independently-rederivable claims: attestation_mode ("self_attested" or "anchored"), effect_mode ("not_applicable", "dispatched_unconfirmed", or "confirmed"), and ledger_mode ("standalone", "chained", or "anchored"). ledger_mode records the custody tier of the record: "standalone" is a lone Capsule (no chain linkage); "chained" is a Capsule whose hash-chain linkage to a predecessor is present and intact; "anchored" is a chained Capsule whose chain root has additionally been committed to an independent transparency log. A verifier rederives ledger_mode from the bytes it can check — "standalone" versus "chained" from the presence and integrity of the hash-chain linkage, and "anchored" only after it verifies an inclusion proof against a trusted log key — and the three tiers are ordered standalone < chained < anchored for overclaim detection. A producer MUST NOT record an assurance mode it did not achieve; a verifier rederives each mode from the evidence present and reports any overclaim.

Cross-party assurance A Capsule's evidentiary weight along the counterparty dimension — how much of a counterparty's own attestation is structurally present in this record — is a fourth, orthogonal claim: assurance.cross_party_rung. It is a new axis, not a new value folded into attestation_mode, for the same reason already gives for keeping verdict_class and effect_mode separate: attestation_mode answers "has this record been committed to an independent transparency log" (log custody); cross_party_rung answers "how much of the counterparty's own signed evidence is bound into this record" (exchange evidence). These are independent facts a producer can hold in any combination — a self_attested record can still be full_bilateral (both parties signed, neither side anchored yet), and an anchored record can still stand on unilateral_fallback evidence alone (a solo attestation that was independently anchored). Folding a countersigned value into attestation_mode would collapse these two facts into one claim and make that combination inexpressible, so this profile keeps them orthogonal. cross_party_rung takes one of three values, ordered unilateral_fallback < acknowledged_receipt < full_bilateral for overclaim detection — the same never-grades-up discipline already applies to attestation_mode, effect_mode, and ledger_mode:

cross_party_rung	Meaning
unilateral_fallback	Only the initiator's own signed half is present; no counterparty evidence, or the counterparty was unreachable or its half did not verify.
acknowledged_receipt	A counterparty reference and correlator are present and well-formed: the counterparty cryptographically acknowledged receipt, but the referenced half carries no substantive co-signed result.
full_bilateral	A counterparty reference and correlator are present and well-formed, and the referenced half is marked as carrying a substantive co-signed result — both parties' evidence is bound to the same exchange.

cross_party_rung is REQUIRED when a cross_party evidence block (below) is present, and both are OPTIONAL on a Capsule with no cross-party exchange. A producer MUST NOT claim a cross_party_rung its evidence does not support. A Class-1 verifier independently rederives the highest rung the cross_party block supports and reports any claim above the derived rung as an assurance_overclaim (), downgrading the reported derived rung to the value the evidence actually supports — the same treatment already gives an overclaimed attestation_mode or ledger_mode. A Capsule that participates in a cross-party exchange carries an OPTIONAL top-level cross_party block:

• initiator_ref (REQUIRED when the block is present): a jcs-n digest () of the initiator's own signed half. A bare intra-profile digest, not a CPB typed digest reference ().
• counterparty_ref (OPTIONAL): a jcs-n digest of the counterparty's signed half. Its absence means no usable counterparty evidence was obtained — the counterparty was unreachable, or its half did not verify at the layer that checked it.
• correlator (REQUIRED when counterparty_ref is present): an opaque profile-native correlation string joining initiator_ref and counterparty_ref to the same exchange — the same kind of "opaque correlation string" primitive external_ref already uses (), not a CPB reference.
• substantive (OPTIONAL boolean, meaningful only when counterparty_ref is present): true only when the counterparty's referenced half carries a substantively co-signed result rather than a bare receipt of the initiator's half.

A verifier derives cross_party_rung from this block's own bytes alone, never by dereferencing the digests it cites: unilateral_fallback when counterparty_ref is absent or malformed; acknowledged_receipt when counterparty_ref and correlator are both present and well-formed but substantive is absent or false; full_bilateral when counterparty_ref and correlator are both present and well-formed and substantive is true. This is a structural check, the same kind already uses to derive "chained" from the mere presence of a well-formed chain block — it does not verify the counterparty's underlying signature itself, which is a substrate concern by reference (), mirroring how this layer never derives anchored. The two-party wire encoding this rung summarizes — the initiator and counterparty attestation halves, their signatures, and the handshake that produces them — is the companion 's concern, not this profile's; this profile carries only the rung claim and the minimal correlation evidence needed to rederive it honestly.

Disposition and the verdict reason-class A Capsule's disposition block records how the decision was disposed:

• decision (REQUIRED): "accept", "reject", "needs_input", or "deferred" (registry-governed, ).
• approver (REQUIRED): a closed enum, exactly "human", "policy", or "counterparty". The value domain is fixed by this specification (not registry-governed); an unknown approver value is not a conforming Capsule. Unlike the registry-governed vocabularies of this document (), approver stays a closed three-member enum after this addition — never a registry an implementation is expected to extend by registration.
• human_disposed (REQUIRED, boolean): the honest in-the-loop flag — true ONLY when a human actually acted. A policy auto-approval is false. human_disposed: true REQUIRES approver: "human"; a producer MUST NOT claim a human disposed what a policy did.
• authority (OPTIONAL): an opaque reference to the authority under which a non-human disposition acted. A conforming Capsule carries at most the reference, never the authority's internal structure.
• verdict_class (OPTIONAL): the terminal-verdict reason-class (). It is RECOMMENDED for any non-executed verdict, where it carries the terminal reason; it is legitimately absent for a clean executed verdict (which has no reason-class, mirroring an absent reason_digest).
• reason_digest (OPTIONAL): a jcs-n digest () of a structured, private reason object — machine-readable members such as the constraint identifier, the threshold, and the observed value; never free prose — so two engines attesting the same refusal produce the same digest. The member is absent (not a digest of an empty object) when a verdict has no reason, such as a clean "executed".
• expiry_policy (OPTIONAL; deferral dispositions only): a digested {ttl_seconds, on_expiry} object — ttl_seconds is an integer count of seconds, never a duration string, and on_expiry is "expired" or "escalated". ttl_seconds is evaluated against the deferral Capsule's registration time — the timestamp field inside the digest commitment — not the Transparency Service receipt time, and not a consumer's local wall clock; a named clock basis is what makes the expiry computation deterministically reproducible, so any verifier derives the same elapsed-time result from the record's own bytes. The deferral's frozen summary is a digest-committed, content-side layer written once at deferral time; it MUST NOT be regenerated.
• approver: "counterparty" (see ) records that a counterparty to a cross-party exchange, rather than this operator's own human or policy, disposed the decision. The honesty invariant above is unaffected: human_disposed: true still REQUIRES approver: "human", so a counterparty disposition is never claimed as human-in-the-loop.

The verdict_class vocabulary verdict_class records WHY the action terminated as it did. The seeded vocabulary (registry-governed, ; unregistered values are informational to a verifier, never a rejection):

verdict_class	Meaning
executed	The action ran.
blocked	A blocking constraint stopped it before dispatch.
hitl_dispatched	Routed to a human operator; awaiting resolution.
denied	An operator or policy refused it before dispatch.
timeout	The decision timed out (see the orthogonality rule).
errored	The action ran and threw; final state unknown.
engine_failure	The engine could not evaluate the action.
deferred	A human elected to postpone the decision; open item.
needs_decision	Evaluation complete; decision required, not yet routed to a decider; open item.
expired	TTL policy on the deferral elapsed; terminal unless superseded by escalation.
escalated	Expiry or policy routed the item to a higher authority; open item at the new authority.
resolved	A terminal decision Capsule closed the chain without executing — the non-executing closure only (see the pairing rule, ).

hitl_dispatched and deferred are sequential states, not synonyms: hitl_dispatched means sent to a decider and awaiting response; deferred means a decider responded "later".

Orthogonality with effect_mode verdict_class (why the verdict) and assurance.effect_mode (what is known about the effect) are independent axes and MUST NOT be folded into one another:

• The pre/post-dispatch distinction lives in effect_mode, not in the class. A timeout before dispatch is verdict_class: "timeout" with effect_mode: "not_applicable"; a timeout after dispatch is verdict_class: "timeout" with effect_mode: "dispatched_unconfirmed". One timeout value covers both.
• errored pairs with effect_mode: "dispatched_unconfirmed" — the effect was dispatched and may have left a partial side effect. not_applicable would falsely assert nothing happened, which is the inverse of attesting an execution that did not occur and equally non-conforming.
• A class that by its kind never dispatches (blocked, hitl_dispatched, denied, engine_failure, deferred, needs_decision, expired, escalated, resolved) REQUIRES the derived effect_mode to be "not_applicable". A verifier reports any other derived mode as an error: an effect attempt contradicts a verdict that claims it never executed.
• The pairing rule: resolved is exclusively the NON-executing closure (decline, waive, recorded-elsewhere) — it pairs with effect_mode: "not_applicable" and an absent effect_attestation. An EXECUTING closure is encoded as verdict_class: "executed" chained supersedes to the deferral () — one valid encoding of "closed with effect", never two.
• The effect status "failed" (ran and returned a clean failure, state known) is distinct from verdict_class: "errored" (ran and threw, state unknown). "failed" is an effect status, never a reason-class.

A Capsule on every verdict A conforming producer MUST record a Capsule for every verdict, whatever its disposition. This requirement is universal over the verdict_class vocabulary — the IANA registry of this document () — and applies to every value later admitted by registration; it is deliberately not stated as an enumerated list, which would go stale the moment Specification Required admits a new value. A refusal or block with no Capsule is invisible to an auditor; a blocked or denied Capsule is auditor-grade evidence that the gate worked: the affirmative, digest-committed record that the constraint or policy fired and the action did not proceed. Recording only successes makes the evidence trail survivorship-biased and the refusal path unverifiable.

Chained Capsules and human-in-the-loop resolution Every Capsule that references a prior Capsule carries a digested chain block: {parent_capsule_id, relation}. The relation vocabulary is registry-governed (; Specification Required), seeded with one value:

relation	Meaning
supersedes	Terminal transition over the parent — resolution, expiry, escalation close or replace the parent's open state.
epoch_opens	Non-terminal: this Capsule opens a new operational epoch. The chain parent is the last Capsule produced under the prior epoch. The opening Capsule carries the new epoch_id (); the prior epoch's last Capsule is the parent.

Single-parent is intentional: a Capsule chains to exactly one parent. Human-in-the-loop resolution is the supersedes relation: a hitl_dispatched Capsule is sealed at dispatch time and is never mutated. When the decision is later resolved, that resolution is a second, linked Capsule carrying its own disposition and chaining to the dispatch Capsule with relation: "supersedes". The dispatch Capsule stays hitl_dispatched forever; resolution state lives only on the resolution Capsule, preserving the append-only model. Concurrent-supersedes rule: the ledger is append-only and totally ordered; the earliest capsule in ledger order with relation=supersedes over a given parent is authoritative; any later supersedes over the same parent is structurally valid but MUST surface as a verification finding. Open-items predicate: an item is open when its Capsule's verdict_class is one of deferred, needs_decision, hitl_dispatched, escalated, or blocked, and no Capsule in the store carries chain.parent_capsule_id equal to its capsule_id with relation: "supersedes".

Class 1 verification Verification has two tiers. Substrate verification — the issuer's COSE_Sign1 signature, and for the transparent tier the Receipt's inclusion proof and Transparency Service signature — is performed by reference to , , and ; this profile does not respecify it. The agent-profile checks below are normative here and constitute Class 1 verification (): every check is performable from the Signed Statement, the Capsule payload, the registry contents (), and — for the chain checks — the producer's store of Capsules; no other input is needed. A verifier MUST return a structured result, never throw; a single ok boolean gates trust in every other reported field; findings are reported in a fixed order.

1. Structural: REQUIRED fields present and typed; no floating-point values in digest-bearing fields.
2. Identity: recompute the CPB derived identifier per 's Derived Identifier section and compare against the carried capsule_id.
3. Confirmed-effect binding: effect.status: "confirmed" without a well-formed response_digest is a failure ().
4. Verdict/effect orthogonality: a never-dispatching verdict_class with a derived effect_mode other than "not_applicable" is a failure (); resolved is in the never-dispatch set per the pairing rule.
5. Effect-attestation matrix: effect_attestation missing where the matrix REQUIRES it, or present where it MUST be absent — including the planned carve — is a failure ().
6. Chain semantics (store-level): a missing chain parent is a failure; concurrent supersedes surface as findings per .
7. Assurance reconciliation: rederive the assurance modes from evidence actually verified; report overclaims.
8. Unknown registry values (verdict_class, decision, effect.type, irreversibility_class, effect_attestation, chain.relation): report as informational findings; MUST NOT reject (). An unknown effect_attestation is additionally graded no stronger than runtime_claimed ().

Disposition honesty is structurally guaranteed, not a live check above. The honesty invariant — human_disposed: true REQUIRES approver: "human" () — is enforced when the disposition is constructed: the typed disposition carrier rejects human_disposed: true paired with any non-human approver, so a violating Capsule cannot be formed or signed at all. A Class 1 verifier therefore does not re-assert it in the enumeration above; like parse- and type-level malformations that a typed record cannot represent, a dishonest disposition is an unrepresentable state rather than a runtime failure mode. A verifier consuming arbitrary bytes not produced by a conforming constructor SHOULD nonetheless assert the invariant defensively against hand-crafted input. The closed approver enum () is likewise structural: an approver value outside {human, policy} is non-conforming by construction and so is absent from the unknown-registry-value reporting of check 8. NOTE (Class 1 test vector, effect-attestation matrix, check 5): a Capsule carrying effect.status: "failed" derives effect_mode: "dispatched_unconfirmed" (); the matrix therefore REQUIRES effect_attestation. A conforming verifier MUST report a check-5 failure for such a Capsule when effect_attestation is absent, and MUST NOT treat the failed status as exempt (only planned is carved, and only not_applicable is the no-effect case). The same expectation holds for effect.status: "reverted", which likewise derives dispatched_unconfirmed. This vector exists to demonstrate the matrix is total over effect.status: the runtime reporting a failure is still a dispatch, and a dispatch that escapes attestation is the precise condition check 5 exists to catch. A verifier MUST NOT consult a model, a clock-dependent heuristic, or network state to decide ok for the checks above. Manifest-dependent verification is Class 2 ().

Conformance: two verifier classes This profile defines two verifier conformance classes. Producer conformance is a single class and is unchanged by this split: a conforming producer emits the same Capsules regardless of which verifier class consumes them.

Class 1 verifier:

Verifies the Signed Statement envelope and the Capsule payload WITHOUT any constraint manifest: substrate verification by reference, the structural and identity checks, the registry vocabularies, the digest recomputations, and the validity matrices (confirmed-effect binding, verdict/effect orthogonality, effect-attestation, chain semantics). The complete Class 1 check set is .

Class 2 verifier:

A Class 1 verifier that additionally performs manifest-aware verification (): constraint evidence-schema checks and manifest-sourced thresholds. Class 2 conformance presupposes access to the producer's constraint manifest and the private evidence its Constraint Records bind; absent those inputs, a Class 2 verifier reports Class 1 results unchanged.

Manifest-dependent material The producer's constraint manifest — the private definition of each constraint's predicate, evidence schema, and thresholds — is not carried in the Capsule. The material in this section depends on it: the detail of Constraint Records and the Class 2 checks. Manifest discovery and authentication are out of scope for this profile; they are expected to be handled via out-of-band tenant configuration or a future discovery mechanism.

Constraint Records A Constraint Record is the public verdict of one deterministic check that ran against the action. It carries only sanitized categories — an id, optional check_type and method labels, a result of "pass" / "fail" / "n/a", severity, a blocking flag recording whether the check actually gated this decision, and an optional evidence_digest (a jcs-n digest, ) binding the verdict to the private evidence the check evaluated. The content a check evaluated MUST NOT appear in the public record; it is bound by digest only. The check's predicate, evidence schema, and thresholds live in the producer's manifest. Every recorded result MUST be the output of a deterministic predicate over disclosed or digest-committed evidence. The live decision path MUST NOT re-prompt a model to make a check pass, and a verifier MUST NOT re-prompt a model to "re-check" one: re-running a non-deterministic check is not verification. Constraint id, check_type, and method values are lowercase snake_case categories. New values follow the namespacing convention of .

Class 2 verification The checks below are manifest-aware: they require the producer's constraint manifest and the private evidence a Constraint Record binds by digest. A Class 2 verifier performs them in addition to the complete Class 1 set (); their results never weaken a Class 1 result — they extend it.

1. Constraint evidence-schema check: for each Constraint Record () carrying an evidence_digest, confirm the bound evidence conforms to the manifest's evidence schema for that constraint id and that the recomputed digest matches; a mismatch is a failure.
2. Threshold checks: confirm that manifest-sourced thresholds were applied as the manifest states.

Extensibility All extension points are payload-only. The protected-header capsule_* claim set is closed by this profile version: a strict Transparency Service registration policy may reject statements bearing header claims it does not recognize, while payload bytes are opaque to it — so a payload-only extension can never make a Capsule unregistrable. A verifier encountering an unrecognized capsule_* header claim MUST still verify and report it as informational; rejection of unknown header claims is a registration-policy prerogative, not a verifier behavior.

Namespacing convention Three vocabularies are deliberately not registry-governed — constraint id/check_type, compliance.framework_tags, and assurance.sources[].kind — because their value space is producer-local by nature. Bare names (no namespace separator) are reserved for the values seeded in this document; any party introducing a new value MUST namespace it with a URI or reverse-DNS prefix (for example, com.example.margin_floor). A bare, unseeded name is non-conforming for a producer; a verifier still treats it as informational.

Selective Disclosure The base confidentiality posture of this profile is whole-envelope: a producer discloses a Capsule by sharing its full payload, or withholds it entirely. Sensitive content not carried in the envelope leaves no on-wire indicator of its existence. This whole-envelope posture is sufficient for the common case where the unit of disclosure is the Capsule as a whole. For cases in which a producer must reveal a subset of payload fields to a verifier while concealing both the values and the existence of unrevealed fields, a per-field selective-disclosure mechanism is needed. This profile reserves an extension point in the Capsule payload for such a mechanism. The intended field-level technique follows the SD-JWT selective-disclosure model — salted-hash commitments over JCS-canonicalized arrays — because the Capsule payload is JSON; it is written to stay aligned with SPICE's SD-CWT (the CBOR sibling) for SCITT-ecosystem consistency. The complete normative profile of this mechanism — including the commitment encoding, disclosure syntax, and verifier checks — is defined in the companion Internet-Draft . That companion is a CPB payload-class document; the mechanism is payload-class-generic. This profile (AAC) retains only the eligibility-policy annex: the declaration of which AAC payload fields are eligible for selective disclosure and which are non-eligible because this profile's own verifier requires their values in clear. Implementations of this profile version MUST NOT generate or interpret selective-disclosure payload structures unless they additionally implement : the extension point is defined only in that companion, and no conformance claim or verification behavior is defined for it in this document.

Related Work Several active individual drafts address adjacent evidence problems for AI agent actions; this profile is complementary to each. defines pre-execution authorization records (Permits) that bind an allow/deny/challenge decision to the request bytes subsequently dispatched. defines Agent Route Origin Authorization (AgentROA), a cryptographic policy-enforcement framework that authorizes agent capability invocations before dispatch through signed policy envelopes and per-hop attestations; like Permits it governs whether an action may proceed (may), complementary to this profile's record of what occurred (did). defines AgentInteractionRecords signed by an agent operator and registered with an independent evidence custodian, with redaction receipts and regulatory mappings. defines a serialization-independent claim set for AI content-refusal audit trails carried in SCITT Signed Statements; the same author's (VeritasChain Protocol) is a SCITT profile for verifiable audit trails in algorithmic trading — a vertical-specific application of the same transparency substrate. , by the same author, is a conformance-tiered Verifiable AI Provenance framework (hash-chaining, signatures, SCITT anchoring, and a completeness invariant) under which the trading profile sits; it shares this profile's SCITT-anchored, third-party-verifiable substrate, framed as a provenance architecture rather than a per-action verdict record. profiles SCITT receipts for the transparency obligations of EU AI Act Article 50. defines session-level Governance Audit Records produced by a governing enforcement component; this profile differs in recording per-action verdicts with effect-state binding rather than session-close summaries. The distinction this profile contributes is verdict-level disposition with effect-state binding: authorization records prove permission was granted (may); Capsules prove what occurred (did) — executed, blocked, denied, errored, or timed out — with a structural binding that prevents an attempt from being presented as a completion, and with refusals recorded as affirmative evidence. defines receiver-attested confidential agent-action receipts registered on a witness-cosigned Merkle log. This profile differs in providing self-and-counterparty bilateral attestation — each party holds proof of the other's commitment — over a SCITT-neutral anchor, with an explicit disposition vocabulary (executed, blocked, denied, timeout, errored, deferred, expired, escalated) that distinguishes outcome categories rather than receiver attestation alone. The companion Internet-Draft profiles the two-party extension. defines composition and conformance rules for multi-agent accountability chains built on the same CPB derived-identifier primitive this profile uses; Capsules chained via and bilaterally attested Capsules compose under those rules. defines on-chain identity, reputation, and validation registries for AI agents on a public blockchain. This profile differs in that payload content is content-private — only digests and timestamps are anchored, never payloads or PII — and the transparency log is off-chain-anchorable to any conforming SCITT service, separating conduct evidence from the on-chain content-public constraint of registry entries. Mastercard Verifiable Intent () records a signed intent-to-act over a checkout-authorization chain. This profile complements it by recording general-purpose conduct, obligation, and refusal verdicts in an agent-to-agent lane, anchored to a neutral transparency log, without being coupled to a specific payment or checkout context. binds a per-action delegation-authorization decision and provenance references into an Agent Action Capsule via namespaced payload extensions that leave the core fields untouched, recording that an action was taken under a stated authorization without asserting the authority. This specification is complementary; the profile is deliberately agnostic to the delegation mechanism, and such bindings compose by shared action digest.

Future Work The companion Internet-Draft defines a bilateral attestation extension in which two parties independently seal Capsules over a shared action digest, each holding proof of the other's commitment. The extension reuses this profile's disposition vocabulary (executed, blocked, denied, timeout, errored, deferred, expired, escalated) and anchors both seals to a conforming SCITT Transparency Service, so a third party trusting neither signatory can verify the record end-to-end. Statement-type and verdict-class values reserved in this document for that extension are governed by the registries in . The companion Internet-Draft normatively profiles the selective-disclosure extension point reserved in , specifying the per-field commitment structure, disclosure syntax, eligible fields, and verifier checks, aligned with .

IANA Considerations

New registries Every registry requested below governs a vocabulary that lives entirely in the Capsule payload — values a SCITT-generic Transparency Service never parses, since registration, inclusion, and Receipt issuance operate on the COSE_Sign1 envelope and its protected header, not on payload content. The registrations this profile requests against existing IANA registries are the capsule_* CWT claims () and the two media types of ; both are addressed separately from the payload-vocabulary registries here. This profile requests no new COSE header parameter registry and no new CWT claim registry; the new registries here are payload-vocabulary registries only. IANA is requested to create a new registry group, "Agent Action Capsule Parameters", containing the six registries below. The registration policy for each is Specification Required (, Section 4.6). Specification Required is chosen deliberately. The threat it answers is a vocabulary value whose meaning is defined only inside a closed product — two verifiers would then disagree on what the value means, and the interoperable, falsifiable-from-the-record property this profile depends on would erode. The mitigation is the policy's publicly-available-spec requirement: a value enters the shared vocabulary only once its semantics are pinned in a specification any implementer can read. Accordingly, for each registry the designated expert approves a registration when (1) the citing specification defines the value's semantics precisely enough that two independent implementations would apply it identically — for verdict_class, including its dispatch consequence and its effect_mode pairing under ; (2) the value's meaning is not already expressible by an existing registered value; and (3) the citing specification is publicly available. Binding invariant for all six registries: verifiers MUST treat unregistered values as informational and MUST NOT reject a Capsule for carrying one. Registration governs shared meaning, never acceptance. Initial contents are the seeded values of this document, verbatim:

1. "verdict_class" registry (): executed, blocked, hitl_dispatched, denied, timeout, errored, engine_failure, deferred, needs_decision, expired, escalated, resolved, epoch_boundary. The deferred token's semantics are OWNED by this registry; the entry of the same spelling in the "disposition.decision" registry is a cross-reference to it. The epoch_boundary token denotes an administrative Capsule (action_type: "fyi") that marks a configuration-epoch transition (); it REQUIRES effect_mode: "not_applicable" (no effect is dispatched by an administrative epoch record).
2. "disposition.decision" registry (): accept, reject, needs_input, deferred. The deferred entry is a cross-reference to the "verdict_class" registry, which owns the token's semantics.
3. "effect.type" registry (): write_order, send_payment.
4. "irreversibility_class" registry (; ordered by ascending consequence — a registration states its position): two_way, one_way_recoverable, one_way_consequential, one_way_terminal.
5. "effect_attestation" registry (): gate_executed, runtime_claimed. The registry definition carries the grade-floor invariant of — an unregistered or unrecognized value is graded no stronger than runtime_claimed; unknown never grades up — and the planned carve of : with effect.status: "planned" the member MUST be absent, and it becomes REQUIRED the moment dispatch occurs. Designated-expert guidance: plausible future registrations exist and are deliberately not seeded — for example, independent sensor confirmation of a claimed effect, or hardware- or TEE-anchored execution; a registration states where its grade sits relative to the seeded values.
6. "chain.relation" registry (): supersedes, epoch_opens. Designated-expert guidance: supersedes is the single terminal relation; epoch_opens is a non-terminal relation for configuration- epoch boundaries (). Additional non-terminal relations (for example, deposit-toward-open and effort-toward-open relations, or amends / contradicts) are expected future registrations, each admitted once its semantics and any verifier consequence are pinned in a publicly available specification.

Interim registry of record: until this document is published as an RFC, the registry of record is the REGISTRY.md file of the source specification repository, seeded with the same initial contents and the same policy; on publication the IANA registries become the registry of record. Change controller: Action State Group, Inc. (interim); the IETF on publication.

No new registry

• Attestation/signature algorithms: this profile defines no algorithm registry; algorithm identifiers are those of the existing IANA "COSE Algorithms" registry ().
• Constraint id/check_type, compliance.framework_tags, and assurance.sources[].kind: no registry; governed by the namespacing convention of .
• The capsule_* CWT claim labels: registration is requested in the existing IANA "CWT Claims" registry (), not in a new registry; the claim set is closed by this profile version.

Media Type Registrations This profile mandates two media types (, ); IANA is requested to register both in the "Media Types" registry per the templates below (, with the +json structured-syntax suffix of ). Agent Action Capsule media type:

• Type name: application
• Subtype name: agent-action-capsule+json
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: binary; the payload is JSON () as defined in this document, carried as the payload of a COSE_Sign1 () Signed Statement.
• Security considerations: see of this document.
• Interoperability considerations: see this document.
• Published specification: this document (and its successors).
• Applications that use this media type: SCITT () producers and verifiers recording and verifying AI agent actions.
• Fragment identifier considerations: as for application/json () per the +json suffix ().
• Additional information: Deprecated alias names: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.
• Person & email address to contact for further information: the author of this document.
• Intended usage: COMMON
• Restrictions on usage: N/A
• Author: see the Authors' Addresses section of this document.
• Change controller: Action State Group, Inc. (interim); the IETF on publication.
• Provisional registration: yes (pending publication of this document).

Agent Action Capsule outcome media type:

• Type name: application
• Subtype name: agent-action-capsule-outcome+json
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: binary; the payload is JSON () as defined in of this document, carried as the payload of a COSE_Sign1 () Signed Statement.
• Security considerations: see of this document.
• Interoperability considerations: see this document.
• Published specification: this document (and its successors).
• Applications that use this media type: SCITT () producers and verifiers recording asynchronous outcomes correlated to an agent action.
• Fragment identifier considerations: as for application/json () per the +json suffix ().
• Additional information: Deprecated alias names: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.
• Person & email address to contact for further information: the author of this document.
• Intended usage: COMMON
• Restrictions on usage: N/A
• Author: see the Authors' Addresses section of this document.
• Change controller: Action State Group, Inc. (interim); the IETF on publication.
• Provisional registration: yes (pending publication of this document).

Security Considerations The tamper-evidence-versus-runtime-honesty boundary — that the envelope signature and registration Receipt attest record bytes and their timing, not the recording runtime's honesty at the moment of recording — is given in 's Security Considerations (Tamper Evidence and Runtime Honesty). This profile inherits that boundary; the following extends it to the confirmed-effect binding. Confirmed means observed-and-bound, not world-state. A confirmed effect proves the producer bound the bytes of an observed response, not that the external world reached the claimed state. The same boundary extends one hop upstream: binding an observed response proves the producer observed those bytes, not that the responding system was authentic or that the channel was on-path-intact. An attacker who substitutes or forges the response — a false success delivered on-path — induces an honest confirmed Capsule for an effect that did not land; this profile does not mitigate upstream spoofing of the response itself, which is bounded by the same trust assumption as runtime honesty above. Later, independently sourced outcome statements () are the mechanism by which such a spoofed confirmation is contradicted over time. Self-attested versus anchored tiers differ in evidentiary weight. A self-attested Capsule is verifiable against its own bytes and signer; an anchored (registered) Capsule additionally resists omission and back-dating through the Transparency Service's append-only log and receipts. A verifier reports the tier it actually verified and never upgrades a claim it could not check. The honest human-in-the-loop flag () is itself security-relevant: it prevents a policy auto-approval from being presented as human oversight. The invariant — human_disposed: true requires approver: "human" — is structurally guaranteed: a conforming producer cannot construct or sign a Capsule that violates it, so the combination simply does not arise in well-formed records, and the claim is falsifiable from the record alone. A verifier consuming non-constructor-produced bytes SHOULD assert the invariant defensively against hand-crafted input (). The low-entropy digest leakage risk — that a digest over a small enumeration, short identifier, or bounded value space is recoverable by an adversary via a dictionary attack, and so is not confidential merely by being a digest — is given in 's Security Considerations (Low-Entropy Fields). This profile's reason_digest and evidence_digest fields are subject to that caveat; producers SHOULD commit such values under a per-tenant salt or via a tenant-private manifest rather than digesting the bare value. Input integrity is a composable upstream concern. This profile records what the producer observed and bound at seal time; it does not authenticate the provenance of inputs delivered to the agent before sealing. A response spoofed on-path induces an honest confirmed Capsule for an effect that did not land. Input integrity — binding the authenticity of request bytes and upstream grounding sources to the authorization before the seal — is a separate guarantee that composes with this profile at the digest layer: a producer that holds input-integrity evidence (a signed tool response, an attested transport record, a C2PA-style content credential, or an action-body HMAC with memory provenance attestation) MAY reference it by digest in the Capsule payload, preserving the verifier's disinterest — the verifier checks the binding without trusting the producer's claim about upstream systems it cannot observe. This profile partially addresses the grounding dimension via the value_grounded constraint (), which checks that a quoted value matches its cited source, and via model_attestation (), which constrains the emitter identity. The remaining input-integrity surface is out of scope for this profile and is addressed by composing a dedicated input-integrity mechanism upstream. Payload-level identity is stable across signing-key rotation. The operator and developer fields in the Capsule payload () are plain strings committed to the capsule_id digest. They are independent of the signing key: a producer that rotates its COSE signing key (and therefore changes the iss claim in the protected header) without changing operator or developer preserves payload-level identity continuity across the rotation. A verifier accumulating long-horizon history SHOULD correlate Capsules by payload operator — and, when present, epoch_id () — rather than by the SCITT-layer iss claim, which may change on key rotation. Absent a recorded linkage, pre- and post-rotation Capsules are distinguishable by payload operator alone but not correlatable at the SCITT-header layer; a producer SHOULD treat a key rotation that coincides with a configuration change as an epoch boundary () to make the transition explicit in the record. See also of this document for the data-admission tiers that govern which runtime context fields MAY enter a Capsule, including the consequence of the low-entropy digest caveat above for end-user identity fields. Issuer authentication is registration-policy territory, not payload territory. The three supported patterns for binding the iss claim to a verifiable signing key — did:web, x5chain, and SPIFFE SVID — are defined in . A registration policy that accepts a bare, unresolvable kid without enforcing at least one of these patterns reduces issuer accountability to key-material correlation only; verifiers relying on issuer identity for policy decisions SHOULD confirm which binding pattern, if any, was enforced at registration time.

Privacy Considerations A Capsule is content-addressed, tamper-evident, and MAY be anchored to a Transparency Service. As a direct consequence, a committed Capsule cannot be retracted: there is no after-the-fact edit path, and an anchored record is durable beyond the producer's control. Therefore: anything admitted to a Capsule is admitted permanently, and PII or secrets in a content-addressed, tamper-evident, anchored record are unfixable by design. Producers MUST apply a default-deny posture to runtime context before it reaches a Capsule.

Data-Admission Tiers Producer and adapter authors MUST classify every candidate field into exactly one of the following tiers before admission:

1. Clear-safe — Opaque correlation handles that are joinable but non-identifying: for example, agent_name, function_call_id, invocation_id. A field is clear-safe when its value neither identifies a natural person nor carries content material. These MAY be committed in clear.
2. Digest-only — when a value must be provable later without being disclosed now, it MUST be committed as a digest, never in clear. This tier covers payload content: material a verifier may need to check but that must not be exposed in the record. This tier is realized by the selective-disclosure / detached-payload model (): the Capsule carries only a digest; content is held under deployment controls and disclosed selectively.
3. Never-enters — end-user identity (session identifiers, user identifiers, account handles) and secrets/credentials (tokens, keys) MUST NOT enter a Capsule, in clear or as a digest. Critical: hashing is not anonymization for low-entropy identifiers. Session and user identifiers and similar low-entropy values are recoverable by dictionary attack against their digest (see also ). Therefore a digest of such an identifier is not a safe substitute — the digest re-identifies. Identity MUST be excluded, not digested. Where cross-record or cross-slot correlation of a subject is genuinely required, a pairwise or encrypted correlation identifier SHOULD be used instead of the raw or hashed user identifier.

Adapter Allow-List Pattern Adapters SHOULD adopt an allow-list stance: enumerate the fields that MAY enter a Capsule (tier 1, plus tier-2 digests) and default-deny everything else. A block-list — enumerating what may NOT enter — fails open: when a runtime adds a new context field in a later version, a block-list silently admits it. An allow-list fails closed, which is the correct direction for a record that cannot be retracted once committed. Adapter authors SHOULD publish the allow-list in adapter documentation so deployers can audit admission without reading implementation code.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Action State Group, Inc. Tyche Institute n.d. Informative References Tradeverifyd Fraunhofer SIT Microsoft Microsoft COSE (CBOR Object Signing and Encryption) Receipts prove properties of a verifiable data structure to a verifier. Verifiable data structures and associated proof types enable security properties, such as minimal disclosure, transparency and non-equivocation. Transparency helps maintain trust over time, and has been applied to certificates, end to end encrypted messaging systems, and supply chain security. This specification enables concise transparency oriented systems, by building on CBOR (Concise Binary Object Representation) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Fraunhofer SIT Bowball Technologies Ltd Microsoft Research This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. Fraunhofer SIT Microsoft Research Microsoft Research Microsoft Research This document defines a new verifiable data structure (VDS) type for COSE Receipts and inclusion proofs specifically designed for append- only logs produced by the Confidential Consortium Framework (CCF) to provide stronger tamper-evidence guarantees. mesur.io Tradeverifyd Fraunhofer SIT This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is inspired by the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. Keel API, Inc. This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. VERIDIC Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS v4.0, and MiFID II. VeritasChain Standards Organization This document defines a claim set for recording AI content refusal events. The claim set specifies the semantic content and correlation rules for refusal audit trails, independent of any particular serialization format. The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This specification addresses claim semantics and verification requirements; it does not mandate a specific encoding. A CDDL definition is provided for CBOR-based implementations, and equivalent JSON representations are shown in an appendix for illustration. This specification provides auditability of logged refusal decisions. It does not define content moderation policies, classification criteria, or what AI systems should refuse. VeritasChain Standards Organization This document defines a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) applies the SCITT framework to address the specific requirements of financial markets, including high-precision timestamps, regulatory compliance considerations (EU AI Act, MiFID II), and privacy-preserving mechanisms (crypto-shredding) compatible with GDPR. This profile specifies how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. It further defines SCITT conformance profiles for interoperability and an ERASURE event type that records crypto- shredding operations as immutable audit events. About This Document This note is to be removed before publishing as an RFC. The latest version of this document, along with implementation resources and test vectors, can be found at https://github.com/veritaschain/vcp-spec. Discussion of this document takes place on the SCITT Working Group mailing list (scitt@ietf.org). Changes from -02: * Updated to align with VCP Specification v1.2 * Added SCITT Alignment Object and conformance profiles (Section 4.4) * Added ERASURE event type recording crypto-shredding operations (Section 6.3) * Corrected the post-quantum SignAlgo registry value from DILITHIUM3 to DILITHIUM2 (ML-DSA, FIPS 204) * PolicyID examples migrated to the Issuer Domain + Local ID naming convention defined in VCP v1.2 VeritasChain Standards Organization Automated decision-making systems, including AI and algorithmic systems in critical infrastructure, currently lack standardized mechanisms for producing evidentiary-grade provenance records that can withstand independent verification. Traditional logging approaches fail to provide the cryptographic guarantees required for regulatory compliance, forensic investigation, and cross- organizational accountability. This document describes the Verifiable AI Provenance Framework (VAP), an architectural framework that defines requirements for producing verifiable decision trails using existing IETF security technologies. VAP does not define new protocols or cryptographic primitives; rather, it provides an architectural coordination layer that enables domain-specific profiles to leverage Supply Chain Integrity, Transparency and Trust (SCITT), Remote Attestation Procedures (RATS), CBOR Object Signing and Encryption (COSE), and related IETF work in a consistent manner. This document is intended to frame the problem space and facilitate discussion about whether architectural coordination work is needed in this area. LedgerProof Foundation This document defines a Supply Chain Integrity, Transparency, and Trust (SCITT) profile for machine-readable cryptographic transparency receipts addressing all four sub-obligations of Article 50 of Regulation (EU) 2024/1689 (the "EU AI Act"): interactive AI system disclosure (50(1)), machine-readable marking of synthetic media (50(2)), emotion recognition notification (50(3), referenced for completeness), and AI-generated text disclosure with human editorial review exemption (50(4)). The profile defines three SCITT statement content types ("ai/article-50/v1", "ai/human-review/v1", and "ai/chatbot-session/v1") and specifies validation, verification, and chain-of-custody semantics suitable for presentation to European Union supervisory authorities, national competent authorities, and judicial proceedings. The profile is substrate-agnostic but presumes a SCITT Transparency Service backed by a publicly verifiable append-only log. A reference implementation using the Bitcoin blockchain as the SCITT log substrate, via RFC 6962 Merkle aggregation anchored in OP_RETURN transactions, is described in companion document draft-dawkins-scitt-lpr-00. MyAuberge K.K. This document specifies the Governance Audit Record (GAR), the audit architecture for agentic AI systems. GAR defines five audit types, the Session Audit Record (SAR), the Audit Alert system, auditor principal categories, and the Audit Package for external regulatory inspection. GAR provides verifiable evidence that AI agent sessions were governed in accordance with the Intent Declaration Primitive and the Human Escalation Mechanism. GAR answers the governance question: can any of this be proven to a regulator? GAR is a domain-specific application of the SCITT (Supply Chain Integrity, Transparency and Trust) architecture extended with causal ordering semantics for agentic governance events. GAR defines the Authority Lifecycle Event (ALE) category: a normative set of causally-ordered event types covering the complete agent session revocation and recovery lifecycle, including single-agent revocation, authority suspension, partial state recording, recovery initiation, credential restoration, and multi-agent delegation tree events. Version -03 adds the SOOS Governance Semantic Convention: the normative soos.governance.* OpenTelemetry attribute namespace for governance observability, the SOOS GAR Processor specification for OTel-to-SAR pipeline construction with Session Block Merkle integrity, four new Authority Lifecycle Events, three mandatory provenance fields on Cedar evaluation records, and the XPID mirror field on ACD session ALEs. Version -04 made the Session Block construction rules more explicit, closing three ambiguities found during independent interop verification at the IETF 126 Hackathon. Version -05 supersedes -04's Session Block construction text with a corrected construction: the Merkle leaf and internal-node hashes are now domain-separated (RFC 9162's Merkle Tree Hash, with 0x00/0x01 prefix octets) and odd-length levels use RFC 9162's k-split recursive tree shape rather than duplicate-node padding, closing a malleability class structurally equivalent to CVE-2012-2459 that was present in -04's construction. This revision is fully self-contained: unlike -03 and -04, it does not carry forward unreproduced text from an earlier version. Version -05 also adds a subject_digest field to Cedar-evaluation GAR records, the same construction used by the Agent Accountability Composition as its cross-slot join key, positioning GAR as a conforming AEP instance under the RATS-bound composition; the field is normatively scoped to prohibit independent re- serialization where an upstream party has already established the action's canonical serialization, per the failure mode documented in the SCITT typed-reference specification. Version -06 closes gaps surfaced by a WIMSE-style security review pass against -05's own text and reference sample code: a JWKS trust- anchor bootstrap requirement, a corrected key-compromise remediation procedure that no longer requires re-signing already-committed audit artifacts, an explicit Level 1/2 residual-risk disclosure for a compromised-but-signing GEC, a defined failure path for KIA signer quorum failure at Session Block close, referential-integrity enforcement for causal_parent_id, and guidance against alert-fatigue false positives in session_sequence_number gap detection. This revision also carries an idnits repair pass covering reference classification, citation hygiene, and formatting. Nivalto, Inc. This document specifies the Agent Route Origin Authorization (AgentROA) framework, a cryptographic policy enforcement model for governing the actions of autonomous AI agents. AgentROA introduces three core protocol objects: the Agent Route Origin Authorization (ROA) envelope, the Agent Route Attestation (ARA) per-hop receipt, and the Agent Execution Receipt (AER). Together these objects enable: (1) cryptographic binding of an agent's authorized action scope to a signed policy envelope at session initialization, (2) per-hop attestation across multi-agent delegation chains with monotonic scope-narrowing semantics (no policy envelope may be expanded by a downstream delegation), and (3) cryptographic receipts produced intrinsically by the enforcement decision at each capability invocation boundary. The framework is modeled on the BGP Route Origin Authorization (ROA) concept from RPKI (RFC 6480) applied to the AI agent execution domain. The Border Gateway enforcement model positions a cryptographic enforcement process at a capability invocation boundary — external to the agent's execution context — reducing the risk that governance decisions are influenced by the governed agent by placing enforcement in a separate process boundary. The Border Gateway model is topology-independent: it may be deployed as a protocol- specific proxy in front of Model Context Protocol (MCP) servers, as a service mesh enforcement component covering all inter-service calls, as a network egress gateway covering all outbound capability invocations regardless of protocol, or as a domain-specific execution boundary. The protocol objects defined herein function identically across all deployment topologies. This document establishes the architectural model, protocol object schemas, and enforcement semantics for the AgentROA framework. A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes. Action State Group, Inc. n.d. Action State Group, Inc. n.d. Action State Group, Inc. n.d. n.d. Mastercard n.d. Glyphzero n.d.

Acknowledgments The author thanks the reviewers and contributors who shaped the design recorded here, and the SCITT and COSE working groups whose substrate this profile builds on. The author additionally thanks Jody Edmondson for identifying the producer-context data-admission problem and the allow-list adapter pattern in capsule-emit issue #22, which shaped the Privacy Considerations of this document.