SCITT S. Mih Internet-Draft Action State Group, Inc. Intended status: Standards Track 28 August 2026 Expires: 1 March 2027 An Agent Action Capsule Profile for SCITT draft-mih-scitt-agent-action-capsule-04 Abstract 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 identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be 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). 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 1 March 2027. Mih Expires 1 March 2027 [Page 1] Internet-Draft Agent Action Capsules August 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Producer Envelopes and SCITT registration . . . . . . . . . . 5 3.1. Producer Envelope wire profile . . . . . . . . . . . . . 5 3.2. Issuer Binding . . . . . . . . . . . . . . . . . . . . . 6 3.3. Registration and Receipts . . . . . . . . . . . . . . . . 6 3.4. Outcomes . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Registries of this profile (summary) . . . . . . . . . . . . 7 5. The Agent Action Capsule . . . . . . . . . . . . . . . . . . 7 5.1. Identity and parties . . . . . . . . . . . . . . . . . . 7 5.2. Configuration epochs . . . . . . . . . . . . . . . . . . 10 5.2.1. The epoch_id field . . . . . . . . . . . . . . . . . 10 5.2.2. Epoch-boundary Capsules . . . . . . . . . . . . . . . 11 5.2.3. Epoch-scoped verification . . . . . . . . . . . . . . 11 5.3. Effect Record and the confirmed-effect binding . . . . . 12 5.4. Assurance . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. Cross-party assurance . . . . . . . . . . . . . . . . 15 5.5. Disposition and the verdict reason-class . . . . . . . . 17 5.5.1. The verdict_class vocabulary . . . . . . . . . . . . 18 5.5.2. Orthogonality with effect_mode . . . . . . . . . . . 20 5.5.3. A Capsule on every verdict . . . . . . . . . . . . . 20 5.5.4. Chained Capsules and human-in-the-loop resolution . . 21 5.5.5. Cross-record references . . . . . . . . . . . . . . . 22 6. Class 1 verification . . . . . . . . . . . . . . . . . . . . 24 7. Conformance: two verifier classes . . . . . . . . . . . . . . 26 8. Manifest-dependent material . . . . . . . . . . . . . . . . . 27 8.1. Constraint Records . . . . . . . . . . . . . . . . . . . 27 8.2. Class 2 verification . . . . . . . . . . . . . . . . . . 27 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Namespacing convention . . . . . . . . . . . . . . . . . 28 9.2. Selective Disclosure . . . . . . . . . . . . . . . . . . 28 10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 29 Mih Expires 1 March 2027 [Page 2] Internet-Draft Agent Action Capsules August 2026 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 12.1. New registries . . . . . . . . . . . . . . . . . . . . . 31 12.2. No new registry . . . . . . . . . . . . . . . . . . . . 33 12.3. Media Type Registrations . . . . . . . . . . . . . . . . 34 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38 14.1. Data-Admission Tiers . . . . . . . . . . . . . . . . . . 38 14.2. Adapter Allow-List Pattern . . . . . . . . . . . . . . . 39 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 15.1. Normative References . . . . . . . . . . . . . . . . . . 39 15.2. Informative References . . . . . . . . . . . . . . . . . 40 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 1. 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 defines the Agent Action Capsule, its signer- independent identity, a COSE_Sign1 Producer Envelope, and a separate SCITT [RFC9943] registration statement for making the Capsule ID transparent. The Capsule is 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 (Section 5.3) 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 (Section 5.5.3). 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. Mih Expires 1 March 2027 [Page 3] Internet-Draft Agent Action Capsules August 2026 3. Independent verifiability. The substrate guarantees (envelope signature, registration, receipt) are SCITT's and are verified by reference; the agent-domain checks defined here (Section 6, Section 8.2) are deterministic and reproducible by any verifier from the record's own bytes, in two conformance classes (Section 7). The term "Producer Envelope profile" means the exact COSE protected- header, payload, and signature constraints in Section 3.1. The Capsule JSON and its identity construction remain independently verifiable without an envelope. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Capsule: The Agent Action Capsule, a JSON record of one agent action with a signer-independent content identity. 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 Capsules and may create one or more independent Producer Envelopes over a Capsule ID. Producer Envelope: A COSE_Sign1 object whose attached payload is the raw 32-byte Capsule ID. It authenticates one signing key's commitment to that identity without changing the Capsule or its capsule_id. Verifier: Any party that validates a Capsule from its bytes, without trusting the Producer. Verifier conformance is split into two classes (Section 7). Mih Expires 1 March 2027 [Page 4] Internet-Draft Agent Action Capsules August 2026 New Capsules compute JSON digests with plain JSON Canonicalization Scheme (JCS) [RFC8785] and declare canonicalization_id: "jcs". No absent-field normalization is applied: null, empty arrays, and empty objects participate when present. JSON floating-point values are forbidden in digest-bearing material, and integers outside the IEEE-754 safe range MUST be represented as decimal strings. The withdrawn jcs-n construction of [I-D.mih-sokolov-scitt-payload-binding] remains only as a vintage Capsule-ID verification path. It is selected by a format-2 Capsule in which canonicalization_id is absent. A producer MUST NOT emit jcs-n, and a verifier MUST reject any explicit canonicalization_id: "jcs-n" declaration. 3. Producer Envelopes and SCITT registration 3.1. Producer Envelope wire profile A Producer Envelope is a tagged COSE_Sign1 [RFC9052] object (CBOR tag 18, [RFC8949]). It signs the Capsule's stable identity, not the Capsule JSON. Its attached payload MUST be the raw 32 bytes obtained by decoding the Capsule's 64-character lowercase hexadecimal capsule_id. The payload MUST NOT be hexadecimal text or a JSON serialization. The protected header map MUST contain exactly these three entries: +==========+=========================+=============================+ | COSE | Value | Meaning | | label | | | +==========+=========================+=============================+ | 1 (alg) | -8 | EdDSA using Ed25519. | +----------+-------------------------+-----------------------------+ | 3 | application/agent- | The attached raw Capsule-ID | | (content | action-capsule-id | payload. | | type) | | | +----------+-------------------------+-----------------------------+ | 4 (kid) | raw 32-byte Ed25519 | Self-contained verification | | | public key | key and self-attested | | | | signer identifier. | +----------+-------------------------+-----------------------------+ Table 1 The unprotected header map MUST be empty in a bare Producer Envelope. The signature MUST be a 64-byte Ed25519 signature over the COSE Sig_structure with context Signature1, the encoded protected map, an empty external AAD, and the attached payload. Mih Expires 1 March 2027 [Page 5] Internet-Draft Agent Action Capsules August 2026 A Capsule MAY have zero, one, or multiple Producer Envelopes. Each envelope is an independent object and MUST verify independently against the same Capsule ID. Envelopes are not embedded in the Capsule-ID preimage. Adding, removing, or replacing an envelope therefore never changes capsule_id. This document does not mandate a container representation for carrying a Capsule together with its envelopes. 3.2. Issuer Binding Successful Producer Envelope verification proves that the holder of the private key corresponding to the protected kid signed the Capsule ID. It does not prove that this key is authorized for the Capsule's operator, developer, or action. Key authorization is caller policy and is deliberately separate from the cryptographic verdict. A verifier MUST return the authenticated public key so the caller can apply an allow-list, certificate, DID, SPIFFE, or other authorization policy without changing this wire profile. 3.3. Registration and Receipts A bare Producer Envelope is not an [RFC9943] Signed Statement. Its protected map intentionally contains only the three entries in Section 3.1, whereas an RFC 9943 Signed Statement additionally requires protected CWT iss and sub claims. A conforming Transparency Service therefore MUST NOT treat a bare Producer Envelope as an RFC 9943 Signed Statement. To make a Capsule ID transparent, a registrar creates a distinct RFC 9943 Signed Statement whose attached payload is the same raw 32-byte Capsule ID and whose content type is application/agent-action- capsule-id. That registration statement MUST satisfy every RFC 9943 protected-header requirement, including CWT iss and sub. The returned Receipt binds the registration statement to the service's append-only log. It does not replace or modify any Producer Envelope and does not by itself authorize a Producer Envelope key. Receipt format, Merkle-tree proof construction, and proof verification are SCITT substrate concerns defined by reference to [I-D.ietf-cose-merkle-tree-proofs] and an applicable receipt profile such as [I-D.ietf-scitt-receipts-ccf-profile]. Verification is compositional: verify the Capsule ID, verify each Producer Envelope independently, require the SCITT registration statement payload to equal that raw Capsule ID, then verify its Receipt under a trusted Transparency Service key. A verifier MUST NOT report attestation_mode: "anchored" unless all applicable registration- statement and Receipt checks succeed. Mih Expires 1 March 2027 [Page 6] Internet-Draft Agent Action Capsules August 2026 3.4. Outcomes An asynchronously observed consequence, such as a reversal, dispute, correction, or confirmation, is recorded as a new Capsule with its own Capsule ID. It MAY carry its own Producer Envelopes. Correlation uses payload fields such as action_id, decision_id, external_ref, and chain; it does not mutate the original Capsule. The log remains append-only and the original identity remains immutable. 4. Registries of this profile (summary) Seven vocabularies of this profile are registry-governed under a Specification Required policy ([RFC8126], Section 4.6): verdict_class, disposition.decision, effect.type, irreversibility_class, effect_attestation, chain.relation, and citation_purpose. The registries and their initial contents are defined in Section 12, kept at the back of this document per convention. The binding invariant, stated once here and again in Section 12: 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. 5. 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 Section 8.1. 5.1. 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- | Mih Expires 1 March 2027 [Page 7] Internet-Draft Agent Action Capsules August 2026 | | | | action-capsule-04". | +---------------------+-----------+----------+----------------------+ | format_version | string | REQUIRED | The serialization- | | | | | suite version. New | | | | | Capsules use "4". | | | | | Vintage format-2 | | | | | Capsules remain | | | | | verifiable only | | | | | under the | | | | | compatibility rule | | | | | below. | +---------------------+-----------+----------+----------------------+ | canonicalization_id | string | REQUIRED | New Capsules MUST | | | | for | carry exactly | | | | format | "jcs". Explicit | | | | 4; MUST | "jcs-n", empty, | | | | be | null, non-string, | | | | absent | and unknown | | | | for | declarations are | | | | format 2 | invalid. | +---------------------+-----------+----------+----------------------+ | capsule_id | string | REQUIRED | The derived | | | (64 | | identifier. For | | | lowercase | | format 4, compute | | | hex) | | SHA-256 over plain | | | | | JCS of the Capsule | | | | | with only | | | | | capsule_id removed. | | | | | The | | | | | canonicalization_id | | | | | declaration and | | | | | chain block | | | | | participate. | | | | | 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). | Mih Expires 1 March 2027 [Page 8] Internet-Draft Agent Action Capsules August 2026 +---------------------+-----------+----------+----------------------+ | 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 | [RFC3339] 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 | | | | | (Section 5.2) — | | | | | 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 | Mih Expires 1 March 2027 [Page 9] Internet-Draft Agent Action Capsules August 2026 | | | | epoch_id. Absent | | | | | epoch_id implies a | | | | | single, unnamed | | | | | epoch; a producer | | | | | MUST NOT back-fill | | | | | epoch_id on | | | | | Capsules already | | | | | sealed. | +---------------------+-----------+----------+----------------------+ Table 2 For a vintage format-2 Capsule, canonicalization_id MUST be absent. Its Capsule ID is verified by removing capsule_id and chain, applying the legacy absent-field normalization, then applying JCS and SHA-256. This path is verification-only. A producer MUST NOT emit a new format-2 Capsule. Monetary and quantity values are subject to the exact-decimal-string requirement in Section 2. 5.2. 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." 5.2.1. The epoch_id field The epoch_id payload field (Section 5.1) 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. Mih Expires 1 March 2027 [Page 10] Internet-Draft Agent Action Capsules August 2026 5.2.2. 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, Section 12); and * a RECOMMENDED model_attestation block (Section 5.1) 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, Section 12) 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. 5.2.3. 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. For format 4, the chain block participates in capsule_id. Changing a parent identifier or relation after sealing therefore changes the recomputed identity and invalidates every Producer Envelope over the prior Capsule ID. Only vintage format-2 verification excludes chain. Mih Expires 1 March 2027 [Page 11] Internet-Draft Agent Action Capsules August 2026 5.3. 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 | request_digest and | | | dispatched. | response_digest MUST be | | | | absent. | +------------+------------------+--------------------------+ | dispatched | Sent; result not | request_digest SHOULD be | | | observed. | present; response_digest | | | | MUST be absent. | +------------+------------------+--------------------------+ | confirmed | Result observed | response_digest MUST be | | | and bound. | present and MUST be a | | | | JSON digest (Section 2) | | | | of the actual response. | +------------+------------------+--------------------------+ | failed | Attempted; | response_digest, when | | | runtime reported | present, digests the | | | failure (state | failure response. | | | known). | | +------------+------------------+--------------------------+ | reverted | A committed | Correlated via | | | effect was | external_ref / | | | undone. | decision_id. | +------------+------------------+--------------------------+ Table 3 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, Section 12), 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, Section 12). Mih Expires 1 March 2027 [Page 12] Internet-Draft Agent Action Capsules August 2026 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 (Section 12; 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. | +--------------------+---------------------------------+ Table 4 Validity is checked against the assurance effect_mode (Section 5.4): +========================+====================================+ | 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 | +------------------------+------------------------------------+ Table 5 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 Section 5.3. 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 Mih Expires 1 March 2027 [Page 13] Internet-Draft Agent Action Capsules August 2026 underlying committed effect it reverses is correlated separately via external_ref / decision_id (the Effect Record fields, Section 5.3), 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, distinguishing gate-observed execution from runtime-claimed execution. It is not copied into a Producer Envelope header. References to external authorization records carried in the Effect Record (for example, permit receipts per [I-D.munoz-scitt-permit-profile], or machine mandates) are typed digest references per [I-D.mih-sokolov-scitt-payload-binding]'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. NOTE: docs/interop/aac-aep-scitt-digest-binding-vector.json pins a machine-checkable positive/negative demonstration of this Cross- Profile Comparability rule across AAC, AEP, and SCITT under the profile label urn:action-state:aac-aep-scitt:digest- binding:2026-07-02. 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, either a current JSON 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. 5.4. 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 Mih Expires 1 March 2027 [Page 14] Internet-Draft Agent Action Capsules August 2026 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. 5.4.1. 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 Section 5.5.2 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 Section 5.4 already applies to attestation_mode, effect_mode, and ledger_mode: Mih Expires 1 March 2027 [Page 15] Internet-Draft Agent Action Capsules August 2026 +======================+=========================================+ | 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. | +----------------------+-----------------------------------------+ Table 6 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 (Section 6), downgrading the reported derived rung to the value the evidence actually supports — the same treatment Section 6 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 JSON digest (Section 2) of the initiator's own signed half. A bare intra- profile digest, not a CPB typed digest reference (Section 5.3). * counterparty_ref (OPTIONAL): a JSON 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. Mih Expires 1 March 2027 [Page 16] Internet-Draft Agent Action Capsules August 2026 * 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 (Section 5.3), 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 Section 5.4 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 (Section 6), 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 [I-D.mih-agent-bilateral-attestation]'s concern, not this profile's; this profile carries only the rung claim and the minimal correlation evidence needed to rederive it honestly. 5.5. 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, Section 12). * 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 (Section 12), 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. Mih Expires 1 March 2027 [Page 17] Internet-Draft Agent Action Capsules August 2026 * 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 (Section 5.5.1). 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 JSON digest (Section 2) 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 Section 5.4.1) 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. 5.5.1. The verdict_class vocabulary verdict_class records WHY the action terminated as it did. The seeded vocabulary (registry-governed, Section 12; unregistered values are informational to a verifier, never a rejection): Mih Expires 1 March 2027 [Page 18] Internet-Draft Agent Action Capsules August 2026 +=================+===============================================+ | 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, Section 5.5.2). | +-----------------+-----------------------------------------------+ Table 7 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". Mih Expires 1 March 2027 [Page 19] Internet-Draft Agent Action Capsules August 2026 5.5.2. 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 (Section 5.5.4) — 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. 5.5.3. 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 (Section 12) — 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 Mih Expires 1 March 2027 [Page 20] Internet-Draft Agent Action Capsules August 2026 constraint or policy fired and the action did not proceed. Recording only successes makes the evidence trail survivorship-biased and the refusal path unverifiable. 5.5.4. 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 (Section 12; Specification Required), seeded with one value: +=============+====================================================+ | relation | Meaning | +=============+====================================================+ | confirms | Non-terminal: this Capsule observes or records the | | | outcome of the parent; the parent's open state | | | remains. | +-------------+----------------------------------------------------+ | 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 (Section 5.2.2); | | | the prior epoch's last Capsule is the parent. | +-------------+----------------------------------------------------+ Table 8 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. Mih Expires 1 March 2027 [Page 21] Internet-Draft Agent Action Capsules August 2026 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". 5.5.5. Cross-record references chain presupposes the cited Capsule is this producer's own: it is scoped to same-custody-stream, single-parent state transitions (Section 5.5.4). It has no shape for citing a record outside that stream — a different producer's Capsule, or any other artifact this Capsule's action was performed on or in response to. A Capsule MAY carry a digested references array for exactly that case; absent or empty means the Capsule makes no such citation. Like the rest of the payload, references participates in the capsule_id digest (Section 5.1): citing a record is itself a claim this Capsule's signature covers. *Boundary rule.* chain is exclusively the producer's own same-stream parent and is the only field Section 5.4's ledger_mode derivation reads. references is exclusively for everything else. A references entry MUST NOT name the same target as chain.parent_capsule_id — a producer citing its own same-stream parent states that once, in chain, never redundantly in references. *Shape.* Each references entry's identity is a CPB typed digest reference [I-D.mih-sokolov-scitt-payload-binding]: {type, digest_alg, digest}, the same mechanism this profile already uses for the external-authorization references of the Effect Record (Section 5.3). type names an artifact type per the CPB Artifact Type registry; this document defines the references entry shape, not an exhaustive list of what may be cited. A reference MAY additionally carry log_coordinates, an object {log_id, leaf_index, inclusion_proof}, present as a unit when the cited record has been registered to an append-only log a verifier can consult. log_coordinates is an upgrade, not a second identity: it proves the exact referenced bytes were found at the stated log position, and its presence or absence never changes what type + digest_alg + digest already identify. Producer-local log checkpointing is future scope at the CPB binding layer, not this document (Section 11); until that mechanism is specified, a Class 1 verifier treats a present log_coordinates member as structurally recorded and MUST NOT report it as independently verified. Mih Expires 1 March 2027 [Page 22] Internet-Draft Agent Action Capsules August 2026 *Citation purpose.* A references entry MAY carry citation_purpose, a registry-governed (Specification Required, Section 12) string stating why this Capsule cites the target. citation_purpose is a distinct vocabulary from CPB's own purpose field on a typed digest reference: CPB's purpose selects among an artifact type's registered digest contexts, and citation_purpose is this profile's own, separately- named field for the citing relationship, never a repurposing of CPB's field. The seeded vocabulary: +==================+==============================================+ | citation_purpose | Meaning | +==================+==============================================+ | acted_on | This Capsule's action targeted, consumed, or | | | was performed against the cited record's | | | declared content — a stream boundary, not a | | | custody claim: the cited record may belong | | | to a different producer or stream entirely, | | | and citing it asserts only that this action | | | is about that content, never that the citing | | | producer holds or continues its custody. | +------------------+----------------------------------------------+ | responds_to | This Capsule addresses or answers the cited | | | record without a same-stream chain | | | relationship to it — the cited record is not | | | this Capsule's chain.parent_capsule_id and | | | MAY be a different producer's record or | | | otherwise outside this producer's own | | | stream. | +------------------+----------------------------------------------+ Table 9 Designated-expert guidance: both seeded values name a cross-stream citation intent that chain.relation cannot express because chain.relation is scoped to same-stream transitions (Section 5.5.4). A producer whose citation is a same-stream state transition over its own parent uses chain instead and never mints a references entry for it (the boundary rule above). Additional citation_purpose values are expected future registrations, each admitted once its semantics are pinned in a publicly available specification, per this document's Specification Required policy (Section 12). *Relation to chain.relation's confirms value in deployed implementations.* A cross-stream citation — for example, a denial Capsule addressing a prior record that is not its own chain parent — is not a same-stream state transition and so is not a chain.relation value under this profile; chain.relation registers no value for it, and none is added by this revision. Such a citation is a references Mih Expires 1 March 2027 [Page 23] Internet-Draft Agent Action Capsules August 2026 entry with citation_purpose: "responds_to" (or "acted_on", if it is the affirmative case). An implementation using chain with a confirms-shaped relation for a citation that is not the same-stream parent is not using chain as this document defines it; the compatible migration is a references entry with the appropriate citation_purpose, not a fourth chain.relation value. 6. Class 1 verification Capsule verification and Producer Envelope verification are independent. A verifier can validate a Capsule with no envelope, and can validate any number of envelopes against a Capsule ID without changing the Capsule result. For each Producer Envelope, a verifier MUST: 1. validate the exact tag, protected map, empty unprotected map, attached payload, and signature sizes in Section 3.1; 2. require the attached payload to equal the raw 32 bytes of the Capsule ID; 3. verify the Ed25519 signature under the public key carried in kid; and 4. return that authenticated public key separately from any caller- defined authorization decision. Malformed or unverifiable envelopes MUST produce structured failures and MUST NOT cause the verifier to throw or panic. One invalid envelope does not erase the validity of another independent envelope over the same Capsule ID. Receipt verification is a separate substrate step performed by reference to [RFC9943] and [I-D.ietf-cose-merkle-tree-proofs]. The agent-profile checks below are normative here and constitute Class 1 verification (Section 7): every check is performable from the Capsule JSON, the registry contents (Section 4), 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; format 4 requires exactly canonicalization_id: "jcs"; format 2 requires the field to be absent; unknown formats and all other declarations fail closed. Mih Expires 1 March 2027 [Page 24] Internet-Draft Agent Action Capsules August 2026 2. Identity: for format 4, remove only capsule_id and compute SHA-256 over plain JCS. For vintage format 2, remove capsule_id and chain, apply absent-field normalization, then JCS and SHA- 256. Compare the result with the carried capsule_id. 3. Confirmed-effect binding: effect.status: "confirmed" without a well-formed response_digest is a failure (Section 5.3). 4. Verdict/effect orthogonality: a never-dispatching verdict_class with a derived effect_mode other than "not_applicable" is a failure (Section 5.5.2); 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 (Section 5.3). 6. Chain semantics (store-level): a missing chain parent is a failure; concurrent supersedes surface as findings per Section 5.5.4. A references entry (Section 5.5.5) is a different claim: it is informational cross-stream correlation, never a chain-integrity input, and a verifier MUST NOT treat a references entry naming an unresolvable or absent target as a chain- semantics failure — only a references entry that duplicates chain.parent_capsule_id is a failure, per the boundary rule of Section 5.5.5. 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, citation_purpose): report as informational findings; MUST NOT reject (Section 12). An unknown effect_attestation is additionally graded no stronger than runtime_claimed (Section 5.3). Disposition honesty is structurally guaranteed, not a live check above. The honesty invariant — human_disposed: true REQUIRES approver: "human" (Section 5.5) — 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 Mih Expires 1 March 2027 [Page 25] Internet-Draft Agent Action Capsules August 2026 defensively against hand-crafted input. The closed approver enum (Section 5.5) 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" (Section 5.3); 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 (Section 8.2). 7. 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 Capsule payload WITHOUT any constraint manifest: 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 Section 6. Producer Envelope and Receipt results are reported independently and do not alter payload Class 1. Class 2 verifier: A Class 1 verifier that additionally performs manifest-aware verification (Section 8.2): 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. Mih Expires 1 March 2027 [Page 26] Internet-Draft Agent Action Capsules August 2026 8. 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. 8.1. 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 JSON digest, Section 2) 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 Section 9.1. 8.2. 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 (Section 6); their results never weaken a Class 1 result — they extend it. 1. Constraint evidence-schema check: for each Constraint Record (Section 8.1) 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. Mih Expires 1 March 2027 [Page 27] Internet-Draft Agent Action Capsules August 2026 2. Threshold checks: confirm that manifest-sourced thresholds were applied as the manifest states. 9. Extensibility All Capsule extension points are in the Capsule JSON. The Producer Envelope protected map is exact and closed by Section 3.1. An extra protected entry is a profile failure, not an extension mechanism. New envelope metadata requires a future format version or a separate carrying structure. 9.1. 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. 9.2. 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 [RFC9901] — salted-hash commitments over JCS-canonicalized arrays — because the Capsule payload is JSON; it is written to stay aligned with SPICE's SD-CWT [I-D.ietf-spice-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 [I-D.mih-scitt-cpb-selective-disclosure]. That companion is a CPB payload-class document; the mechanism is payload-class-generic. This Mih Expires 1 March 2027 [Page 28] Internet-Draft Agent Action Capsules August 2026 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 [I-D.mih-scitt-cpb-selective-disclosure]: the extension point is defined only in that companion, and no conformance claim or verification behavior is defined for it in this document. 10. Related Work Several active individual drafts address adjacent evidence problems for AI agent actions; this profile is complementary to each. [I-D.munoz-scitt-permit-profile] defines pre-execution authorization records (Permits) that bind an allow/deny/challenge decision to the request bytes subsequently dispatched. [I-D.nivalto-agentroa-route-authorization] 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). [I-D.emirdag-scitt-ai-agent-execution] defines AgentInteractionRecords signed by an agent operator and registered with an independent evidence custodian, with redaction receipts and regulatory mappings. [I-D.kamimura-scitt-refusal-events] defines a serialization-independent claim set for AI content-refusal audit trails carried in SCITT Signed Statements; the same author's [I-D.kamimura-scitt-vcp] (VeritasChain Protocol) is a SCITT profile for verifiable audit trails in algorithmic trading — a vertical- specific application of the same transparency substrate. [I-D.kamimura-vap-framework], 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. [I-D.dawkins-scitt-ai-article50] profiles SCITT receipts for the transparency obligations of EU AI Act Article 50. [I-D.sato-soos-gar] 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. Mih Expires 1 March 2027 [Page 29] Internet-Draft Agent Action Capsules August 2026 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. [NotarizedAgents] 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 [I-D.mih-agent-bilateral-attestation] profiles the two-party extension. [I-D.mih-sato-agent-accountability-composition] defines composition and conformance rules for multi-agent accountability chains built on the same CPB derived-identifier primitive this profile uses; Capsules chained via Section 5.5.4 and bilaterally attested Capsules compose under those rules. [ERC8004] 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 ([VerifiableIntent]) 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. [I-D.rampalli-scitt-capsule-provenance-binding] 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. Mih Expires 1 March 2027 [Page 30] Internet-Draft Agent Action Capsules August 2026 11. Future Work The companion Internet-Draft [I-D.mih-agent-bilateral-attestation] 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 Section 12. The companion Internet-Draft [I-D.mih-scitt-cpb-selective-disclosure] normatively profiles the selective-disclosure extension point reserved in Section 9.2, specifying the per-field commitment structure, disclosure syntax, eligible fields, and verifier checks, aligned with [I-D.ietf-spice-sd-cwt]. 12. IANA Considerations 12.1. New registries Every registry requested below governs a vocabulary that lives entirely in the Capsule JSON. A SCITT-generic Transparency Service does not need to parse those values because registration, inclusion, and Receipt issuance operate on the separate SCITT registration statement. The media-type registrations are addressed separately in Section 12.3. This profile requests no new COSE header parameter or CWT claim registry; the new registries here are payload vocabularies only. IANA is requested to create a new registry group, "Agent Action Capsule Parameters", containing the seven registries below. The registration policy for each is Specification Required ([RFC8126], 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, Mih Expires 1 March 2027 [Page 31] Internet-Draft Agent Action Capsules August 2026 including its dispatch consequence and its effect_mode pairing under Section 5.5.2; (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 seven 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 (Section 5.5.1): 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 (Section 5.2.2); it REQUIRES effect_mode: "not_applicable" (no effect is dispatched by an administrative epoch record). 2. "disposition.decision" registry (Section 5.5): 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 (Section 5.3): write_order, send_payment. 4. "irreversibility_class" registry (Section 5.3; ordered by ascending consequence — a registration states its position): two_way, one_way_recoverable, one_way_consequential, one_way_terminal. 5. "effect_attestation" registry (Section 5.3): gate_executed, runtime_claimed. The registry definition carries the grade-floor invariant of Section 5.3 — an unregistered or unrecognized value is graded no stronger than runtime_claimed; unknown never grades up — and the planned carve of Section 5.3: 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. Mih Expires 1 March 2027 [Page 32] Internet-Draft Agent Action Capsules August 2026 6. "chain.relation" registry (Section 5.5.4): confirms, supersedes, epoch_opens. Designated-expert guidance: supersedes is the single terminal relation; confirms and epoch_opens are non- terminal relations, with epoch_opens reserved for configuration- epoch boundaries (Section 5.2.2). 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. 7. "citation_purpose" registry (Section 5.5.5): acted_on, responds_to. This registry is distinct from, and never a repurposing of, CPB's own purpose field on a typed digest reference ([I-D.mih-sokolov-scitt-payload-binding]), which selects among an artifact type's registered digest contexts and is orthogonal to any role a companion profile assigns a digest within a cross-document citation. Designated-expert guidance: both seeded values name a citation whose target is outside the citing Capsule's own chain — a different producer or a different stream (Section 5.5.5); a citation to the producer's own same- stream chain parent is never expressed here. Additional values are expected future registrations, each admitted once its semantics 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. 12.2. No new registry * Attestation/signature algorithms: this profile defines no algorithm registry; algorithm identifiers are those of the existing IANA "COSE Algorithms" registry ([RFC9053]). * Constraint id/check_type, compliance.framework_tags, and assurance.sources[].kind: no registry; governed by the namespacing convention of Section 9.1. * Producer Envelopes use only existing COSE header labels alg, content type, and kid. This document requests no new COSE header or CWT claim. Mih Expires 1 March 2027 [Page 33] Internet-Draft Agent Action Capsules August 2026 12.3. Media Type Registrations IANA is requested to register the Capsule JSON media type and the raw Capsule-ID payload media type in the "Media Types" registry per the templates below ([RFC6838]). The JSON representation uses the +json structured-syntax suffix of [RFC8259]. The raw identity payload has no structured-syntax suffix. 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 representation is JSON ([RFC8259]) as defined in this document. * Security considerations: see Section 13 of this document. * Interoperability considerations: see this document. * Published specification: this document (and its successors). * Applications that use this media type: producers, ledgers, transports, and verifiers recording and verifying AI agent actions. * Fragment identifier considerations: as for application/json ([RFC8259]) per the +json suffix ([RFC6839]). * 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. Mih Expires 1 March 2027 [Page 34] Internet-Draft Agent Action Capsules August 2026 * Change controller: Action State Group, Inc. (interim); the IETF on publication. * Provisional registration: yes (pending publication of this document). Agent Action Capsule ID media type: * Type name: application * Subtype name: agent-action-capsule-id * Required parameters: N/A * Optional parameters: N/A * Encoding considerations: binary; exactly 32 octets containing the raw SHA-256 Capsule ID represented in Capsule JSON as 64 lowercase hexadecimal characters. * Security considerations: see Section 13 of this document. * Interoperability considerations: see this document. * Published specification: this document (and its successors). * Applications that use this media type: COSE Producer Envelopes and SCITT Transparency Services registering Capsule identities. * Fragment identifier considerations: N/A. * 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. Mih Expires 1 March 2027 [Page 35] Internet-Draft Agent Action Capsules August 2026 * Provisional registration: yes (pending publication of this document). 13. 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 [I-D.mih-sokolov-scitt-payload-binding]'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 (Section 3.4) 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 (Section 5.5) 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 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 (Section 6). 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 Mih Expires 1 March 2027 [Page 36] Internet-Draft Agent Action Capsules August 2026 [I-D.mih-sokolov-scitt-payload-binding]'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 (Section 8.1), which checks that a quoted value matches its cited source, and via model_attestation (Section 5.1), 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. Capsule identity is stable across signing-key rotation. The operator and developer fields in the Capsule payload (Section 5.1) are plain strings committed to capsule_id and are independent of the signing key. Rotating a COSE signing key creates a new Producer Envelope but does not change the Capsule ID. A verifier accumulating long-horizon history SHOULD correlate Capsules by payload operator and, when present, epoch_id (Section 5.2), then apply its own authorization policy to each authenticated envelope key. A producer SHOULD treat a key rotation that coincides with a configuration change as an epoch boundary (Section 5.2.2). See also Section 14 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. Signer authorization is caller-policy territory, not Capsule or envelope cryptography. The raw public key in kid is self-attested. A verifier relying on producer identity for a policy decision MUST apply an external authorization rule to the authenticated key and MUST NOT infer authority from signature validity alone. Mih Expires 1 March 2027 [Page 37] Internet-Draft Agent Action Capsules August 2026 14. 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. 14.1. 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 (Section 9.2): 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 Section 13). 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. Mih Expires 1 March 2027 [Page 38] Internet-Draft Agent Action Capsules August 2026 14.2. 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. 15. References 15.1. Normative References [I-D.mih-sokolov-scitt-payload-binding] Mih, S. and A. Sokolov, "Canonical Payload Binding: A Signed Statement Construction Profile", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding- 00, n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Mih Expires 1 March 2027 [Page 39] Internet-Draft Agent Action Capsules August 2026 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . 15.2. Informative References [ERC8004] "ERC-8004: Agent Identity Registry", n.d., . [I-D.dawkins-scitt-ai-article50] Dawkins, V. S., "A SCITT Profile for EU AI Act Article 50 Transparency Receipts", Work in Progress, Internet-Draft, draft-dawkins-scitt-ai-article50-00, 25 May 2026, . [I-D.emirdag-scitt-ai-agent-execution] Emirdag, P., "AI Agent Execution Profile of SCITT", Work in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent- execution-00, 11 April 2026, . [I-D.ietf-cose-merkle-tree-proofs] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "COSE (CBOR Object Signing and Encryption) Receipts", Work in Progress, Internet-Draft, draft-ietf- Mih Expires 1 March 2027 [Page 40] Internet-Draft Agent Action Capsules August 2026 cose-merkle-tree-proofs-18, 2 December 2025, . [I-D.ietf-scitt-receipts-ccf-profile] Birkholz, H., Delignat-Lavaud, A., Fournet, C., and A. Chamayou, "CCF Profile for COSE Receipts", Work in Progress, Internet-Draft, draft-ietf-scitt-receipts-ccf- profile-04, 24 June 2026, . [I-D.ietf-scitt-scrapi] Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt- scrapi-11, 26 June 2026, . [I-D.ietf-spice-sd-cwt] Prorock, M., Steele, O., Birkholz, H., and R. Mahy, "Selective Disclosure CBOR Web Tokens (SD-CWT)", Work in Progress, Internet-Draft, draft-ietf-spice-sd-cwt-08, 1 June 2026, . [I-D.kamimura-scitt-refusal-events] Tokachi, K., "Verifiable AI Refusal Events using SCITT", Work in Progress, Internet-Draft, draft-kamimura-scitt- refusal-events-03, 2 August 2026, . [I-D.kamimura-scitt-vcp] Tokachi, K., "A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP)", Work in Progress, Internet-Draft, draft-kamimura-scitt- vcp-03, 21 July 2026, . Mih Expires 1 March 2027 [Page 41] Internet-Draft Agent Action Capsules August 2026 [I-D.kamimura-vap-framework] Tokachi, K., "Verifiable AI Provenance Framework (VAP): An Architectural Framework for Evidentiary-Grade AI Decision Trails", Work in Progress, Internet-Draft, draft-kamimura- vap-framework-01, 21 July 2026, . [I-D.mih-agent-bilateral-attestation] Mih, S., "Bilateral Agent Action Attestation", Work in Progress, Internet-Draft, draft-mih-agent-bilateral- attestation-00, n.d., . [I-D.mih-sato-agent-accountability-composition] Mih, S. and T. Sato, "Agent Accountability: Composition and Conformance", Work in Progress, Internet-Draft, draft- mih-sato-agent-accountability-composition-00, n.d., . [I-D.mih-scitt-cpb-selective-disclosure] Mih, S., "Selective Disclosure Profile for Canonical Payload Binding", Work in Progress, Internet-Draft, draft- mih-scitt-cpb-selective-disclosure-00, n.d., . [I-D.munoz-scitt-permit-profile] Munoz, C., "A SCITT Profile for Pre-Execution AI Action Authorization Records", Work in Progress, Internet-Draft, draft-munoz-scitt-permit-profile-01, 19 July 2026, . [I-D.nivalto-agentroa-route-authorization] Michalak, J., "Agent Route Origin Authorization (AgentROA): A Cryptographic Policy Enforcement Framework for AI Agent Actions", Work in Progress, Internet-Draft, draft-nivalto-agentroa-route-authorization-01, 15 April 2026, . Mih Expires 1 March 2027 [Page 42] Internet-Draft Agent Action Capsules August 2026 [I-D.rampalli-scitt-capsule-provenance-binding] Rampalli, K., "SCITT Capsule Provenance Binding", Work in Progress, Internet-Draft, draft-rampalli-scitt-capsule- provenance-binding, n.d., . [I-D.sato-soos-gar] Sato, "The Governance Audit Record (GAR) for Agentic AI Systems", Work in Progress, Internet-Draft, draft-sato- soos-gar-06, 25 August 2026, . [NotarizedAgents] "Notarized Agents: Decentralized, Verifiable AI Agent Receipts", 2026, . [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . [VerifiableIntent] Mastercard, "Verifiable Intent", 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. Mih Expires 1 March 2027 [Page 43] Internet-Draft Agent Action Capsules August 2026 Author's Address Steven Mih Action State Group, Inc. Email: spec@actionstate.ai Mih Expires 1 March 2027 [Page 44]