Individual Submission T. Sato Internet-Draft MyAuberge K.K. Intended status: Informational 21 September 2026 Expires: 25 March 2027 AI Audit Reference Architecture for Post-Hoc Agent Accountability draft-sato-agent-accountability-refarch-01 Abstract This document defines a reference architecture for producing, protecting, and verifying post-hoc accountability records for the actions of autonomous and semi-autonomous software agents, built from evidence captured across an action's full lifecycle -- before, during, and after it executes -- but assessed after the fact. It is scoped exclusively to post-hoc accountability, as distinct from real- time enforcement, and depends on no other individual submission's proposed architecture: everything it requires is either an already- settled standard, used as published, or intended to be specified and released openly as the author's own work, independent of this document's own adoption. It defines seven ordered stages -- intent and mandate capture, the agent boundary, the record producer, the event log and its cryptographic anchoring, a composed trust fabric, the disclosed audit record, and third-party verification -- together with two branch conditions covering cross-principal transactions and external resource ingestion. 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 25 March 2027. Sato Expires 25 March 2027 [Page 1] Internet-Draft agnt-acct-refarch September 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Relationship to Other Work . . . . . . . . . . . . . . . 6 4. The Reference Architecture . . . . . . . . . . . . . . . . . 7 4.1. Intent and Mandate . . . . . . . . . . . . . . . . . . . 9 4.2. Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Cross-Principal Correlation (Target: Another Agent) . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. Resource Ingestion Checkpoint (Target: A Passive Resource) . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Record Producer . . . . . . . . . . . . . . . . . . . . . 12 4.4. Event Log and Anchored Block . . . . . . . . . . . . . . 14 4.5. Trust Fabric . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Audit Record . . . . . . . . . . . . . . . . . . . . . . 16 4.7. Third-Party Verification . . . . . . . . . . . . . . . . 18 5. Existing Building Blocks . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 Sato Expires 25 March 2027 [Page 2] Internet-Draft agnt-acct-refarch September 2026 1. Introduction Autonomous and semi-autonomous software agents increasingly act on behalf of users and organizations, often across administrative domains and without direct human oversight at each step. When such an action later needs review -- by an operator, a regulator, or an affected party -- there is today no interoperable way to produce a record of what happened that a party outside the agent's own operator can verify without taking that operator's word for it. Four properties of agentic systems, largely absent from the systems traditional audit logging was designed for, motivate the structure defined in this document: * *Non-deterministic behavior.* A conventional system executes a given input the same way every time, so auditing it reduces to confirming it did what its code specifies. An agent can legitimately produce different outputs from the same inputs. "Did it do the right thing" is therefore not answerable by comparison against a fixed expected trace; it requires comparing an honestly pre-declared intent and expected outcome against what actually happened (Section 4.1). * The actor is not a reliable witness to itself. A conventional system's logs are typically produced by the process performing the action, and this has usually been a safe assumption. An agent whose own behavior is the subject of scrutiny cannot be its own witness, which motivates a record producer structurally distinct from the agent (Section 4.3) and boundary-observed, rather than agent-reported, tool and service call records (Section 4.2). * Recursive, sometimes cross-organizational, machine-speed delegation. A conventional transaction has one actor under one clear grant of authority. An agent may spawn sub-agents needing narrower authority than their parent, and may transact with agents run by an entirely different organization sharing no trust root (Section 4.2.1) -- a case with no close analogue in pre-agent systems, where the equivalent handoff was usually mediated by a human negotiating a contract rather than an automated, machine- speed exchange requiring its own correlation mechanism. * The record must survive a reader who trusts no participant. Agentic decisions increasingly need to be defensible to a regulator or counterparty with no independent way to evaluate an opaque, fast-moving process. What was actually committed, tamper- evidently, before or during the action is the only thing such a reader can rely on (Sections 4.5 through 4.7). Sato Expires 25 March 2027 [Page 3] Internet-Draft agnt-acct-refarch September 2026 1.1. Requirements Language 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. This document is Informational; normative language below expresses design requirements for a conforming implementation of this architecture, not IETF standards-track conformance. 2. Terminology Agent: a software workload acting on behalf of a Principal, potentially delegating to sub-agents or invoking tools and external resources. Principal: the human or organization an Agent acts for. Mandate: the specific authorization basis and its scope under which an Agent or its delegate acts. Governed Object: the specific resource instance a Mandate names. Record Producer: a dedicated enforcement component, distinct from the Agent and the Operator, responsible for generating Audit Records. Anchored Block: a set of Event Log entries grouped at a trigger point into a signed, tamper-evident structure. Audit Record: a compact, signed, disclosure-scoped record summarizing one session, recomputable from its underlying Event Log. Coverage: a verification property establishing that no record was suppressed, checkable only via a counterparty's independently held evidence. Tamper-evident: a record is checkable by a party who does not trust the Agent that produced the underlying action -- not merely internally consistent by the Agent's or the Record Producer's own account. An Agent's log of its own actions can be internally consistent and still be false: consistency is a property the Agent controls, checkability by an independent party is not. Sato Expires 25 March 2027 [Page 4] Internet-Draft agnt-acct-refarch September 2026 Other terms are used in their ordinary sense, or defined at first use in Section 4. 3. Scope Auditing an agent's behavior splits into two problem classes with different failure modes, different real-time constraints, and different owners. Enforcement decides whether an action MAY proceed, in real time, on the critical path, and cannot tolerate latency. Post-hoc accountability -- record definition, correlation, and reconstruction -- is inherently after the fact and MAY be off the critical path. *This document's scope is post-hoc accountability only.* Enforcement -- the policy language, the evaluation engine, the mandate/authorization-token format itself -- is the responsibility of adjacent work that already owns it. Referencing the shape of an authorization artifact (for example, whether it binds to a resource instance or a resource category) is in scope; defining that artifact's wire format is not. Two concrete cases are worth stating plainly, since both arise naturally while specifying delegation (Section 4.2) and are easy to mistake for this document's problem: enforcing a mandate's ceiling across an entire delegation tree rather than per edge, and preventing a descendant from acting during the window between a parent mandate's revocation and that revocation's actual propagation. Both are real- time decisions about whether an action may proceed and are therefore out of scope. This document's role with respect to both is limited to specifying that a revocation-propagation window is itself a recordable fact, not to preventing exploitation of that window. Scope begins when an interaction establishes or relies on a security- relevant relationship within a foundational protocol's defined boundary, and a correlation context is created linking the actor, the authority, the intended action, and the supporting evidence. This starting point is about when evidence capture begins, not when enforcement happens: this document does not decide whether the interaction may proceed at this point or any other. See Section 4's opening for why capturing evidence before an action executes is still "post-hoc" in what it accomplishes. Scope ends when the interaction reaches a recorded outcome -- completion, denial, failure, cancellation, timeout, revocation, an accountable handoff, or an explicitly marked erasure-unresolved state (see the Open Issues appendix) -- and the available evidence has been correlated and preserved for reconstruction. Two forces are in tension throughout this document: the need for tamper-evident, third-party-verifiable evidence, and privacy principles (data minimization, purpose limitation, erasure rights) Sato Expires 25 March 2027 [Page 5] Internet-Draft agnt-acct-refarch September 2026 that presume records can be limited or removed. This document does not resolve that tension; it states it explicitly wherever it bears on a design choice below. 3.1. Relationship to Other Work This document reuses existing, already-settled work exactly as published -- RATS, COSE, SCITT, and OAuth's cross-domain identity- chaining work (below) -- rather than depending on any other individual submission's proposed architecture, however closely related. Two reasons. First, this document intends to be directly implementable now, not contingent on another document's own adoption timeline. Second, no existing implementation of any standard cited here needs to change on this document's account: everything is used as already specified, and anything new that this document requires is either specified in Section 4 below or intended to be built and released openly as the author's own work, separately from this document. An existing individual submission on auditing agent delegation and interactions [AUDIT-ARCH] addresses closely related ground -- a role and record-type model (Interaction, Action, Delegation, and Authorization Transition Records; an Auditing Service composed of Attestation, Audit Store, and Transparency Log) at a similar level of the problem. This document does not adopt that model's terminology or defer to it: the two are independent treatments of the same problem space, developed separately, and cited here as related work rather than as a dependency this document's own claims rest on. Where the two documents' conclusions converge, that convergence is noted below as evidence the underlying requirement is real, not as a citation either document's claims rest on. The delegation-chain shape adopted in Section 4.2.1 does not require any specific existing specification. An implementation represents the two chains however its own credential and tracing formats already do, exactly as Section 4.2.1's own text states -- "whatever cryptographic delegation chain the enforcement layer already carries." This same two-layer shape independently appears in the related submission above, which this document takes as convergent evidence the pattern is sound in general, not evidence tied to any one implementation. Sato Expires 25 March 2027 [Page 6] Internet-Draft agnt-acct-refarch September 2026 How two independently-rooted agents in Section 4.2.1's cross- principal case actually establish a valid credential across administrative domains in the first place is out of this document's scope, same as any other enforcement-layer mechanism (Section 3): existing OAuth work on preserving identity and authorization across trust domains is the likely substrate, and this document references that boundary rather than defining a competing one. This document does not attempt a full survey of adjacent IETF activity. The Open Issues appendix notes specific points where independent work elsewhere has reached the same conclusion as a claim made here, or has identified a gap this document shares without yet closing it. 4. The Reference Architecture Seven ordered stages, plus two branch conditions evaluated within Stage 2. Several stages below capture information before an action executes. This capture is not enforcement -- this document does not decide whether an action proceeds based on it; that decision belongs to the adjacent, excluded enforcement layer (Section 3). Pre-action capture exists so that the post-hoc judgment is possible at all: "post-hoc" describes when accountability is assessed -- by comparing what was honestly declared in advance against what the record shows actually happened -- not when evidence capture begins. Sato Expires 25 March 2027 [Page 7] Internet-Draft agnt-acct-refarch September 2026 +----------------------------+ | 4.1 Intent and Mandate | +-------------+--------------+ | v +----------------------------+ +---------------------------+ | 4.2 Agent |-->| 4.2.1 Cross-Principal | | (branches on call target) | | Correlation (-> agent) | | | +---------------------------+ | | | | +---------------------------+ | |-->| 4.2.2 Resource Ingestion | +-------------+--------------+ | Checkpoint (-> resource) | | +-------------+-------------+ v | +----------------------------+ | governed | 4.3 Record Producer | | artifact +-------------+--------------+ | | | v | +----------------------------+ <----------------+ | 4.4 Event Log and | | Anchored Block | +-------------+--------------+ | v +----------------------------+ | 4.5 Trust Fabric | +-------------+--------------+ | v +----------------------------+ | 4.6 Audit Record | +-------------+--------------+ | v +----------------------------+ | 4.7 Third-Party | <-- 4.2.1 rejoins here (Coverage) | Verification | +----------------------------+ The solid path is the default sequence a governed action follows end to end. The branch conditions are not alternative architectures: both fire from the same event -- an outbound call crossing the Agent's own boundary at Stage 4.2 -- and both rejoin the solid path rather than terminating separately. The resource-ingestion branch (4.2.2) rejoins at the Event Log (4.4), since a Governed Artifact it produces becomes ordinary Event Log content for the Agent's Sato Expires 25 March 2027 [Page 8] Internet-Draft agnt-acct-refarch September 2026 subsequent actions. The cross-principal branch (4.2.1) rejoins specifically at the Coverage check within Third-Party Verification (4.7), because Coverage is the only one of the six verification checks whose behavior differs between the single-producer and two- party cases. 4.1. Intent and Mandate Scope begins here. Three of four intent-to-result fields are captured before the action happens; the fourth, actual result, is captured only after (Section 4.6). * *Mandate*: binds authority to a specific resource _instance_, not a resource _category_. Instance binding is what makes cross- component correlation checks, revocation scope, and provenance chains resolvable by direct lookup rather than reconstruction. * *Governed Object*: the specific resource instance the Mandate names. This identifier MUST match, unaltered, across the Mandate, the declared intent, and the eventual Audit Record. * *Declared intent*: goal, reasoning basis, and a confidence level, committed before the action executes. * *Expected outcome*: an acceptance envelope for what counts as success, endorsed by the enforcement component before the session begins, not merely declared by the Agent unilaterally. This is what makes non-deterministic agent behavior auditable: outcome variation alone is not suspicious; what is checkable is whether the actual result, once known, diverges from an expected outcome honestly declared in advance. The expected outcome MUST also declare a confirmation window: the interval within which an observed effect (Section 4.4) is expected to arrive. A dispatched attempt with no observed effect inside its declared window becomes a first-class, alarmable state, distinguishing a session that is genuinely still in progress from one that has silently stalled -- a distinction the dispatch/effect split alone does not provide. Declaring a window does not fully resolve this: a window set too generously reintroduces the ambiguity it is meant to remove, and this document does not yet specify how a conforming implementation should choose one. * *Correlation context*: links Mandate, intent, and resource by the shared Governed Object identifier. Sato Expires 25 March 2027 [Page 9] Internet-Draft agnt-acct-refarch September 2026 Mandate, intent, and expected outcome MUST be recorded as separate fields rather than collapsed to one terminal outcome, so a reader can later distinguish an authorization failure (intent exceeded mandate) from an execution failure (result diverged from a properly-in-scope expected outcome). Binding a pre-declared constraint set to the specific action later verified against it is a gap independently named in adjacent authorization-layer work: existing grant mechanisms are not generally described as providing a standard way to bind previously-approved constraints to the concrete action performed later and verify that relationship at execution time. This document's answer sits at the evidence layer (capture before, prove against after) rather than the grant layer (bind before, enforce at issuance) -- a different trust root and a different consumer, complementary rather than competing. 4.2. Agent The Agent is not trusted, and every other property of this stage follows from that fact. * *Workload identity*: short-lived and never a bearer credential. The Agent's identity for correlation purposes MUST be a stable identifier distinct from the signing key that authenticates any single credential, not the key itself. A key-derived identity breaks exactly when short-livedness requires it to work: routine key rotation would otherwise mint what looks like a new actor each time, orphaning the audit trail's continuity at precisely the moments -- credential renewal, key hygiene -- that are supposed to be unremarkable. * *Delegation*: downscoped at every hop, never simply forwarded, with each hop cryptographically accountable rather than accountable only by convention. This document does not prescribe the specific mechanism (see the Open Issues appendix): whether consent (an actor affirming its own participation and the terms it was bound to) and provenance (which party added that actor to the chain) are represented as one combined proof or two independent ones is presently unsettled in adjacent authorization-layer work; this document requires only that both be recoverable at each hop. A sub-agent is positional, not categorical -- it is any agent invoked by another agent -- so this requirement applies recursively at every level of a delegation tree. Two further properties are required of a delegation tree specifically, as distinct from a single edge. A Mandate's ceiling enforcement is an enforcement-layer concern out of scope here (Section 3), but sibling delegations acting on the same or Sato Expires 25 March 2027 [Page 10] Internet-Draft agnt-acct-refarch September 2026 overlapping resources are in scope: two individually-valid sibling actions with jointly conflicting effects raise exactly the precedence-versus-correspondence question resolved generically in Section 4.7's Ordering check. A causal-parent identifier chain that is otherwise sound does not, by itself, establish which sibling's effect took precedence when two conflict. A recorded, append-only delegation chain faithfully records history but does not, by itself, prove that history is still true: the parent credential a chain entry points to can itself be revoked, expired, or compromised after the entry was recorded -- a "parent-swap" condition an append-only record cannot reveal on its own. Verification MUST re-check the parent credential's own current signature and status at every use, not only at the point a chain entry was originally recorded; trusting a previously- recorded entry as a substitute for live re-verification reintroduces exactly the gap the chain's own signatures were meant to close. * *Tool and service calls*: the boundary at which a tool or service is invoked MUST record the canonical request as observed at that boundary, not as reported by the Agent. An Agent recording itself can produce useful telemetry but cannot, by itself, deliver non-repudiation to a third party, which is why Section 4.3 requires a record producer structurally separate from the Agent. At each outbound call from this stage, a branch condition applies: is the target another agent, or a passive resource? 4.2.1. Cross-Principal Correlation (Target: Another Agent) A further branch: do both agents trace to the same root Principal, or to independent roots? * *Same root*: the single producer chain continues unchanged. Coverage (Section 4.7) is satisfied trivially, since there is only one producer to reconcile against. * *Independent roots*: forks into two full, symmetric instances of Sections 4.3 through 4.6, one per party, joined by a *correlation artifact* jointly derived so that neither party could produce it alone. As discussed in Section 3.1, this artifact is the tracing- layer counterpart to whatever cryptographic delegation chain the enforcement layer already carries in the authorizing credential; this document adds correlation and reconciliation on top, not a competing chain. Two outcomes are possible: mutual attestation Sato Expires 25 March 2027 [Page 11] Internet-Draft agnt-acct-refarch September 2026 (both sides confirm) or a gracefully degraded, one-sided record (one side could not attest, marked explicitly rather than blocking the transaction). Either outcome establishes correspondence between the two chains, not precedence (Section 4.7). Both outcomes rejoin at the Coverage check in Section 4.7. 4.2.2. Resource Ingestion Checkpoint (Target: A Passive Resource) Before an Agent may act on data pulled from an external resource: 1. The resource MUST already have declared its trust level and capability class, independently attested, before any assignment is made. 2. The raw retrieval -- the API call, the query, the sensor poll -- happens outside enforcement mediation, the same way any other tool use does; it is not proxied. 3. The enforcement component MUST re-validate the resource's _current_ trust level, not a value cached from discovery, and the record's well-formedness, in full, before any commit begins. 4. Only then does the content become a *Governed Artifact*, referenced by hash, with its content stored separately from the governance chain. This checkpoint does not assess whether the retrieved data is good -- only whether the resource it came from meets the governance bar. Data quality is out of scope, by the same reasoning that separates "was this authorized and evidenced" from "was it a good decision" throughout this document. This gate governs retrieval, but a resource under a trust or access boundary can leak information about itself through paths other than retrieval -- a search, an existence check, a relevance score, or an index entry can reveal that a governed resource exists, or how well it matches a query, to a principal who could never pass this checkpoint to actually retrieve it. Any such secondary path MUST be subject to the same trust-level gate as retrieval itself; gating only the eventual read leaves exactly this class of leak open. 4.3. Record Producer * *Distinct identity*: a dedicated enforcement component: not the Agent, not the Operator, not any external party. Sato Expires 25 March 2027 [Page 12] Internet-Draft agnt-acct-refarch September 2026 * *Non-delegable ordering*: confirmation that a session closed MUST NOT be returned before that session's record has actually committed. This is an ordering guarantee, not an eventual- consistency promise. Five distinct trigger classes generate a record, with genuinely different real-time constraints: +=================+===========================+================+ | Trigger | Constraint | Reader-facing? | +=================+===========================+================+ | Self-audit | Continuous, after every | No | | | internal state commitment | | +-----------------+---------------------------+----------------+ | Session-close | Unconditional, atomic, | Yes | | | every close reason | | +-----------------+---------------------------+----------------+ | Event-triggered | Synchronous, before any | Yes | | | response returns | | +-----------------+---------------------------+----------------+ | Scheduled / | Time- or population- | Yes | | cross-session | scoped | | +-----------------+---------------------------+----------------+ | On-demand | Grant-bound window, | Yes | | external | closes at expiry | | +-----------------+---------------------------+----------------+ Table 1: Record Trigger Classes Event-triggered's synchronous property is easy to misread as an enforcement-path property; it is not. The record write blocking the response concerns when evidence commits, not whether the action is permitted -- that decision occurs in the excluded authorization layer. Self-audit records are not disclosed to any of the six reader roles defined in Section 4.6; they exist solely to catch the producer's own internal inconsistencies. That does not make them optional or low-stakes. A detected inconsistency -- a state transition with no corresponding intent declaration, a resolved escalation with no recorded trigger, a reference to authority that does not exist in the mandate store -- MUST produce an immutable anomaly entry, and that entry MUST immediately raise an alert at the highest defined severity to every party positioned to intervene. The entry MUST NOT be suppressible by the producer that generated it. A self-audit mechanism that detects an inconsistency and only logs it, without a mandatory, non-suppressible escalation path, is indistinguishable from not having one: the signal existing somewhere in a store nobody is required to check is the exact failure this trigger class exists to prevent. Sato Expires 25 March 2027 [Page 13] Internet-Draft agnt-acct-refarch September 2026 This requirement has a bootstrap problem worth naming explicitly: if the condition triggering the anomaly is itself a failure of the signing or producer infrastructure, the alert this section requires may be exactly what that infrastructure can no longer produce. A conforming implementation MUST provide a separate, out-of-band notification path -- one that does not depend on the same signing capability the anomaly may have compromised -- for exactly this case, rather than allowing the escalation requirement above to silently fail closed when it is needed most. *Unavailability*: every trigger class above assumes the producer, and wherever it commits to, can actually be reached. A conforming implementation MUST declare, in advance, what happens when that assumption fails -- whether the agent halts (fail-closed), continues without a record (fail-open), or buffers locally pending recovery -- and MUST NOT leave this behavior undefined. Fail-open without a stated fallback is the same silent gap as an unescalated self-audit anomaly: an undetectable failure mode dressed up as normal operation. Buffering, if chosen, does not exempt the buffered record from the non-delegable ordering guarantee above once the producer recovers -- a buffered record is not yet committed in the sense that guarantee requires, and a session MUST NOT be reported as closed while its evidence sits unresolved in a buffer. A declared buffering period MUST pause the confirmation window's clock (Section 4.1) for the duration the producer is buffering, resuming only once buffering ends. Without this rule, a producer correctly following its own declared fallback can trigger a false "silently stalled" finding for a session that is, in fact, behaving exactly as this section specifies -- two individually correct mechanisms producing a false alarm in composition, confirmed directly against sample code before being stated as a requirement here. 4.4. Event Log and Anchored Block The producer's own local, append-only log holds the actual action content -- what the Agent did -- distinct from what gets attested about it. Each entry keeps two facts separately rather than collapsing them: * *Dispatched attempt*: what the producer attempted. * *Observed effect*: what was confirmed, independently of the Agent's own report, to have actually happened. Confirmation that only reads the Agent's own claim about what it did is not confirmation -- it is the same self-witnessing problem Section 4.2 already rules out for tool calls, recurring here in a different form. The observing party MUST be positioned to read the affected Sato Expires 25 March 2027 [Page 14] Internet-Draft agnt-acct-refarch September 2026 surface directly (the tool's own response, the resource's own resulting state), not merely to relay what the Agent asserts about it. These MAY legitimately diverge without either being wrong: a session can dispatch a completion attempt and never receive effect confirmation before timeout. This is not an inconsistency to resolve; it is the case this split exists to surface rather than silently collapse into a single ambiguous "timeout." At a trigger point, entries are grouped into an *Anchored Block*: a span-level hash chain within the session, plus a session-level root and signature, using separate key material for each layer so that forging one does not permit repairing the other. 4.5. Trust Fabric Three distinct mechanisms, composed in a specific order, not merged into one signed structure: * *Attestation*: establishes ongoing trust in the signing key's custody. This is periodic, not re-run per record. Trust-anchor lifetime and rotation MUST be considered separately from, and on its own schedule independent of, leaf signing-key rotation (Section 4.2): a compromised anchor can validate forged material for as long as the anchor itself remains trusted, regardless of how short-lived the leaf keys it vouches for are. A conforming implementation MUST also state explicitly which key-material philosophy it follows for the Record Producer's own signing key -- ephemeral, per-ceremony keys that bound a compromise to a single attestation, or long-lived, hardware-anchored keys with a threshold scheme to bound compromise blast radius -- rather than leaving the choice implicit. Neither approach is wrong; leaving the choice unstated is. * *Signing*: covers each Anchored Block as a whole, using whichever key attestation has vouched for. * *Local commit*: writing the signed block to the producer's own log. This satisfies the non-delegable ordering guarantee of Section 4.3 -- fast, with no network dependency. * *Registration*: submitting the block, or a checkpoint over several blocks, to a transparency service, on a declared cadence, batched rather than per-record. This provides _external_ non-repudiation and MUST NOT be conflated with the internal ordering property above. Sato Expires 25 March 2027 [Page 15] Internet-Draft agnt-acct-refarch September 2026 A verifier arriving inside the gap between local commit and external registration sees something real but not yet provable by the Existence check (Section 4.7) -- not a suppression indicator, provided the gap stays within the declared cadence. The cadence itself MUST be a declared, committed value, or a verifier cannot distinguish "not yet registered, normally" from "suppressed." *Where the data actually lives, stated in one place*: three tiers, not one. The event log (Section 4.4) is local to the producer and never leaves it directly; the Anchored Block, once signed, is committed locally first and registered externally second, on the declared cadence above -- two copies existing at two different times, not one; and full conversational content (prompts, human approvals) is held in a redactable container held separately from all of the above (Section 4.6), referenced from the Audit Record only by hash, never embedded in it. An implementation that can point to exactly these three storage locations, and explain why content is split across them this way, has answered this question completely. One that stores everything in a single undifferentiated store has not -- even if every other requirement in this document is met, because that single store cannot support Section 4.6's redaction guarantee without also breaking the Event Log's append-only property. 4.6. Audit Record One signed, compact record per session, composed of five elements: * *Identity and linkage*: record identifier, causal-parent reference, and a monotonic per-producer sequence number. * *Audience binding*: the specific counterparty, transaction, or presentation context the record is valid evidence _for_, carried under the signature, not left to an out-of-band comparison the relying party performs on its own. A Mandate scoped correctly at authorization time (Section 4.1) does not, by itself, prevent a fully valid record from being replayed against the wrong counterparty later, or a typed value (an amount, a quantity) from being read against the wrong unit -- both are failures of what the record asserts about itself when presented as evidence, not failures of what the Mandate authorized. Where a value in the record has a unit or type that matters to its meaning, that unit or type MUST be carried under the signature alongside the value, not left implicit. Omitting audience binding is a legitimate implementation choice under resource constraints, but it MUST be stated as a limitation, not left for a relying party to discover by omission. Sato Expires 25 March 2027 [Page 16] Internet-Draft agnt-acct-refarch September 2026 * *Intent-to-result linkage*: the actual-result field, written here, alongside references back to the Mandate, intent, and expected outcome from Section 4.1. * *Terminal disposition*: a pair, not a single field -- the dispatched-attempt and observed-effect facts from Section 4.4, carried forward rather than collapsed. Every disposition, including refusals, timeouts, and denials, is recorded with equal weight to a success. * *Recomputable summary*: any exposed aggregate MUST be re-derivable by a reader from a declared selection and a declared derivation over the underlying Event Log, never accepted as an unverified claim. *Redactable Content Container*: full conversational content -- prompts, human approvals, and similar material not required by the five elements above -- MUST NOT be embedded directly in the Audit Record. It MUST instead be held in a separate user-facing container, distinct from the Event Log and the Anchored Block, referenced from the Audit Record only by hash. This separation exists so that erasure obligations reaching this content can be satisfied by removing it from that separate container without altering -- and therefore without invalidating -- the signed Audit Record or the tamper-evident chain it is part of. Removing content from the container MUST NOT be treated as removing the record of its own prior existence: the hash reference, and the fact that a reference existed, remain part of the tamper-evident chain even after the referenced content is gone. Deleting content from the container MUST require an identifiable, checkable authority -- an unauthenticated deletion capability defeats the same accountability property this architecture requires of every other consequential action. The deletion act itself MUST produce its own entry in the tamper-evident chain, recording that the referenced content was removed, by what authority, and when -- not the deleted content itself, only the fact and provenance of its removal. An erasure of evidence is, by the same reasoning that governs everything else in this document, exactly the kind of action that must remain accountable rather than exempt. Disclosure is layered on top of composition; which reader receives which tier is chosen by declared purpose, not fixed by role identity. Sato Expires 25 March 2027 [Page 17] Internet-Draft agnt-acct-refarch September 2026 +===================+===============================+ | Tier | When used | +===================+===============================+ | Digests-only | Integrity check only | +-------------------+-------------------------------+ | Derivation-scoped | Exactly the declared field | | | set a named computation needs | +-------------------+-------------------------------+ | Full | The rare exception | +-------------------+-------------------------------+ Table 2: Disclosure Tiers Six structurally separate reader roles are defined, with enforced separation of duties (the Witness never holds content; the auditor never holds signing keys; no entity holds both the escalation- resolver and internal-auditor roles on the same session): 1. Internal auditor -- broad, read-only. 2. Escalation resolver -- scoped strictly to the specific request being resolved. 3. External/regulatory auditor -- time- and scope-limited, receives a compiled package, never raw store access. 4. Counterparty -- the other side of a two-party interaction (Section 4.2.1); produces its own independent signed half. 5. Principal -- exercises an export right over its own record. 6. Witness -- countersigns log commitments; proves append-only, unforked history; holds no record content and cannot prove completeness alone. Any evidence request has exactly three possible outcomes, and a reader MUST be able to tell them apart: the artifact; a signed refusal with a stated reason; or a recorded absence (asked, no answer within the window). Absence MUST NOT be inferred as refusal, and a refusal is an answer, not an error. 4.7. Third-Party Verification A skeptical verifier, trusting neither the Agent nor the Operator, runs six checks: * *Verified*: the signature cryptographically validates against a public key. Objective, offline, checkable by anyone. Sato Expires 25 March 2027 [Page 18] Internet-Draft agnt-acct-refarch September 2026 * *Accepted*: the relying party additionally trusts that the key belongs to the claimed principal, via out-of-band pinning. A relying-party decision, never a property of the record itself. A valid signature proves Verified and never implies Accepted. * *Bound*: the record's audience-binding field (Section 4.6), if present, names _this_ counterparty and _this_ transaction, not merely some counterparty and some transaction. This is a distinct outcome from Verified: a record can be fully Verified and still be Unbound, in two different ways a relying party MUST be able to tell apart. If the field is present and names a different counterparty or a conflicting typed value, that is a positively identified conflict -- refuse and register the conflict. If the field is absent entirely, that is unsupported association -- the record cannot confirm the binding, but it has not contradicted it either, and there is nothing to fail on. Collapsing these two into one "verification failed" outcome discards the second case entirely: a relying party told only "not bound" cannot distinguish a record that actively lies about its counterparty from one that was simply never asked to say. * *Existence*: the record is registered and unaltered since receipt. Proves registration timing and tamper-freedom after that point; proves nothing about content truth, signer-identity legitimacy, or completeness. * *Coverage*: nothing was suppressed, within a declared boundary. That qualifier is not optional: Coverage only means something once a deployment has declared which record types it commits to producing at all. A missing record for a type never declared in scope means _not observed_, not _nothing happened_ -- the two are indistinguishable without the declaration, and reading an undeclared gap as a suppression finding is a category error, not a stricter check. Checkable only via the counterparty's own independently held half (Section 4.2.1); the Witness alone cannot establish this. Coverage is role-gated by construction -- not available to internal auditor, escalation resolver, or Principal, none of whom hold an independent second half. The declared-scope requirement above has a real, confirmed evasion path this document does not yet close: an operator who wishes to suppress an entire record type without detection can simply never declare that type as in scope, since anything undeclared is exempt from Coverage scrutiny by the mechanism's own construction. Sample-code testing confirms this directly -- Coverage cannot distinguish a genuinely absent record type from one an operator has deliberately excluded from its own declaration. This document does not yet specify a mechanism making the declared scope itself Sato Expires 25 March 2027 [Page 19] Internet-Draft agnt-acct-refarch September 2026 externally checkable or resistant to after-the-fact narrowing; the fix that makes Coverage meaningful within a declared boundary is what creates this gap at the boundary's own edge. A gap in a monotonic sequence is not, by itself, a suppression finding: a transient gap (a higher sequence number already observed, a lower one still pending -- a legitimate concurrent- session race) is a different condition from a persistent one that survives a reasonable observation window. Only the latter should be read as evidence of suppression; treating every gap as suppression on sight makes Coverage unusable in any system with concurrent sessions. Two further precisions, both easy to get wrong when implementing sequence-based gap detection. First, a refusal or other terminal disposition with no downstream counterpart (Section 4.6) is not a gap: authorization-stage and execution-stage records MUST be counted on separate sequences, or every legitimate refusal reads as a missing execution record on a shared counter, producing exactly the false suppression-finding this check exists to avoid. Second, sequence-gap detection only catches a drop _inside_ a stream that continues afterward -- it cannot detect a stream truncated at its tail, since no later record exists to reveal the absence. Detecting tail-truncation requires an independent time anchor over the stream (a declared attestation that the stream was live as of some point, checkable against elapsed time since), which this document does not yet specify. This is a real, acknowledged gap in Coverage as defined here, not an oversight to be quietly assumed closed. A sharper, adversarial version of the same gap is worth naming separately: a truncated stream is not always simply absent afterward -- it can be replaced with a same-length fork, a fabricated continuation whose sequence numbers and count are indistinguishable from what a genuine continuation would have produced. A time anchor confirming the stream was live as of some point does not, by itself, rule this out: a substitution timed to land before that anchor is checked can satisfy it while presenting fabricated content in place of the true continuation. Chain integrity (are these records internally consistent) and completeness (is this the actual, sole continuation, not one of several equal-length candidates) are therefore separate properties, and this document does not yet specify a mechanism for the second beyond what Ordering (below) already provides between two specific, named records. Sato Expires 25 March 2027 [Page 20] Internet-Draft agnt-acct-refarch September 2026 * *Ordering*: precedence, not mere correspondence, between two records requires either a single record whose boundary spans both terms and establishes their order, or two related records tied together by a trusted sequencing mechanism between them. Agreement absent either structure is correspondence only. This is the same requirement governing the cross-principal case (Section 4.2.1) and the sibling-delegation case (Section 4.2). Verification does not adjudicate whether a record's content is good news. A record can pass all six checks and still show a dispatched attempt with no observed-effect confirmation; this is not a verification failure, it is the correctly recorded case the dispatch/ effect split (Section 4.4) exists to surface. 5. Existing Building Blocks * *RATS* [RFC9334]: attests the record producer's own execution environment, distinct from attesting the Agent whose action is recorded. * *COSE*: the signing format for the Anchored Block. * *SCITT* [SCITT-ARCH]: transparency and non-equivocation for registered blocks. Still an evolving specification as of this writing; the composition in Section 4.5 does not depend on any detail beyond registration, receipts, and a declared registration policy. * *OTel*: a plausible source for the event-level detail an Anchored Block groups together, if an observability-native construction is preferred over a bespoke one. * A redactable content container, referenced only by hash and held separately from the tamper-evident chain -- defined normatively in Section 4.6, not here, since it is this document's own architectural pattern rather than a reused external standard. 6. Security Considerations The threat model underlying this document treats the Agent as untrusted (Section 4.2) and the Operator as not fully trusted (hence a Record Producer structurally distinct from both, Section 4.3). No single Verifier or Transparency Service is assumed sufficient; a conforming deployment SHOULD re-appraise Evidence against independent Reference Values, register records to more than one Transparency Service where feasible, and treat Coverage (Section 4.7) as requiring genuinely independent counterparty evidence rather than a second copy from the same operator. Sato Expires 25 March 2027 [Page 21] Internet-Draft agnt-acct-refarch September 2026 Every check in Section 4.7 that touches a signature -- Verified, Accepted, and by extension Coverage -- ultimately rests on an assumption this document does not itself examine: that resolving a public key to a named principal is backed by some enrollment guarantee. What that guarantee must consist of is, as of this writing, independently described elsewhere as an unstated, catalogue- level gap inherited by any mechanism in this space rather than solved individually. This document's Accepted/Verified split names the seam where the gap bites; it does not close it. Implementers and reviewers should treat any claim of "verified identity" in a conforming record with this gap in mind. The same unexamined- assumption pattern applies one level up when a Mandate names a human Principal as the root of its own authority (Section 4.1): this document assumes that root authority is simply given, and says nothing about how a human principal's own authority is itself established and verified before a Mandate can be issued on its behalf. This is a distinct gap from key-to-principal enrollment, not a restatement of it, and is equally unresolved here. Section 4.2's boundary-observed recording (a tool or service call boundary records what it observed, not what the Agent claims) and Section 4.5's Trust Fabric both quietly assume something this document has never stated: that the boundary doing the observing, and the environment producing the signed record, are themselves intact. If an Agent can escape its own isolation and reach the infrastructure responsible for observing or signing its actions, the entire tamper- evidence chain built on that observation inherits the compromise silently -- a corrupted observer produces a perfectly well-formed, correctly signed, internally consistent record of something that did not happen as recorded. This is a different threat than an Agent lying about itself, which Section 4.2 already defends against; it is the observer being the compromised party, not the subject. This document has been treating the Record Producer's environment as trustworthy by assumption, the same way an isolation boundary is often treated as a solved problem by the systems built on top of it. That assumption should be stated rather than left implicit, and the audit infrastructure itself -- not only the Agent under audit -- belongs on the list of things a threat model considers a possible attack target, not only the thing the model exists to hold accountable. This document does not yet specify a defense; naming the precondition precisely is the first step, and is deliberately left as that first step rather than padded out with a mechanism that hasn't been validated. Declared intent (Section 4.1) is a distinct attack surface from the dispatch/observed-effect split, and this document has not previously named it as one. An Agent can misrepresent its own stated goal or Sato Expires 25 March 2027 [Page 22] Internet-Draft agnt-acct-refarch September 2026 reasoning as easily as it could misreport an action's effect -- the dispatch/effect split (Section 4.4) defends against the second; nothing here yet defends against, or even names, the first. Where a Mandate's expected outcome (Section 4.1) is derived by translating a higher-level instruction through the Agent itself, and a human confirmation is used as a control on that translation, the confirmation SHOULD bind cryptographically to a digest of what was actually rendered to the approver, not merely to a reference to a Mandate object that could point to different content by the time it is inspected. Records this document specifies may need retention well beyond any single signing key's or algorithm's expected service life, given the privacy and regulatory tensions named in Section 7. A conforming implementation MUST plan for signature and algorithm agility over a retained record's full lifetime rather than binding it permanently to whatever algorithm family was current at the time of signing; this document does not itself specify a migration mechanism, only the requirement that one exist. This document is silent on denial-of-service as its own named category, consistent with a gap already visible in adjacent architecture-level work in this space, but that consistency does not make the gap acceptable on its own terms. Beyond the delegation- depth ceiling already named as unresolved in the Open Issues appendix, this document does not address whether expensive verification work (Section 4.7) can be forced by trivially malformed input ahead of any cheap structural check, nor whether a Record Producer or its registration target can be driven to exhaustion by an adversary rather than by ordinary load. Both are left as open, unaddressed questions rather than assumed solved by implication. This document does not solve, and does not attempt to solve: an adversarial component that refuses to record what happened at its own boundary; collusion across every defined role simultaneously; or the correctness of the Agent's own decision-making. These are stated as explicit non-goals. 7. Privacy Considerations Two forces are in tension throughout this document (Section 3): tamper-evident evidence, and privacy principles including erasure rights. The redactable content container (Section 4.6) is this document's primary mitigation, keeping the append-only integrity chain free of content that might need later removal. It is not a complete answer: The Open Issues appendix notes an unresolved "erasure-unresolved" disposition state and the harder problem of erasure obligations reaching into live, pinned execution state. Sato Expires 25 March 2027 [Page 23] Internet-Draft agnt-acct-refarch September 2026 Correlation metadata is a separate privacy concern from record content. Even hash-only records can leak workflow existence, size, and participant identity across organizational boundaries via trace- ID continuity or the delegation chain itself. A candidate mechanism exists in WIMSE's own egress-identity generalization pattern: replacing the tracing chain at an organizational boundary with an opaque identifier whose mapping is retained only at the originating side. This document does not yet adopt that mechanism as a requirement. 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC9334] Birkholz, H., Ed., Thaler, D., Ed., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . 9.2. Informative References [AUDIT-ARCH] Kuehlewind, M. and H. Birkholz, "An Architecture for Auditing Agent Delegation and Interactions", 2026, . [SCITT-ARCH] IETF SCITT Working Group, "An Architecture for Trustworthy and Transparent Digital Supply Chains", 2026, . Sato Expires 25 March 2027 [Page 24] Internet-Draft agnt-acct-refarch September 2026 Appendix A. Open Issues This list has grown since the initial submission, and it will likely continue to. That growth is a direct, traceable result of feedback from people implementing against this problem in production -- several items below cite a specific, real failure someone has actually hit -- and should be read as evidence this document is doing its job, not as evidence of regression. Where this revision closed a previously-listed item by adopting it as a normative requirement elsewhere in this document, that item has been removed from this list rather than left here in a resolved state. * *Ordering's two acceptable structures (Section 4.7) have no worked example yet.* Belongs in a future worked-examples deliverable. At least one execution-time authorization-evidence mechanism proposed elsewhere has been described by its own author as not closing this gap either -- independent confirmation the gap is real. * *Coverage's tail-truncation and same-length-fork limitation (Section 4.7) is stated but not closed.* Sequence-gap detection only catches a drop inside a stream that continues afterward; it cannot detect a stream truncated at its tail, and a truncated stream can in principle be replaced with a fabricated, same-length continuation that a naive time anchor would not rule out. This document does not yet specify a mechanism for detecting either case. * *The confirmation window declared in Section 4.1 has no specified sizing guidance.* A window set too generously reintroduces the ambiguity between "still in progress" and "silently stalled" that declaring one is meant to remove. This document requires that a window be declared; it does not yet say how a conforming implementation should choose one. * *Evidence requirements are satisfiable by the cheapest artifact that passes them, not necessarily by the work itself.* An evidence gate defined as "a non-empty output exists" can be satisfied by an empty or trivial change wrapped in enough structure to pass the check, without the underlying work having occurred. This is a different failure from a dispatched-but-unconfirmed action (Section 4.4): here the record is fully present, correctly formed, and passes every stated check, and still does not reflect that the work was done. This document does not yet require that an evidence gate be paired with an adversarial test asserting the cheapest known bypass is rejected, though implementation experience shared in adjacent discussion confirms this is a real, observed failure mode, not a hypothetical one. Sato Expires 25 March 2027 [Page 25] Internet-Draft agnt-acct-refarch September 2026 * *Whether the originating, unmediated user request is its own field, distinct from Mandate and Declared Intent (Section 4.1).* What a user actually asked for is not always identical to what they were subsequently permitted, and the latter -- narrower, and set at a different moment -- is what matters when a decision is later disputed. Section 4.1 currently captures Mandate (the authorization basis) and Declared Intent (the Agent's own stated goal), but neither is quite the same thing as the user's own original, unmediated request. Whether this needs a third, separate field, or is already adequately reachable through Mandate once that field is used precisely, is not yet resolved here. * *Erasure-unresolved as a disposition state* is not yet added to the outcome vocabulary in Section 3. * *Erasure reaching into live, pinned execution state* -- whether a third release class belongs in this document or a deployment/ retention deliverable is undecided. * *Delegation depth, narrowed.* Sibling-delegation conflicts are closed (folded into Section 4.2 as an Ordering instance). Tree- wide ceiling enforcement and revocation-propagation timing are out of scope by Section 3; specifying that a propagation window is itself a recordable fact is in scope and not yet done. The specific cryptographic mechanism for per-hop accountability remains unsettled in adjacent work. * *Correlation-metadata leakage* -- candidate mechanism identified (Section 7), not yet adopted as a requirement. * *Signature-to-principal binding ("enrollment")* -- named in Section 6, not closed. * *Human-authority root bootstrapping* -- named in Section 6 as a distinct gap from key-to-principal enrollment: this document assumes a human Principal's own root authority is simply given, and does not address how that authority is itself established and verified before a Mandate can be issued on its behalf. * *Denial of service* -- named in Section 6, not closed beyond the delegation-depth ceiling already listed above. Whether expensive verification work can be forced ahead of cheap structural checks, and whether a Record Producer or its registration target can be driven to exhaustion deliberately rather than by ordinary load, are both open. Sato Expires 25 March 2027 [Page 26] Internet-Draft agnt-acct-refarch September 2026 * *Coverage's declared-scope evasion (Section 4.7)* -- confirmed directly via sample-code testing: an operator can exclude an entire record type from Coverage scrutiny simply by never declaring it in scope, since undeclared types are exempt from suppression detection by the mechanism's own design. This document does not yet specify a way to make a declared scope itself externally checkable or resistant to after-the-fact narrowing. * *Formal, tool-based verification has not been performed on this architecture* and should be, at a point where practitioners with direct, hands-on experience running these tools are available to do it -- this is not a gap to close with an unguided first attempt. Two candidate targets are already visible from the informal testing done so far, named here as a starting point for whoever takes this on: the Record Producer's confirmation-window and buffering interaction (Sections 4.1/4.3), a stateful process where hand-written scenario testing already found one composition bug, suggesting a model checker (e.g., TLA+) exploring the full reachable state space could find others a limited, hand-written scenario set would miss; and the delegation chain's causal-parent and sequence-number structure (Sections 4.2/4.6), a relational- structure question suited to a tool such as Alloy -- for example, whether two sessions could ever be assigned the same sequence number, or a causal-parent chain could ever form a cycle. Neither target has been modeled; both are named as informed starting points, not as findings. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano Japan Email: tomsato@myauberge.jp Sato Expires 25 March 2027 [Page 27]