Network Working Group B. B Internet-Draft 11 AI Blockchain Developments LLC Intended status: Informational 13 August 2026 Expires: 14 February 2027 Signed Decision Records for Agent Authorization: Disclosures, Entry Emission, and Ordering Evidence draft-bradleyb-audit-decision-records-00 Abstract Audit systems for autonomous agents commonly record the actions an agent performed. This makes the non-occurrence of a permitted action unrepresentable: when nothing happens, there is no action to emit anything. This document describes an evidence model that records the authorization decision rather than the action. A decision exists whether or not the action follows, so denials, expiries, and commitments that were granted and never honoured remain representable. The document defines four disclosures that make a decision record independently evaluable, an entry-emission rule for states a relying party may need to reason about, and the evidentiary basis for claims that a decision preceded its effect. It distinguishes correspondence, where two records agree about what happened, from precedence, where the order of decision and effect is established, and it requires records to state which of the two they carry. About This Document This note is to be removed before publishing as an RFC. This document consolidates positions developed in discussion on the agent2agent and agentproto mailing lists during 2026, in preparation for the proposed AUDIT working group. It is an individual submission. 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/. B Expires 14 February 2027 [Page 1] Internet-Draft Decision Records August 2026 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 14 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Decision Records . . . . . . . . . . . . . . . . . . . . . . 4 4. The Four Disclosures . . . . . . . . . . . . . . . . . . . . 5 4.1. What the Signature Binds . . . . . . . . . . . . . . . . 5 4.2. What Establishes Order, and From Which Boundary . . . . . 5 4.3. Whether the Producer Also Enforces . . . . . . . . . . . 5 4.4. What the Deadline Derives From . . . . . . . . . . . . . 6 5. Entry Emission . . . . . . . . . . . . . . . . . . . . . . . 6 6. Ordering Evidence: Correspondence Is Not Precedence . . . . . 7 6.1. The Causal Route . . . . . . . . . . . . . . . . . . . . 7 6.2. The Temporal Route . . . . . . . . . . . . . . . . . . . 8 6.3. The Disclosure Consequence . . . . . . . . . . . . . . . 8 7. Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Intellectual Property Notice . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 B Expires 14 February 2027 [Page 2] Internet-Draft Decision Records August 2026 1. Introduction Autonomous and semi-autonomous software agents act on behalf of users and organizations across administrative and trust boundaries. Interoperable auditing for such systems is under discussion in the IETF, including a proposed architecture [I-D.kuehlewind-audit-architecture] with deliverables covering an auditing architecture and audit data models. Most deployed audit instrumentation is event-sourced from the action: a record is produced when something happens. This placement has a structural consequence. It cannot represent the non-occurrence of a permission, because when the permitted action never occurs there is no action to emit anything. One cannot audit for the non-occurrence of a permission the way one audits for the violation of a prohibition. The gap is a consequence of where the instrumentation sits rather than a limit on what audit can represent. Event-sourcing the authorization decision instead of the action removes it: a decision exists whether or not the action follows. A denial is an event. An expiry that returns resources is an event. A grant honoured and closed cleanly is an event, if the thing recorded is the decision rather than its effect. This document describes the resulting evidence model, drawn from the operational experience of a fail-closed authorization control plane that emits a signed decision record for both allowed and denied actions, and from convergent findings reported independently by other implementers on the agent2agent mailing list. It is offered as input to the audit data model and architecture work. 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. 2. Terminology Decision record A signed artifact emitted by an authorization point at the time a decision is taken, for both allow and deny outcomes. B Expires 14 February 2027 [Page 3] Internet-Draft Decision Records August 2026 Declaration A statement, made before execution, of what is expected or permitted to happen, including any rules from which operational parameters such as deadlines are derived. Disposition record An artifact describing the standing or outcome of a commitment, emitted at entry into a state rather than only at termination. Effecting side The system that performs the action a decision permits. The effecting side may be in a different trust domain than the authorization point. Fail-closed plane A deployment in which the decision point and the enforcement point are the same component, so that the effect cannot be reached except through the decision. Advisory deployment A deployment in which the decision point does not enforce, and the effecting side may act regardless of the decision. Correspondence Agreement between two records about what happened, for example matching hashes over the same content. Precedence An established ordering between a decision and its effect. 3. Decision Records An authorization point conforming to this model emits a signed decision record for every decision, on both the allow and the deny path. The deny path deserves emphasis because it is the one nobody instruments. Systems keep what happened. Very few keep what was refused, and almost none sign it. In practice denials are the records most often needed and least often retained. A conforming authorization point MUST retain and sign denial records with the same integrity protection as allow records. A denial that holds is the clean case for ordering, since there is no effect for its record to be ordered against, but only when fail- closed operation is enforced rather than declared. In an advisory deployment of the same data model the assumption that the effect did not happen anyway is not checkable, and the deny record inherits the B Expires 14 February 2027 [Page 4] Internet-Draft Decision Records August 2026 full ordering problem of Section 6. Any treatment of the deny path MUST ride together with the fail-closed versus advisory distinction, or the clean case will be claimed by deployments it does not describe. 4. The Four Disclosures A decision record is independently evaluable only if it carries, or its governing declaration carries, four disclosures. Each disclosure exists because its absence produces a claim that appears stronger than it is, and the weakness is invisible unless someone asks the question the disclosure answers. 4.1. What the Signature Binds A signature produced at decision time attests to what was decided. A signature produced at retrieval time attests that the ledger says this now. These are different claims, and a record MUST state which one its signature makes. A pre-declared expectation compared against a record signed after the fact is a weaker claim than it appears, and hash-chain integrity over the ledger does not repair it: a chain orders what it covers, and cannot order against an effect the chain does not see. 4.2. What Establishes Order, and From Which Boundary The record MUST state what establishes the order of the decision against the effect, and whether that mechanism sits inside the same trust boundary as the record's producer. A record minted by the authorizing side establishes at most when it was signed, not that the signing preceded an effect that side never observes. The acceptable forms of ordering evidence are given in Section 6. 4.3. Whether the Producer Also Enforces The record MUST state whether its producer is also the enforcement point. In a fail-closed plane the decision point and the enforcement point are the same component, and several ordering properties hold by construction. In an advisory deployment they do not, and a record that is silent on this distinction invites the stronger reading. B Expires 14 February 2027 [Page 5] Internet-Draft Decision Records August 2026 4.4. What the Deadline Derives From Where a decision or commitment carries a deadline, the deadline MUST be disclosed as a derivation rather than an absolute. A deadline stated as an absolute timestamp is unfalsifiable: no evaluator can check it against the workload it governs. A deadline stated as a rule, for example a multiple of a declared expected duration against stated variance assumptions, can be evaluated before anything runs. Routing protocols use this shape already: a dead interval derived as a stated multiple of a hello interval, a holdtime negotiated as a multiple of a keepalive. The derivation rule belongs in the declaration, where it is falsifiable as a design choice before execution. The instantiation, what the expected duration was taken to be for this case and what the rule therefore produced, belongs in the disposition record, where it is falsifiable precisely against the single case. The asymmetry is load-bearing: an instantiation with no prior rule cannot be distinguished from a justification written by the party it excuses, after the outcome was known. The rule MUST predate the run for the instantiation to mean anything. The consequence of a deadline shorter than the completable lifetime of the work it governs is not neutral noise. Measurement reported on the agent2agent list showed such a horizon right-censoring roughly three quarters of long-running work, with the bias concentrated on the parties holding the longest commitments. Carried into audit, that turns normal operation into a stream of apparent violations, which is worse than no deadline because it looks like evidence. 5. Entry Emission An enumerated set of terminal dispositions cannot cover a state that never terminates. A record emitted at termination produces nothing when nothing terminates, and silence from the committing party is then indistinguishable from a commitment legitimately in progress. The general rule is: Every state a relying party may need to reason about MUST have an artifact emitted at entry into that state. Silence after an entry artifact is then a standing claim, attributable to a named party, that the state persists. Silence with no artifact is the ambiguity itself. This is the same discipline that motivates recording the decision rather than the action, generalized to every state the model names: a decision exists whether or not the action follows, and a hold exists whether or not it resolves. B Expires 14 February 2027 [Page 6] Internet-Draft Decision Records August 2026 Entry emission deliberately does not fold liveness into the record. Requiring periodic re-emission would make absence mean two things at once, a resolved state whose resolution was lost or a failed party, and the record's meaning would then depend on an availability property. Liveness of the committing party is a separate mechanism at whatever layer already knows whether the party is reachable, with its own interval and failure semantics. One residue is stated here rather than left to be discovered. A party that enters a state, emits truthfully at entry, and makes no progress is indistinguishable from one that is working. Entry emission converts silence into an attributable claim; it does not establish that the claimed state is progressing. No record-level mechanism in this document closes that gap. 6. Ordering Evidence: Correspondence Is Not Precedence Reconciliation between the authorizing side's record and the effecting side's record, hash for hash, establishes correspondence: the two sides agree about what happened. It establishes nothing about which came first. A verdict that quietly means the comparable parts matched is a misrepresentation of evidentiary weight, and the data model MUST give records a way to say correspondence-only so that the weaker claim is never presented as the stronger one. Meeting the precedence bar requires either one observer whose boundary covered both the decision and the effect, which across trust domains does not exist by definition, or two records related through the same operation with a trusted sequencing mechanism between them. This formulation aligns with the ordering-evidence treatment of post- hoc ratification presented as pre-execution authority in [I-D.bu-agentproto-security-principal-binding]. Two routes to such a mechanism exist, and they are not equally available. 6.1. The Causal Route Make the effect consume an unpredictable artifact minted at decision time. If the effecting side cannot act without a value that did not exist before the decision, precedence follows from causality rather than from any clock, and a relying party verifies it later from the two records alone, provided the effect record binds the artifact. Neither side needs to trust the other's clock. In a fail-closed plane this is native, because the effect cannot be reached except through the decision. Two properties are required for the route to be sound: B Expires 14 February 2027 [Page 7] Internet-Draft Decision Records August 2026 1. The artifact MUST be single-use. Without that, one decision establishes precedence for an unbounded number of effects, each of which individually passes the causal test. In a fail-closed plane single use may hold by construction, but that is a property of the deployment rather than of the route, and a data model that carries the artifact without stating consumption semantics will be implemented both ways. 2. Causality establishes order and not duration. The artifact proves the effect could not have preceded the decision and says nothing about how long after. A decision taken long ago whose artifact is still live passes the causal test exactly as cleanly as a fresh one. The artifact MUST therefore carry, or its declaration MUST state, the interval within which it remains consumable, derived per Section 4.4. Precedence without a bound is what a stale authority looks like from the inside. 6.2. The Temporal Route Independent external anchors on both sides. An anchored decision record proves the decision existed no later than its anchor time, which is the easy half. The lower bound on the effect is self- asserted unless the effecting substrate anchors at effect time, and a self-asserted effect time is the same defect the model excludes elsewhere, arriving one level down. The temporal route is honest only where both sides anchor, which is a deployment property, not a data model property. 6.3. The Disclosure Consequence Where neither route holds, the record MUST say correspondence-only. Failure to provide this status forces implementations to choose between overclaiming and not reporting, and deployed systems choose overclaiming. 7. Boundary An admission point governs what asks. This model says nothing about systems that never ask, and no obligation on a committing party reaches a system that makes no commitments. The systems in which the motivating failure occurs most reliably are exactly those that make no commitments at all, so there is no committing party and no artifact to be absent. This is stated as a boundary of the model rather than left to be discovered by whoever deploys against it. B Expires 14 February 2027 [Page 8] Internet-Draft Decision Records August 2026 8. Security Considerations This document is about the evidentiary weight of records, and its security considerations are the disclosures themselves. The failure mode it addresses throughout is a claim that appears stronger than the mechanism behind it: a read-time signature presented as a decision-time commitment, correspondence presented as precedence, an absolute deadline presented as a checkable bound, a reusable artifact presented as proof of a single ordered effect. Each disclosure in this document exists to make one such overclaim impossible to make silently. Records and artifacts described here are themselves targets. A decision record's signature key, the mint for causal artifacts, and any external time anchor are all points whose compromise converts forged claims into apparently verifiable ones. Key management and anchor selection are out of scope for this document and standard considerations apply. Entry emission creates a new attributable statement and therefore a new thing to lie about. A party may emit truthfully at entry and never progress; see the residue in Section 5. Verifiers MUST NOT treat an entry artifact as evidence of progress. 9. IANA Considerations This document has no IANA actions. 10. Intellectual Property Notice An IPR disclosure covering material in this document has been filed with the IETF as disclosure 7500, under royalty-free terms for Necessary Patent Claims for the purpose of implementing the relevant specification. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . B Expires 14 February 2027 [Page 9] Internet-Draft Decision Records August 2026 11.2. Informative References [I-D.kuehlewind-audit-architecture] Kuehlewind, M. and H. Birkholz, "An Architecture for AI Agent Auditing", Work in Progress, May 2026, . [I-D.bu-agentproto-security-principal-binding] Bu, S., "Security Principal Binding for Agent Protocols", Work in Progress, August 2026, . Acknowledgments The four-disclosure structure and the entry-emission rule were shaped in discussion on the agent2agent mailing list. Sumit Ahuja contributed the deadline-derivation disclosure and the staleness analysis of the causal route. Mikhail Sergeev contributed the two- disclosures framing that separated what a signature binds from what establishes order. Vernon Wharff contributed the entry-emission observation from an operating pre-execution authorization layer. The ordering-evidence formulation aligns with Section 22 of draft-bu- agentproto-security-principal-binding by Songbo Bu, and the author thanks Thomas Howe and Iman Schrock for discussion of where verifiable conditions belong relative to architecture text. Author's Address Bradley B 11 AI Blockchain Developments LLC Email: quantum@11aiblockchain.com URI: https://11aiblockchain.com B Expires 14 February 2027 [Page 10]