Agent Accountability: A Conformance and Verification Method
draft-mih-agent-accountability-conformance-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Steven Mih | ||
| Last updated | 2026-07-31 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mih-agent-accountability-conformance-00
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, <https://datatracker.ietf.org/doc/html/
draft-mih-sokolov-scitt-payload-binding-01>.
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
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, <https://datatracker.ietf.org/doc/html/
draft-birkholz-verifiable-agent-conversations-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
audit-architecture-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-mih-agent-
bilateral-attestation-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-mih-sato-
agent-accountability-composition-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-mih-scitt-
agent-action-capsule-02>.
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,
<https://www.rfc-editor.org/rfc/rfc8785>.
[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, <https://www.rfc-editor.org/rfc/rfc9334>.
[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,
<https://www.rfc-editor.org/rfc/rfc9943>.
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]