Agent Accountability: A Conformance and Verification Method

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

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

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

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

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

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 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):¶

• 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:¶

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

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

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

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

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

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

Three vectors derived from these inputs:¶

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

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