Individual Submission T. Sato Internet-Draft MyAuberge K.K. Intended status: Informational 16 September 2026 Expires: 20 March 2027 AI Audit Reference Architecture for Post-Hoc Agent Accountability draft-sato-agent-accountability-refarch-00 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. It is scoped exclusively to post-hoc accountability, as distinct from real- time enforcement, and elaborates rather than replaces the role and record-type model described in an existing individual submission on auditing agent delegation and interactions. 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 20 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Sato Expires 20 March 2027 [Page 1] Internet-Draft agnt-acct-refarch September 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Relationship to Other Work . . . . . . . . . . . . . . . 5 4. The Reference Architecture . . . . . . . . . . . . . . . . . 6 4.1. Intent and Mandate . . . . . . . . . . . . . . . . . . . 8 4.2. Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Cross-Principal Correlation (Target: Another Agent) . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Resource Ingestion Checkpoint (Target: A Passive Resource) . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Record Producer . . . . . . . . . . . . . . . . . . . . . 11 4.4. Event Log and Anchored Block . . . . . . . . . . . . . . 12 4.5. Trust Fabric . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Audit Record . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Third-Party Verification . . . . . . . . . . . . . . . . 14 5. Existing Building Blocks . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 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. Sato Expires 20 March 2027 [Page 2] Internet-Draft agnt-acct-refarch September 2026 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). 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. Sato Expires 20 March 2027 [Page 3] Internet-Draft agnt-acct-refarch September 2026 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. Other terms follow the usage of the architecture referenced in Section 3.1. 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 Sato Expires 20 March 2027 [Page 4] Internet-Draft agnt-acct-refarch September 2026 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. It 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) 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 elaborates, rather than competes with, the architecture described in an existing individual submission on auditing agent delegation and interactions [AUDIT-ARCH] ("the referenced architecture" hereafter). That document's role and record-type model -- Interaction, Action, Delegation, and Authorization Transition Records; User, Agent, and External Service/Tool as principal acting roles; an Auditing Service composed of Attestation, Audit Store, and Transparency Log -- sits one level of abstraction above the reference architecture defined in Section 4. Where the two documents describe the same mechanism at different altitudes, this document adopts the referenced architecture's terminology and defers to it on any point of conflict. Two specific alignments carry through into Section 4: Sato Expires 20 March 2027 [Page 5] Internet-Draft agnt-acct-refarch September 2026 * *The delegation-chain shape.* The referenced architecture keeps a cryptographic delegation chain inside the authorizing token (following OAuth token exchange) separate from a lightweight tracing chain carried in audit context, with a defined reconciliation path between the two. Section 4.2.1 adopts this same two-chain shape rather than choosing one representation exclusively. * *Cross-domain authorization as an enforcement-layer concern.* Existing OAuth work on preserving identity and authorization across trust domains is the likely substrate underneath the cross- principal case of Section 4.2.1. This document references that boundary rather than defining a competing one: how two independently-rooted agents actually establish a valid credential across domains is out of scope, as with any other enforcement- layer mechanism (Section 3). 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. Sato Expires 20 March 2027 [Page 6] 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 20 March 2027 [Page 7] 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 five 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. * *Correlation context*: links Mandate, intent, and resource by the shared Governed Object identifier. 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). Sato Expires 20 March 2027 [Page 8] Internet-Draft agnt-acct-refarch September 2026 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 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. Sato Expires 20 March 2027 [Page 9] Internet-Draft agnt-acct-refarch September 2026 * *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 (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. Sato Expires 20 March 2027 [Page 10] Internet-Draft agnt-acct-refarch September 2026 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. 4.3. Record Producer * *Distinct identity*: a dedicated enforcement component: not the Agent, not the Operator, not any external party. * *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 Sato Expires 20 March 2027 [Page 11] Internet-Draft agnt-acct-refarch September 2026 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. 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 to have actually happened. 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. * *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. Sato Expires 20 March 2027 [Page 12] Internet-Draft agnt-acct-refarch September 2026 * *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. 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." 4.6. Audit Record One signed, compact record per session, composed of four elements: * *Identity and linkage*: record identifier, causal-parent reference, and a monotonic per-producer sequence number. * *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. Disclosure is layered on top of composition; which reader receives which tier is chosen by declared purpose, not fixed by role identity. Sato Expires 20 March 2027 [Page 13] 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 five checks: * *Verified*: the signature cryptographically validates against a public key. Objective, offline, checkable by anyone. Sato Expires 20 March 2027 [Page 14] 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. * *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. 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. * *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 five 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. Sato Expires 20 March 2027 [Page 15] Internet-Draft agnt-acct-refarch September 2026 * A redactable content container, held separately from the ledger, referenced only by hash -- the mechanism that lets the append-only chain stay append-only while still supporting erasure obligations on content (Section 3). Full conversational capture (prompts, human approvals) belongs in a separate user-facing format, reachable from this record only by citation, never embedded. 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. 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. 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, consistent with the referenced architecture's own non-goals (Section 3.1). 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 5) 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 20 March 2027 [Page 16] 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 has been proposed in the referenced architecture (Section 3.1): replacing the tracing chain at an organizational boundary with an opaque identifier whose mapping is retained only at the originating side, following the egress-identity generalization pattern used in workload-identity work. 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 20 March 2027 [Page 17] Internet-Draft agnt-acct-refarch September 2026 Appendix A. Open Issues To be resolved or removed before further submission. Carried forward from the working document this draft is based on. * *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. * *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. * *Liveness versus progress.* The dispatch/effect split narrows but does not close the gap between "still in progress" and "silently stalled." * *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. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano Japan Email: tomsato@myauberge.jp Sato Expires 20 March 2027 [Page 18]