Network Working Group S. Mih Internet-Draft Action State Group, Inc. Intended status: Informational 31 July 2026 Expires: 1 February 2027 Agent Accountability: A Conformance and Verification Method draft-mih-agent-accountability-conformance-00 Abstract An architecture for auditing agent-driven interactions (draft- kuehlewind-audit-architecture) identifies the record types an auditable agent system produces — interaction, action, delegation, and authorization-transition — and the role of an Auditor that determines whether recorded behaviour matched intent and the authorization in force. That architecture does not specify how an Auditor, or any independent party, deterministically verifies that a set of such records — produced by different parties, in different profiles, and composed into one case — is internally consistent and correctly derives an audit conclusion. This document specifies a horizontal conformance and verification methodology for composed agent-accountability records. It organizes conformance into three tiers: the payload-binding layer, per-record- type (per-slot) conformance, and composition (combination) conformance. It defines the determinism boundary between what is mechanically derivable from the binding rules and the individual records, and what is irreducibly semantic; a conformance-vector discipline (positive, negative, and must-fail cases, checked in both directions) that any record profile reuses rather than reinvents; and a deterministic method for deriving composition-conformance vectors from binding rules, individual-record vectors, a composition manifest, and a set of cross-record predicates. The methodology is profile-agnostic: it applies uniformly to any accountability record type and to any declared composition of them, whether those records are joined across parties or across attestation layers. Its lower two tiers verify a single record, so the method applies where no composition is present and strengthens as records are composed. It is intended as the composition-verification work item of the auditing architecture — the one its enumerated work items do not yet cover. Note to Readers Mih Expires 1 February 2027 [Page 1] Internet-Draft Agent Accountability Conformance July 2026 This document is an individual submission, written as a method companion to the architecture for auditing AI agent delegation and interactions (draft-kuehlewind-audit-architecture) and to the agent- accountability composition model (draft-mih-sato-agent- accountability-composition). Discussion is invited on whatever venue is chartered for the auditing architecture work. 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 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 5 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 5 2. Relationship to Other Work . . . . . . . . . . . . . . . . . 6 2.1. Relationship to the Composition Model . . . . . . . . . . 7 2.2. Position in the Architecture's Work-Item Structure . . . 7 2.3. Mapping to Audit Record Types . . . . . . . . . . . . . . 8 3. The Three-Tier Conformance Model . . . . . . . . . . . . . . 9 Mih Expires 1 February 2027 [Page 2] Internet-Draft Agent Accountability Conformance July 2026 4. The Determinism Boundary . . . . . . . . . . . . . . . . . . 10 5. Conformance-Vector Discipline . . . . . . . . . . . . . . . . 11 6. Deriving Composition Vectors . . . . . . . . . . . . . . . . 12 6.1. Assisted Authoring (Non-Normative) . . . . . . . . . . . 13 7. Cross-Party Composition . . . . . . . . . . . . . . . . . . . 14 7.1. What a Conforming Slot Record Is . . . . . . . . . . . . 14 7.2. Slot Mappings Make Heterogeneous Profiles Comparable . . 15 7.3. Party Attribution and the Controlling Manifest . . . . . 16 7.4. The Two Cross-Party Shapes . . . . . . . . . . . . . . . 16 7.5. Relationship to the Bilateral Base . . . . . . . . . . . 17 8. Cross-Layer Composition . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. A Worked CAN-and-WHAT Composition (Informative) . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Autonomous and semi-autonomous agents increasingly take consequential actions across administrative and trust boundaries. Their behaviour is, in whole or in part, non-deterministic — driven by a model whose output cannot be reproduced by re-running it — so the record of what an agent did cannot be taken at face value, and cannot be re-derived by consulting the agent itself. The record is therefore only useful to a party who trusts neither the operator nor any single layer if that party can _verify_ it deterministically: from the bytes and the rules, reproducibly, and independently of the agent that produced it. That verification MUST be performable by a _disinterested third party_: in an adversarial dispute — where the operator, or a counterparty, has a stake in the outcome — only a record that a party with no interest can check from the bytes constitutes proof. Designing the record once for third-party verifiability is also what keeps non-repudiation cheap and on demand: a disinterested transparency receipt (the SCITT [RFC9943] model) need be obtained only when non-repudiation is actually required, rather than trusting a log continuously. That requirement — deterministic, third-party verification of an intrinsically non-deterministic producer — is what this document addresses, and it is why conformance here is defined by derivation rather than by assertion. The architecture for auditing agent delegation and interactions [I-D.kuehlewind-audit-architecture] frames this well: it identifies the record types that must be auditable, the trust mechanisms (attestation, transparency) that make individual records authentic and non-repudiable, and an Auditor whose Mih Expires 1 February 2027 [Page 3] Internet-Draft Agent Accountability Conformance July 2026 duty is to "determine whether recorded behaviour matched the User's intent and the authorization in force." What that architecture leaves open — and what its enumerated work items do not cover — is the Auditor's actual work: given records from several parties, in several profiles, referencing one another, how does an independent party _deterministically_ establish that the composition is consistent and that a stated audit conclusion follows from it, and how is an implementation of that verification _tested for conformance_? Today this is done ad hoc. Independent constructions that appear to agree turn out to agree only under unstated preconditions; aggregate dispositions are sometimes written by hand rather than derived; and conformance, where it exists at all, is asserted rather than checked. These are not hypothetical failures. They have been observed directly in cross-implementation runs against composed agent-action records — including a run in which two independently written constructions agreed on only a minority of a shared vector suite, with every divergence and every unexpected agreement attributed to a declared rule, and the residual traced to a precondition neither side had stated. Three layers divide the work. The payload-binding layer [I-D.mih-sokolov-scitt-payload-binding] defines how a record is canonicalized, digested, and referenced — the same for every record, regardless of profile. This document defines the two layers above it: how a single record of a given profile is verified (per slot), and how a _composition_ of records is verified. Composition is where the difficulty concentrates, and it concentrates in two places in particular. Records are composed _across parties_ — two organizations, each on its own stack and its own profile, meeting at a trust boundary where neither accepts the other's format — and _across the layers of one stack_ — an execution-environment attestation, a model attestation, and an action record, each independently produced and bound into one accountable statement about the same event. Both are heterogeneous by nature: the profiles and vocabularies differ, and the number of admissible combinations grows combinatorially, so composition conformance cannot be hand-authored and kept correct by inspection; it must be _derived_ from the parts. It is also continuous, not one-time: as parties revise the statements and profiles that fill their slots, the compositions that include them change, and their conformance must be _re-derived_ rather than re-asserted. Composition conformance is thus an operational property of a living system, not a certificate issued once. The single-record layer below is verified in isolation, and the method applies there too: a deployment that composes nothing still uses its lower two tiers. Mih Expires 1 February 2027 [Page 4] Internet-Draft Agent Accountability Conformance July 2026 This document specifies the missing layer: a horizontal conformance and verification methodology that sits above the payload-binding layer and is independent of any particular record profile. It is intended as the verification companion to the auditing architecture — in the terms of that document's own work-item structure, the composition-verification work item that is not yet enumerated (Section 2.2). 1.1. Scope and Non-Goals This document specifies verification and conformance for records that other layers already produce. It does NOT define identity, authorization, or delegation semantics (which are the province of the OAuth and WIMSE work the auditing architecture builds on), nor attestation of execution environments (RATS [RFC9334]), nor a transparency service (SCITT [RFC9943]), nor a new record format. Artifacts of those layers appear here only as slot contents and evidence inputs; nothing in this document modifies their semantics. It defines only how composed records are verified and how that verification is tested. 1.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. Accountability record: A signed statement, in some profile, describing one party's part of an agent action — for example an Action Record [I-D.mih-scitt-agent-action-capsule], a delegation record, or an authorization-transition record [I-D.kuehlewind-audit-architecture]. Slot: A claim type within a composition — the kind of thing a record proves (permission, delegation, conduct, enforcement). A slot is a claim type, not a deployment unit. See [I-D.mih-sato-agent-accountability-composition]. Slot semantics: The small canonical vocabulary of what a given slot may conclude, defined once, with the slot, by the composition model. See Section 7.1. Slot mapping: A registered, enumerated function from one profile's own vocabulary to the slot semantics of the slot that profile fills. See Section 7.2. Mih Expires 1 February 2027 [Page 5] Internet-Draft Agent Accountability Conformance July 2026 Composition: A set of accountability records, one or more per slot, joined by reference under a composition manifest, from which an aggregate audit disposition is derived. Composition manifest: The declared statement of what a composition requires: the required slots, which party is expected to fill each, the controlling order, the cross-party shape (Section 7.4) where slots span parties, and the total derivation function for the aggregate disposition. Conformance vector: A frozen, byte-pinned input with its expected verification result, classified positive, negative, or must-fail. Cross-record predicate: A relation that holds _between_ records and cannot be established from any single record alone (for example, that a credential subject and a protected-action actor identify the same actor). Refusal (of a verifier): The verifier outcome in which no disposition is produced and a defect is reported instead. A refusal is distinct from a mismatch (a produced result that differs from the expected one); must-fail vectors require refusal, not mismatch (Section 5). 2. Relationship to Other Work This methodology composes existing building blocks; it does not redefine them. * *Payload binding.* How any record's payload is canonicalized, digested, and referenced by another record is defined by [I-D.mih-sokolov-scitt-payload-binding] (CPB). This document assumes CPB for all binding; tier 1 of the conformance model _is_ CPB conformance. * *The auditing architecture.* [I-D.kuehlewind-audit-architecture] supplies the roles, the record types, and the Auditor whose verification this document specifies and makes testable. This document is intended to slot into that architecture as its composition-verification work item (Section 2.2). * *Record profiles.* Individual record types are defined by their own profiles — the Action Record by [I-D.mih-scitt-agent-action-capsule], user-facing interaction records by [I-D.birkholz-verifiable-agent-conversations], and others. This document defines the conformance discipline those profiles reuse, so that conformance is specified once, horizontally, rather than reinvented per record type. Mih Expires 1 February 2027 [Page 6] Internet-Draft Agent Accountability Conformance July 2026 * *Composition.* [I-D.mih-sato-agent-accountability-composition] defines _what_ composes (the slots and the join). This document defines _how_ a composition is verified and how that verification conforms. * *Transparency and attestation.* [RFC9943] and [RFC9334] make individual records non-repudiable and authentic; this document is orthogonal to and composes with both. Where the architecture profiles those substrates for auditing (its WI-6 and WI-7), this document consumes the profiled results as evidence about individual records and adds nothing to either substrate. 2.1. Relationship to the Composition Model [I-D.mih-sato-agent-accountability-composition] and this document are a matched pair: a _model_ and a _method_. That document defines _what_ composes — the slots (CAN, WHO, WHAT, AUDIT), the shared action-digest that joins them, the binding seam, and the standing invariants a conforming composition MUST preserve, among them that "two independent implementations must agree." It states those invariants; it does not specify how they are tested. This document supplies the missing _how_: the conformance-vector discipline (Section 5), the determinism boundary (Section 4), and the deterministic derivation (Section 6) that make each invariant testable and each composition vector reproducible rather than hand- authored. The cross-verification vectors already produced against that model — an authorization-record-to-action-record pair joining a CAN profile to a WHAT profile — are the first composition (tier-3) instances governed by the method defined here. The two documents evolve independently: the composition document changes _what_ composes; this document changes _how_ a composition is verified. 2.2. Position in the Architecture's Work-Item Structure Section 6 of [I-D.kuehlewind-audit-architecture] enumerates eleven potential work items, WI-1 through WI-11. Each supplies a part this document depends on or composes with, and none covers composition verification. WI-1 gives the four record types their canonical structure — the records this method verifies. WI-3, WI-4, and WI-8 profile three of the record types; in the terms of this document, their owners are tier-2 vector authors (Section 3). WI-6 and WI-7 profile the attestation and transparency substrates that make individual records authentic and non-repudiable — evidence this method consumes, not produces. WI-9 gives the Auditor a query surface over the Audit Store and Transparency Log — how the records reach the Auditor. What no enumerated item covers is what the Auditor does once the records are in hand: establishing, deterministically and testably, that the composed set is consistent Mih Expires 1 February 2027 [Page 7] Internet-Draft Agent Accountability Conformance July 2026 and that the audit conclusion follows from it. This document proposes that work item. Stated in the architecture's own work-item style: _WI-12: Composition Verification and Conformance._ A profile- agnostic method by which an Auditor (Section 4.3 of the architecture), given records of the WI-1 record types together with the receipts and attestation results that bind them, deterministically verifies cross-record consistency — binding resolution, cross-record predicates, and a controlling composition manifest — and derives the aggregate audit disposition; together with a conformance-vector discipline (positive, negative, and must-fail cases; derivation rather than assertion) by which implementations of that verification are themselves tested. This item defines no record format, no identity or authorization semantics, and no transparency or attestation mechanism; it consumes the outputs of WI-1 through WI-8 and is exercised over the access surface of WI-9. The Auditor's duty as the architecture states it — determining "whether recorded behaviour matched the User's intent and the authorization in force" — divides into a mechanically checkable part and an irreducibly semantic part. This document specifies the mechanical part and requires the semantic part to be expressed as explicitly defined predicates before it can influence a verification result (Section 4). Nothing semantic is decided implicitly. 2.3. Mapping to Audit Record Types The record types of [I-D.kuehlewind-audit-architecture] are slots in the sense of this document. Informally: Mih Expires 1 February 2027 [Page 8] Internet-Draft Agent Accountability Conformance July 2026 +=============+==========+=============================================+ |Audit |Slot |Example profile | |architecture |(claim | | |record type |type) | | +=============+==========+=============================================+ |Interaction |intent / |[I-D.birkholz-verifiable-agent-conversations]| |Record |human-in- | | | |the-loop | | +-------------+----------+---------------------------------------------+ |Action Record|conduct |[I-D.mih-scitt-agent-action-capsule] | | |(what was | | | |done) | | +-------------+----------+---------------------------------------------+ |Delegation |delegation|(per the architecture) | |Record | | | +-------------+----------+---------------------------------------------+ |Authorization|permission|(per the architecture) | |Transition |over time | | |Record | | | +-------------+----------+---------------------------------------------+ Table 1 The conformance methodology in this document is identical across these slots; only the per-slot vectors (authored by each profile's owner) differ. 3. The Three-Tier Conformance Model Conformance is organized into three tiers with distinct owners and distinct change cadences. 1. *Binding conformance (tier 1).* Does an implementation canonicalize, digest, and reference correctly? This is profile- agnostic and is defined entirely by CPB [I-D.mih-sokolov-scitt-payload-binding]. Every record, in every slot, binds the same way and is tested by the same vectors. 2. *Per-slot conformance (tier 2).* Does a record of a given profile verify correctly on its own — its own semantics and its own must- fail cases? Per-slot vectors are authored and owned by each profile's owner, using the discipline of Section 5. The registered artifacts of this tier are the profile's entry for the slot it fills and its slot mapping (Section 7.2). 3. *Composition conformance (tier 3).* Does a _declared composition_ of records verify correctly — do the cross-references resolve, do the cross-record predicates hold, and does the aggregate Mih Expires 1 February 2027 [Page 9] Internet-Draft Agent Accountability Conformance July 2026 disposition derive correctly? Tier-3 vectors are, as Section 6 specifies, _derived_ from tiers 1 and 2 plus a manifest and predicate set rather than hand-authored. Registries for the three tiers are kept distinct so that a change in one does not silently invalidate another. [Registry structure TBD in a future revision.] 4. The Determinism Boundary A precise boundary separates what a verifier can derive mechanically from what must be defined as semantics. Drawing it explicitly is the core contribution of this document. Composition verification is a function. Its inputs are: the record bytes of the composition; the composition manifest; the definitions of the cross-record predicates the manifest invokes; and a pinned snapshot of the registered artifacts in force (profiles, slot mappings, and vocabularies, each identified by version). Its outputs are the per-check results and either the derived aggregate disposition or a refusal. The function MUST be deterministic: two conforming implementations given byte-identical inputs MUST produce identical outputs. No input may be the output of a non-deterministic process evaluated at verification time; in particular, no model output enters the function except as record bytes under verification. Anything not derivable from these inputs is outside the verification result. Mechanically derivable (deterministic given the inputs): * *Binding of a composition.* Given the individual records (tier 2) and the CPB typed-reference rules (tier 1), whether each cross- reference resolves is a pure recomputation: recompute the referenced record's derived identifier and compare. Positive and negative binding vectors for a composition are generable directly. * *Aggregate disposition, given a manifest.* Given the individual records' verdicts and a composition manifest that states the required slots, the controlling order, and the derivation rule, the aggregate disposition is a pure function of those inputs. An ACCEPT disposition requires every required slot to satisfy its manifest-defined success condition; a non-success disposition may result from the failure, uncertainty, or non-eligibility of any required slot; and no single record's own verdict determines the aggregate. The signed result MUST bind the deterministic derivation, not restate a hand-written conclusion. Irreducibly semantic (must be defined, not derived): Mih Expires 1 February 2027 [Page 10] Internet-Draft Agent Accountability Conformance July 2026 * *Cross-record predicates.* Relations that exist only between slots — for example that an integrity-protected credential subject and a protected-action actor identify the same actor — are not present in any single record and cannot be derived from the slots alone. They MUST be defined. Once defined as deterministic checks, their vectors are generable. * *Slot semantics and slot mappings.* What a slot may conclude, and how a given profile's vocabulary maps onto it, are semantic declarations (Section 7). Once declared and registered, applying a mapping is mechanical. * *Preconditioned coincidences.* Two independent constructions may agree only under a stated precondition and fail silently outside it. Such a coincidence is a valid conformance claim only when expressed as a frozen vector whose preconditions are stated as explicit conjuncts and checked in both directions (see Section 5). For example, an independent construction that digests an RFC 8785 (JCS) [RFC8785] serialization under SHA-256, but does not apply an exclusion set, does not apply absent-field normalization, and does not guard against digest-bearing floating-point or out-of-safe- range integer values, coincides with the canonical construction only when a payload carries none of those cases — three conjuncts, the third of which is not implied by the first two. Stating the coincidence over positive cases alone, while a must-fail case that one side refuses and the other accepts sits within the same suite, is precisely the silent failure this discipline forbids. This is not hypothetical: it is the observed result of running an independent agent-action construction against the canonical vector suite. * *Totality of the derivation function.* A deterministic generator exists only if the aggregate-disposition function is total (defined for every combination of slot verdicts, including empty and absent required slots). Specifying that totality is semantic work. [The composition derivation function is specified as total in [I-D.mih-sato-agent-accountability-composition] in a future revision; this document depends on that property.] 5. Conformance-Vector Discipline A conformance suite for any tier obeys the following, which any record profile reuses: Mih Expires 1 February 2027 [Page 11] Internet-Draft Agent Accountability Conformance July 2026 1. *Two-sided vectors.* A suite carries positive vectors (a well- formed record MUST verify) and must-fail vectors (a specified defect MUST cause the verifier to _refuse_, not merely mismatch). A suite that checks only for mismatch would pass a verifier that never refuses anything. 2. *Attributed divergence, both directions.* Every divergence between two constructions, or between a mutated and a reference vector, MUST be attributed to a declared rule or step. An unattributed divergence is a hard failure. So too is an _agreement_ on a vector where a declared step should have changed the bytes: a silent agreement where a difference was expected is as much a failure as an unexplained difference. 3. *Mutation-probe self-test.* For each must-fail category, the suite generates the condition-removed mutant and asserts the verifier flips to failure on it. A check whose condition-removed mutant still passes is reported assertion-free and fails conformance. Every category MUST register such a probe or the suite refuses to count it as exercised. 4. *Cross-construction coincidence rule.* A claim that two constructions coincide is valid only as a frozen vector stating all preconditions as explicit conjuncts, with must-fail rows included in the biconditional check. A coincidence asserted over positive rows only is not evidence. 5. *Derived provenance.* Every frozen vector carries its provenance: the pinned inputs and rule versions it was produced from and, for derived (tier-3) vectors, the generator that produced it. An expected result is always the output of the deterministic derivation or verification of this document — never an assertion, and never the unverified output of any assisting tool (Section 6.1). 6. Deriving Composition Vectors Tier-3 vectors are a pure function of four inputs: the CPB binding rules; the individual-record (tier-2) vectors and their verdicts; a composition manifest (required slots, party attribution, shape, order, and the total derivation function); and the set of cross- record predicates. A generator over these inputs emits the combination vectors, their expected results, and their mutation probes, deterministically. When a tier-1 or tier-2 input changes, the affected composition vectors are _regenerated_, not re-authored; their provenance is the generator plus the pinned inputs. Only declared compositions (those named by a manifest) are generated; the method does not enumerate the full power set. Mih Expires 1 February 2027 [Page 12] Internet-Draft Agent Accountability Conformance July 2026 [The generation algorithm, its input schema, and the manifest format are specified in a future revision.] Appendix A walks one composition — a CAN-slot record paired with a WHAT-slot record — through the checks this method requires, with a positive, a negative, and a must-fail vector. 6.1. Assisted Authoring (Non-Normative) Enumerating the cases a suite should exercise is, in part, a judgement task — for both *per-slot semantic vectors* (tier 2: the positive, negative, edge, and must-fail cases a single profile's semantics should cover) and the *cross-record predicate library and composition vectors* (tier 3). Such candidates MAY be drafted with the assistance of automated tools, including machine-learning models, given as input the profile's registry snapshot and invariants, its enumerated must-fail categories, and the determinism boundary of Section 4. Any such candidate is only a proposal, and three closures keep it one: 1. A candidate's expected result MUST be assigned by running it through the deterministic derivation and verification of this document, and only that deterministic result is frozen as a vector. 2. A candidate on which the deterministic derivation is undefined is out of domain and MUST be rejected, not adjudicated — neither the proposing tool nor any other model may supply the missing result. 3. A vector's provenance (Section 5, rule 5) records the derivation and its pinned inputs. A vector whose expected result cannot be traced to that derivation is not a conformance vector, whatever proposed it. A model proposes candidates; the pinned rules decide. This is deliberately the same shape as the accountability records this method verifies. An agent proposes an action; a deterministic gate, or a human in the loop, disposes of it; and the disposition — not the proposal — is what is recorded and later verified. Assisted vector authoring inherits that discipline exactly: the model's proposal is never the authority, and every frozen expected result is derived or confirmed, never asserted. [Guidance on the generator inputs — the registry snapshot, the invariant set, and the must-fail taxonomy a model should be given — is expected in a future revision or companion.] Mih Expires 1 February 2027 [Page 13] Internet-Draft Agent Accountability Conformance July 2026 7. Cross-Party Composition The compositions that matter most to cross-organization auditing are those whose slots are filled by _different parties_. A bilateral exchange [I-D.mih-agent-bilateral-attestation] is the canonical case: two organizations each sign their own attestation over the _same_ action — joined, as in any composition, by the shared action-digest — and neither holds the other's records. This raises questions a single-party composition does not, and this method treats them as first-class. 7.1. What a Conforming Slot Record Is Cross-party composition turns on what "conforming" means for a slot, so this section fixes it. A record conforms to a slot when both of the following hold: 1. it is a well-formed instance of some profile _registered for that slot_, verified under that profile's own tier-2 semantics; and 2. its slot-relevant values map, under that profile's registered slot mapping (Section 7.2), to the slot's canonical semantics. The _canonical semantics_ of a slot — the small vocabulary of what that claim type may conclude — is owned by the composition model [I-D.mih-sato-agent-accountability-composition]: one vocabulary per slot, defined with the slot, never per profile. This document does not restate those vocabularies and does not depend on their particular contents; it requires only that each slot have such a vocabulary and that each profile map onto it. Illustratively, a CAN slot might conclude one of {authorized, denied, conditional} and a WHAT slot one of a verdict-complete disposition set; the authoritative vocabularies are whatever the composition model defines. Profiles and their mappings are registered per slot in the tier-2 registry (Section 3) — the single-slot registry, in the composition model's terms. [The registry structure, including the mapping entry format, is TBD alongside the registry work noted in Section 3.] "A conforming CAN," then, is not any one profile's notion of authorization; it is any registered authorization profile whose verdict maps to the shared CAN semantics — which is exactly what lets a CAN from one party compose with a differently-profiled CAN from another. Mih Expires 1 February 2027 [Page 14] Internet-Draft Agent Accountability Conformance July 2026 7.2. Slot Mappings Make Heterogeneous Profiles Comparable Two parties need not use the same profile for the same claim type — one side's authorization record may be in one profile and the other side's in another. Verifying each per its own profile (tier 2) is necessary but not sufficient: to compose, a verifier must establish that the two assert the _same thing at the slot level_, and two profiles are two vocabularies — left unreconciled, they are two languages that only appear to agree. Comparability is provided by the slot's canonical semantics together with a *slot mapping* registered by each profile. A slot mapping MUST be: * *Enumerated.* An explicit, finite list of (profile value, slot value) pairs — never computed heuristically, inferred from lexical similarity, or supplied at verification time. A profile value absent from the list is _unmapped_. * *Registered and versioned.* Part of the profile's tier-2 registry entry for the slot it fills, pinned by version in the registry snapshot that is an input to verification (Section 4). * *Frozen and tested.* A testable artifact under Section 5: positive vectors for each mapped pair, a must-fail vector for an unmapped value, preconditions stated as explicit conjuncts, and the biconditional checked in both directions including the must-fail rows. Two heterogeneous records in one slot are then compared _through their mappings into the common slot semantics_, never against each other's raw vocabulary: a verifier maps each record's slot-relevant value under that record's own registered mapping and compares the images in the slot vocabulary. All slot-success conditions in a manifest are expressed over the slot vocabulary, so the same manifest governs any admissible pairing of profiles. An _unmapped_ value fails closed at the composition tier: a value with no registered mapping is unrecognized and MUST NOT satisfy any slot-success condition, because it cannot be shown to mean what the condition requires. This is disposition-level fail-closure, and it is consistent with — not in tension with — the open-vocabulary posture of existing record profiles, under which an unknown vocabulary value is reported as an informational finding rather than invalidating the record. The two rules govern different tiers: an unmapped value does not make the record non-conforming at tier 2, and it does not contribute success at tier 3. Unknown is tolerated as content and rejected as evidence; unknown never grades up. Mih Expires 1 February 2027 [Page 15] Internet-Draft Agent Accountability Conformance July 2026 Profile heterogeneity across parties is thus permitted — and made _verifiable_ — by the slot mapping, not by forcing every party onto one profile. 7.3. Party Attribution and the Controlling Manifest Two further rules apply when slots span parties: * *Slots may be attributed to distinct parties.* A composition manifest MAY state which party is expected to fill which slot. The shared action-digest is what makes the cross-party join verifiable without either party's cooperation at verification time. * *The parties may hold different manifests.* When each side has its own view of what the composition requires, the _controlling_ manifest MUST be identified, and it is an input to verification — never an output. A verifier MUST NOT let a party unilaterally satisfy a required slot the controlling manifest attributes to the counterparty, nor treat a slot absent on one side as satisfied because the other side supplied a different one. Reconciling divergent manifests is a cross-record predicate (Section 4) and MUST be stated, not assumed. 7.4. The Two Cross-Party Shapes Two cross-party _shapes_ are distinguished, because they compose differently and MUST NOT be silently interchanged: * *Mutual attestation — a common understanding.* Each party attests its own side and, through the slot mappings, is verified to understand the other's; together they form a joint record both are bound to — in effect a contract about what happened. The aggregate disposition is _joint_: it derives from both parties' slots under the controlling manifest, and the completed acknowledgment pair of the bilateral exchange (Section 7.5) binds each party to the other's attestation. Graceful-degradation and reduced-assurance markings carried by the underlying exchange are preserved into the derivation as inputs, never discarded or upgraded. Mih Expires 1 February 2027 [Page 16] Internet-Draft Agent Accountability Conformance July 2026 * *Cross-organization acknowledgment.* A party records that it observed or acknowledged the _other_ party's action, without forming a mutual contract. This is the weaker binding, and deliberately so: consistent with the bilateral exchange's definition of acknowledgment as receipt rather than assent, the acknowledgment is a cross-record predicate over the counterparty's record, but it does not, by itself, make the acknowledging party co-responsible for a disposition it did not assert. The shape is declared by the controlling manifest and is an input to the derivation function; a verifier MUST NOT infer the shape from the records themselves. A manifest that requires mutual attestation is not satisfied by an acknowledgment, however well-formed: a verifier presented with acknowledgment-shape records under a mutual- attestation manifest MUST treat the mutual-attestation slots as unsatisfied. The two shapes derive different aggregate dispositions from the same underlying action, which is precisely why substituting one for the other must be structurally impossible rather than merely discouraged. 7.5. Relationship to the Bilateral Base The bilateral attestation exchange [I-D.mih-agent-bilateral-attestation] is the base this section builds on, and this document changes nothing in it: the four-move exchange (request attestation, constraint evaluation, action attestation, acknowledgment), the binding obligations, the acknowledgment-is- receipt semantics, and the reduced-assurance marking are used as defined there. The correspondence is direct: a completed bilateral exchange — both attestations, both acknowledgments — is the canonical instance of the mutual-attestation shape, and an acknowledgment without a counterpart attestation instantiates the acknowledgment shape. Where that exchange degrades gracefully, the reduced- assurance indicator it records enters the derivation here as a slot input; this document adds no second marking scheme. What this section adds is one generalization, at the composition tier only: the two sides of an exchange MAY fill their slots with _different registered profiles_, reconciled through the slot semantics and slot mappings of Section 7.2 rather than required to share a vocabulary. Where both sides use the base exchange's shared disposition vocabulary, both mappings are the identity and this section adds nothing — the homogeneous case is the special case, not the rule. Heterogeneous parties are the general case this method is built for. Mih Expires 1 February 2027 [Page 17] Internet-Draft Agent Accountability Conformance July 2026 Run-time protocols that reconcile heterogeneous per-party attestations into a single disposition are consumers of this method: the reconciled result is itself a composition, conformant only if it derives from the parties' records under a stated controlling manifest and the predicates above. [The manifest-reconciliation rules and the reduced-assurance composition cases are specified in a future revision.] 8. Cross-Layer Composition The cross-party compositions of Section 7 join records held by different _parties_. A second axis joins records produced at different _layers_ of one party's stack: an execution-environment attestation (RATS [RFC9334], the auditing architecture's WI-6), a model or reasoning attestation, and the action record [I-D.mih-scitt-agent-action-capsule] a party emits for the same action. Each is a distinct claim about the same event — the environment it ran in, the model that produced the proposal, and what was ultimately done — and each is produced and signed independently. This is composition in exactly the sense of this document. The layer records are joined by the shared action-digest and an aggregate disposition is derived from them under a manifest, using the same determinism boundary (Section 4), the same conformance-vector discipline (Section 5), and the same derivation (Section 6) as any other composition. The layer attestations enter only as slot contents and evidence inputs; this document adds nothing to RATS or to any attestation format, exactly as Section 2 states. What it adds is the ability for an independent party to verify not merely that an agent took an action, but that it did so _on an attested environment, with an attested model_ — a deeper accountability claim, checkable down to the layer that produced it. Cross-layer composition is deliberately independent of whether any cross-party or cross-profile composition is present. A single party whose stack is one coherent profile still composes these layers, and this method verifies that composition without requiring a second party or a second profile. Where the architecture profiles the attestation and transparency substrates (its WI-6 and WI-7), this work item is what binds their results to the WI-1 record types and derives a disposition over the bound set. [A manifest profile for the environment/model/action layers is specified in a future revision.] Mih Expires 1 February 2027 [Page 18] Internet-Draft Agent Accountability Conformance July 2026 9. Security Considerations The verification specified here inherits, and does not replace, the authenticity and non-repudiation properties of the underlying attestation [RFC9334] and transparency [RFC9943] layers. A verifier MUST fail closed: an unrecognized or unestablished value MUST NOT satisfy a predicate or slot-success condition required for a successful disposition (Section 7.2). Because the manifest and the registry snapshot are inputs to verification (Section 4), substituting either substitutes the verification result; a manifest or snapshot MUST therefore be identified by digest in any signed verification result, so that two parties disputing a disposition can first establish whether they verified against the same inputs. Shape substitution — presenting acknowledgment-shape records against a mutual-attestation requirement — is prevented structurally by Section 7.4. [Full threat model, including manifest substitution and predicate-omission attacks, TBD in a future revision.] 10. Privacy Considerations Conformance vectors are synthetic by construction and carry no production content. Verification operates over digests, not payloads, and therefore inherits the content-privacy posture of the record profiles it checks. [Correlation considerations for composition manifests TBD.] 11. IANA Considerations This document will request registries for cross-record predicates and for composition manifests in a future revision. This -00 has no IANA actions. 12. References 12.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- 01, 27 July 2026, . Mih Expires 1 February 2027 [Page 19] Internet-Draft Agent Accountability Conformance July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [I-D.birkholz-verifiable-agent-conversations] Birkholz, H., Heldt, T., and O. Steele, "Verifiable Agent Conversation Records", Work in Progress, Internet-Draft, draft-birkholz-verifiable-agent-conversations-00, 25 February 2026, . [I-D.kuehlewind-audit-architecture] Kühlewind, M. and H. Birkholz, "An Architecture for Auditing AI Agent Delegation and Interactions", Work in Progress, Internet-Draft, draft-kuehlewind-audit- architecture-00, 18 May 2026, . [I-D.mih-agent-bilateral-attestation] Mih, S., "Bilateral Attestation of Cross-Organization Agent Actions", Work in Progress, Internet-Draft, draft- mih-agent-bilateral-attestation-01, 19 July 2026, . [I-D.mih-sato-agent-accountability-composition] Mih, S., Sato, Bu, S., and I. Schrock, "Agent Accountability: Composition and Conformance", Work in Progress, Internet-Draft, draft-mih-sato-agent- accountability-composition-00, 5 July 2026, . [I-D.mih-scitt-agent-action-capsule] Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- capsule-02, 6 July 2026, . Mih Expires 1 February 2027 [Page 20] Internet-Draft Agent Accountability Conformance July 2026 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [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, . Appendix A. A Worked CAN-and-WHAT Composition (Informative) This appendix walks one two-slot composition through the checks this method requires. It is synthetic: the profiles, vocabularies, and values are invented for this appendix and carry no production content. The composition follows the CAN/WHAT seam of [I-D.mih-sato-agent-accountability-composition]: a pre-action authorization record (CAN slot) is cited by digest from a post-action record (WHAT slot). *Slot semantics* (illustrative; the authoritative vocabularies are the composition model's): the CAN slot concludes one of authorized, denied, conditional; the WHAT slot concludes one of the verdict- complete dispositions, of which this example uses executed and blocked. *Profiles and mappings* (tier-2 registry entries): * Profile can-x fills the CAN slot. Its own verdict vocabulary is {granted, rejected, granted_with_conditions}; its registered slot mapping is the enumerated list: granted maps to authorized, rejected maps to denied, and granted_with_conditions maps to conditional. * Profile what-y fills the WHAT slot. Its own outcome vocabulary includes {completed, refused}; its registered slot mapping sends completed to executed and refused to blocked. *Manifest* M-1: required slots CAN and WHAT; CAN is the parent (controlling order: the WHAT record cites the CAN record); a single party fills both slots, so the cross-party rules of Section 7 are not exercised here; one cross-record predicate, P-1; derivation function Mih Expires 1 February 2027 [Page 21] Internet-Draft Agent Accountability Conformance July 2026 D: the aggregate disposition is accept if and only if the binding check, P-1, and both slot-success conditions hold, where CAN slot success is authorized and WHAT slot success is executed; every other defined combination derives a named non-accept disposition attributing the earliest failed check. D is total over slot verdicts, including absent slots. *Predicate* P-1 (same actor): the byte string in the CAN record's subject field equals the byte string in the WHAT record's actor field. (A deliberately minimal identity rule; a real predicate library would define equality with more care. The point is that the rule is stated, deterministic, and checked — not assumed.) *Records* (payload sketches; digests abbreviated): can-record (profile can-x) what-record (profile what-y) { { "subject": "agent-7", "actor": "agent-7", "action_digest": "5f8a...", "action_digest": "5f8a...", "verdict": "granted", "outcome": "completed", ... "authority": { } "type": "can-x", "digest_alg": "SHA-256", CANONICAL-DIGEST(can-record) "digest": "c41d..." = "c41d..." }, ... } *The verification walk*, in order: 1. _Binding check (tier 1)._ Recompute the CAN record's derived identifier under its registered digest context (CPB [I-D.mih-sokolov-scitt-payload-binding]) and compare it with the digest carried in the WHAT record's authority typed reference. 2. _Per-slot checks (tier 2)._ Each record verifies under its own profile's semantics and must-fail categories. 3. _Mapping check._ Map each record's slot-relevant value under its registered slot mapping; an unmapped value fails closed (Section 7.2). 4. _Predicate check._ Evaluate P-1 over the two records. 5. _Aggregate derivation._ Apply D to the mapped slot verdicts and check results; compare the derived disposition with the vector's frozen expected result. Mih Expires 1 February 2027 [Page 22] Internet-Draft Agent Accountability Conformance July 2026 *Three vectors* derived from these inputs: +========+====================+====================================+ | Vector | Contents | Expected result | +========+====================+====================================+ | V-POS | Records as above: | Derivation yields accept; every | | | granted / | check attributed | | | completed; binding | | | | digest matches; | | | | P-1 holds | | +--------+--------------------+------------------------------------+ | V-NEG | Identical, except | Non-accept disposition attributed | | | authority.digest | to the binding check (step 1); | | | carries the | later checks still evaluate, per | | | derived identifier | D's totality | | | of a _different_ | | | | CAN record | | +--------+--------------------+------------------------------------+ | V-MF | Identical to | The verifier _refuses_: it reports | | | V-POS, except the | the unmapped token and produces no | | | CAN verdict is | accept; the CAN slot-success | | | approved — a token | condition is unsatisfiable | | | with no entry in | (Section 7.2). A run that instead | | | can-x's registered | produced a disposition merely | | | mapping | mismatching the expected one would | | | | fail the suite | +--------+--------------------+------------------------------------+ Table 2 *Mutation probes* (rule 3 of Section 5): for V-MF, the condition- removed mutant replaces approved with granted; the verifier MUST flip to accept on the mutant, demonstrating that the refusal was caused by the unmapped token and not by an unrelated defect. For V-NEG, restoring the correct digest must likewise flip the result to accept. *Both directions* (rule 2): a second, independent implementation run over the same three vectors must agree on all three results; any divergence must be attributed to a declared rule, and an agreement on a vector where a declared step should have changed the outcome — for example, both implementations accepting V-MF — is equally a hard failure. Everything in this walk is a pure function of the pinned inputs: the two records' bytes, M-1, P-1, and the registry snapshot carrying the two profiles and their mappings. Regenerating the three vectors from those inputs reproduces them byte-for-byte; that reproduction, not this prose, is their provenance. Mih Expires 1 February 2027 [Page 23] Internet-Draft Agent Accountability Conformance July 2026 Acknowledgments This work builds on the architecture for auditing agent delegation and interactions [I-D.kuehlewind-audit-architecture] and composes with the SCITT, RATS, and agent-accountability communities. Cross- implementation conformance runs by independent implementers surfaced the precondition and hand-written-disposition failure modes this document is designed to make impossible. Author's Address Steven Mih Action State Group, Inc. Email: spec@actionstate.ai Mih Expires 1 February 2027 [Page 24]