Network Working Group R. Rampertab Internet-Draft RAmEx Labs Intended status: Informational 29 October 2026 Expires: 2 May 2027 Replayable Authority Histories for Auditing Automated Agents draft-rampertab-audit-agent-authority-history-00 Abstract Software agents act on authority that changes while they run: permissions are granted and revoked, running instances are replaced, and some requests are refused. Activity logs record what a system reports it did, but they do not by themselves show what an agent was allowed to do when it acted, and the operator can edit them. This document specifies a model for an authority history: an append-only, signed record of who granted what to whom, which actions were admitted, which requests were refused, and which unfinished duties survive when one agent replaces another. Given independently authenticated owner keys and history identity, a verifier can replay the history and recompute its recorded authorization decisions while trusting neither the agent nor the operator. The document states what such a verifier can and cannot establish. Optional profiles cover external anchoring, federated operation, human-attested keys and zero-knowledge disclosure. An informative appendix describes one encoding. 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 2 May 2027. Rampertab Expires 2 May 2027 [Page 1] Internet-Draft Agent Authority History October 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. The question . . . . . . . . . . . . . . . . . . . . . . 4 1.2. The approach . . . . . . . . . . . . . . . . . . . . . . 5 1.3. A short example . . . . . . . . . . . . . . . . . . . . . 6 1.4. What a verifier can and cannot conclude . . . . . . . . . 8 1.5. How this relates to existing work . . . . . . . . . . . . 9 1.6. Relation to AUDIT, and questions for discussion . . . . . 11 1.7. Scope and how to read this document . . . . . . . . . . . 12 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 14 3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Parties and trust . . . . . . . . . . . . . . . . . . . . 17 3.2. The history . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. Five things kept apart . . . . . . . . . . . . . . . . . 18 3.4. Four rules the rest depend on . . . . . . . . . . . . . . 19 4. The authority history . . . . . . . . . . . . . . . . . . . . 19 4.1. Control records . . . . . . . . . . . . . . . . . . . . . 19 4.2. Grants, delegations and prohibitions . . . . . . . . . . 21 4.3. Sessions and epochs . . . . . . . . . . . . . . . . . . . 22 4.4. Owner keys and pre-rotation . . . . . . . . . . . . . . . 22 4.5. Owner approval policies . . . . . . . . . . . . . . . . . 23 4.6. Proof of Human Lineage attestation . . . . . . . . . . . 25 4.7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Records and their verification . . . . . . . . . . . . . . . 28 5.1. The chain and the head . . . . . . . . . . . . . . . . . 28 5.2. Control signatures . . . . . . . . . . . . . . . . . . . 28 5.3. Session signatures . . . . . . . . . . . . . . . . . . . 29 5.4. Replay and determinism . . . . . . . . . . . . . . . . . 29 5.5. Evidence references . . . . . . . . . . . . . . . . . . . 30 5.6. State commitment . . . . . . . . . . . . . . . . . . . . 30 6. Decisions and refusals . . . . . . . . . . . . . . . . . . . 30 6.1. The decision procedure . . . . . . . . . . . . . . . . . 30 6.2. Consequential requests and admissions . . . . . . . . . . 32 Rampertab Expires 2 May 2027 [Page 2] Internet-Draft Agent Authority History October 2026 6.3. Budgets . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.4. Refusals as records . . . . . . . . . . . . . . . . . . . 32 7. Counterparty receipts and external policy . . . . . . . . . . 34 7.1. Counterparty receipts . . . . . . . . . . . . . . . . . . 34 7.2. External policy composition . . . . . . . . . . . . . . . 34 8. Duties, handover and lineage . . . . . . . . . . . . . . . . 35 8.1. Duties . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Succession and handover . . . . . . . . . . . . . . . . . 35 8.3. Queries . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.4. Proof of Human Lineage . . . . . . . . . . . . . . . . . 37 8.5. Query scope and investigation . . . . . . . . . . . . . . 38 9. Execution recovery and continuation . . . . . . . . . . . . . 39 9.1. Admission, dispatch and uncertain outcomes . . . . . . . 39 9.2. Same-case continuation . . . . . . . . . . . . . . . . . 40 9.3. Interfaces and service boundaries . . . . . . . . . . . . 41 10. Reconciliation . . . . . . . . . . . . . . . . . . . . . . . 41 10.1. Why a decision point is not enough . . . . . . . . . . . 42 10.2. Reconciliation observations . . . . . . . . . . . . . . 42 11. Export, verification and freshness . . . . . . . . . . . . . 43 11.1. The export view . . . . . . . . . . . . . . . . . . . . 43 11.2. What a verifier establishes . . . . . . . . . . . . . . 44 11.3. Rollback and freshness: local anchors, witnesses and public chains . . . . . . . . . . . . . . . . . . . . . 44 11.4. External anchoring profiles . . . . . . . . . . . . . . 46 11.5. Federated operators . . . . . . . . . . . . . . . . . . 48 12. Optional zero-knowledge proofs . . . . . . . . . . . . . . . 48 13. Applicability beyond AI agents . . . . . . . . . . . . . . . 51 14. Security Considerations . . . . . . . . . . . . . . . . . . . 53 14.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 53 14.2. The host is trusted by the engine, not by the verifier . . . . . . . . . . . . . . . . . . . . . . . . 59 14.3. Key compromise . . . . . . . . . . . . . . . . . . . . . 60 14.4. Rollback, refusals, delegation, availability, claims . . 62 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 63 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 17.1. Normative References . . . . . . . . . . . . . . . . . . 64 17.2. Informative References . . . . . . . . . . . . . . . . . 64 Appendix A. Example encoding: an append-only JSON Lines history . . . . . . . . . . . . . . . . . . . . . . . . . 69 A.1. Store, chain and state . . . . . . . . . . . . . . . . . 69 A.2. Record kinds and signatures . . . . . . . . . . . . . . . 69 A.3. Refusals, duties, export, witness . . . . . . . . . . . . 71 Appendix B. Implementation status . . . . . . . . . . . . . . . 71 Appendix C. Formal verification: what was chosen, what it proves, what it does not . . . . . . . . . . . . . . . . . . . . 76 Appendix D. Relation to other work . . . . . . . . . . . . . . . 82 Appendix E. SCITT mapping . . . . . . . . . . . . . . . . . . . 83 Rampertab Expires 2 May 2027 [Page 3] Internet-Draft Agent Authority History October 2026 Appendix F. Worked model example . . . . . . . . . . . . . . . . 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 84 1. Introduction This section sets out the problem, the approach and an example, and relates the model to existing work. The specification begins in Section 2. 1.1. The question Consider an organization that lets a software agent buy supplies on its behalf. During the month the agent's running instance is replaced after a fault, a larger order is refused, and a second agent takes over the purchasing role. Weeks later an auditor, a regulator or a supplier asks about one purchase: was this agent allowed to make it, at the moment it made it, and on whose authority? Today that question is usually answered from logs kept by the system being audited. Logs record what the system reports it did. They rarely carry the authority state from which the answer could be recomputed, and whoever operates the host can edit them. The answer therefore rests on trust in the operator, the very party an audit is meant to check. Automated agents make the question both more common and harder to answer, for three reasons: * *Authority changes during execution.* Grants are issued, narrowed and revoked while agents run. The Agent Use of Delegation and Interaction Traceability (AUDIT) BoF request names "how permissions evolved during execution" as a question audits must answer [AUDIT-BOF]. * *The actor is not one thing.* A running instance, the durable agent it belongs to, and the office that agent holds can each be replaced independently. Authority attached to the wrong one is either lost on replacement or wrongly inherited. * *What did not happen matters too.* An auditor needs to know which requests were refused and why, and what work was left unfinished when an agent was replaced. This document proposes that a system record its authority, not only its activity: as an append-only, signed history from which its authorization decisions can be recomputed by a party that trusts neither the agent nor the operator that runs it. Rampertab Expires 2 May 2027 [Page 4] Internet-Draft Agent Authority History October 2026 1.2. The approach Figure 1 shows who signs which records and who checks them. Owner keys, authenticated out of band | | every change of power is owner-signed v +---------------------------------------------------+ | Authority history (append-only, hash-chained) | | grants, revocations, sessions, roles, tenures, | | admissions, refusals, duties, handovers | +---------------------------------------------------+ ^ | | sessions sign admissions, | export | refusals and outcomes v +--------------+ +-----------------------------+ | Agent and | | Verifier | | its host | | trusts neither agent nor | | (untrusted) | | operator; replays the range | +--------------+ | and recomputes decisions | +-----------------------------+ Figure 1: Who signs what, and who checks it Three properties carry the design: * *Authority is recorded as signed data.* Every creation or withdrawal of power (a grant, delegation, prohibition, revocation, session admission, role transfer or termination) is a control record that must satisfy the owner's approval policy in force at its position (Section 4.1). A delegation can narrow the grant it derives from, never widen it. * *Decisions are reproducible.* A decision is ALLOW with a proof (the permission path from a root grant of the owner to the actor), DENY with a code, or INDETERMINATE. A consequential action is recorded as an admission that names the head (the position, hash and time of the history prefix) on which it was decided; refusals are recorded as well. Replay re-derives every admission and every authority or budget refusal, and rejects a history whose recorded decision does not reproduce (Section 6). Rampertab Expires 2 May 2027 [Page 5] Internet-Draft Agent Authority History October 2026 * *Verification does not depend on the operator.* Given owner keys and a history identity authenticated by independent means, a verifier can check an export without the agent, the operator, the writer software or network access to the host (Section 11). Showing that an export is the latest state needs evidence held outside the host: signed heads held by others, witnesses or external anchors (Section 11.3, Section 11.4). The rest of the model follows from taking these properties seriously: separate records for the agent, its runtime sessions and its office (Section 3.3); duties that survive a handover while grants do not (Section 8); observations of calls that bypassed the decision point (Section 10); and an explicit statement of what a verifier can and cannot conclude (Section 11.2). 1.3. A short example Table 1 follows the purchasing scenario above through one history. It is illustrative and simplified; Appendix F gives a fuller sequence. +======+==========================+===========+====================+ | Step | Record | Signed by | What a verifier | | | | | later concludes | +======+==========================+===========+====================+ | 0 | Genesis: owner keys, | None (the | The history's | | | policy identifiers | genesis | identity, once | | | | is | authenticated out | | | | unsigned) | of band | +------+--------------------------+-----------+--------------------+ | 1 | Create agents A1 and A2, | Owner | The parties, the | | | a purchasing role R and | | office, and whose | | | a succession rule for R; | | receipts count | | | register supplier X's | | | | | receipt key | | | +------+--------------------------+-----------+--------------------+ | 2 | Appoint A1 to R (tenure | Owner | Who holds the | | | 1); admit runtime | | office, and which | | | session S1 for A1 | | key speaks for A1 | +------+--------------------------+-----------+--------------------+ | 3 | Grant G to A1: purchase | Owner | The authority A1 | | | from supplier X, total | | holds | | | at most 500, valid until | | | | | 31 October | | | +------+--------------------------+-----------+--------------------+ | 4 | Admission: A1 buys 200 | S1 | ALLOW, recomputed, | | | from X | | with proof path | | | | | owner to G to A1 | Rampertab Expires 2 May 2027 [Page 6] Internet-Draft Agent Authority History October 2026 +------+--------------------------+-----------+--------------------+ | 5 | Supplier's signed | S1, | X claims delivery; | | | receipt for that | wrapping | the claim is | | | purchase | X's | authenticated, the | | | | signature | delivery is not | +------+--------------------------+-----------+--------------------+ | 6 | S1 fails; advance A1's | Owner | Any record S1 | | | control epoch, which | | appends after this | | | retires S1, and admit | | point is rejected | | | session S1b | | on replay | +------+--------------------------+-----------+--------------------+ | 7 | Refusal: A1 asks to buy | S1b | DENY, recomputed: | | | 400 | | amount exceeded | | | | | (200 + 400 > 500) | +------+--------------------------+-----------+--------------------+ | 8 | Duty: pay X for the step | S1b | Open work attached | | | 4 purchase by 15 | | to the office, not | | | November, owed by role R | | to A1 | | | under the succession | | | | | rule of step 1 | | | +------+--------------------------+-----------+--------------------+ | 9 | Handover: terminate A1, | Owner | The duty stays | | | transfer R to A2 (tenure | | open under R; | | | 2); admit session S2 | | grant G does not | | | | | pass to A2 | +------+--------------------------+-----------+--------------------+ | 10 | Refusal: A2 asks to buy | S2 | DENY, recomputed: | | | 50 | | no authority | +------+--------------------------+-----------+--------------------+ Table 1: One purchasing history and what a verifier learns from it Weeks later an auditor receives an export of the whole history and obtains the owner's public keys from a source the operator does not control. Without contacting the operator, the auditor can establish that the purchase at step 4 was authorized, and by which grant; that two requests were refused, on which heads and why; that the payment duty is still open under the purchasing role, and that no signed assignment of it to A2 has been recorded; and that A2 received none of A1's power. The auditor cannot establish from the export alone that the goods arrived, that every purchase passed through the decision point, or that the export ends at the latest record. Rampertab Expires 2 May 2027 [Page 7] Internet-Draft Agent Authority History October 2026 1.4. What a verifier can and cannot conclude +=================+===============================+==============+ | Question an | Established from an export? | What the | | auditor asks | | answer rests | | | | on | +=================+===============================+==============+ | Was this action | Yes | Replay; | | authorized by | | owner | | the recorded | | signatures | | authority at | | on every | | the head it | | change of | | names? | | power | +-----------------+-------------------------------+--------------+ | Which requests | Yes, for recorded refusals. | Session | | were refused, | Authority and budget refusals | signatures; | | when, and with | are recomputed; refusals by | replay | | which code? | an external enforcement point | | | | are attested, not recomputed. | | | | A history need not record | | | | every refused attempt. | | +-----------------+-------------------------------+--------------+ | Who owed which | Yes | Replay of | | unfinished work | | roles, | | after a | | tenures and | | handover, and | | duties | | did any power | | | | pass with the | | | | role? | | | +-----------------+-------------------------------+--------------+ | Did the owner | That the required keys | The owner | | approve each | signed; not who held them, | approval | | change of | nor what they intended | policy; key | | power? | | custody | +-----------------+-------------------------------+--------------+ | Did the action | No: only who claimed it, and | Signed | | have its effect | on which head | outcomes and | | in the world? | | counterparty | | | | receipts are | | | | claims | +-----------------+-------------------------------+--------------+ | Did every | No. Reconciliation | Placement of | | action pass | observations report matched | the decision | | through the | and unmatched calls, without | point; | | decision point? | a completeness guarantee. | reconciler | | | | coverage | +-----------------+-------------------------------+--------------+ | Is this the | Only with evidence held | Held heads, | Rampertab Expires 2 May 2027 [Page 8] Internet-Draft Agent Authority History October 2026 | latest state of | outside the host | witnesses, | | the history? | | external | | | | anchors | +-----------------+-------------------------------+--------------+ | Are the | No; history time is the | Writers' | | timestamps | writers' claim | clocks; see | | true? | | Section 14.2 | +-----------------+-------------------------------+--------------+ Table 2: What a verifier can and cannot establish Section 11.2 states these conclusions precisely, and Section 14.1 lists each adversary with its residual limit. 1.5. How this relates to existing work Several existing mechanisms each answer part of the question. The model is intended to complement them, not replace them. +========================================+============+=============+ |Work |What it |What this | | |provides |document | | | |adds | +========================================+============+=============+ |Activity logs and tracing |A record of |The | | |what a |authority | | |system |state needed | | |reports it |to recompute | | |did |whether it | | | |was allowed, | | | |under owner | | | |signatures | | | |that an | | | |operator | | | |without the | | | |owner keys | | | |cannot forge | +----------------------------------------+------------+-------------+ |OAuth Token Exchange [RFC8693]; |Delegation |A durable | |Transaction Tokens |and context |history in | |[I-D.ietf-oauth-transaction-tokens] |carried in |which a | | |tokens for |token's | | |the duration|underlying | | |of a request|grant, and | | | |its | | | |revocation, | | | |can be | | | |recorded and | Rampertab Expires 2 May 2027 [Page 9] Internet-Draft Agent Authority History October 2026 | | |replayed | +----------------------------------------+------------+-------------+ |Workload Identity in a Multi System |Identifiers |A session | |Environment (WIMSE) architecture |and short- |admission | |[I-D.ietf-wimse-arch] |lived |can bind a | | |credentials |WIMSE | | |for |credential's | | |workloads |key; the | | | |history | | | |records what | | | |that | | | |identity was | | | |allowed to | | | |do over time | +----------------------------------------+------------+-------------+ |Certificate Transparency [RFC6962] |Append-only,|Replay of | |[RFC9162]; Supply Chain Integrity, |auditable |authority- | |Transparency and Trust (SCITT) [RFC9943]|logs; |state | | |evidence |transitions. | | |that a |Registration | | |statement |does not | | |was |establish | | |registered |that a | | | |statement is | | | |true or | | | |complete. | +----------------------------------------+------------+-------------+ |Remote Attestation Procedures (RATS) |Evidence |References | |[RFC9334] |about the |to such | | |environment |evidence; | | |that |this model | | |produced a |checks | | |record |authority | | | |and signer | | | |claims, not | | | |environments | +----------------------------------------+------------+-------------+ |AUDIT architecture |Cross-domain|A local, | |[I-D.kuehlewind-audit-architecture] |record |replayable | | |generation, |authority- | | |collection |state | | |and audit |component | | |context |that such an | | | |architecture | | | |could carry | +----------------------------------------+------------+-------------+ |Signed permissions and action receipts |Passkey |Replayed | |[I-D.izmaylov-agent-permission-receipts]|permissions,|actor, | Rampertab Expires 2 May 2027 [Page 10] Internet-Draft Agent Authority History October 2026 | |attenuating |session and | | |delegation, |epoch state; | | |signed |role tenures | | |action |and | | |receipts |surviving | | | |duties; | | | |admissions | | | |that must | | | |reproduce | | | |ALLOW | +----------------------------------------+------------+-------------+ Table 3: How this model relates to existing work These pieces compose. A deployment could issue OAuth tokens under grants recorded in the history, bind WIMSE credentials to admitted sessions, and anchor the history's heads in a transparency service or public ledger. Appendix D and Appendix E give the detail. 1.6. Relation to AUDIT, and questions for discussion The AUDIT BoF proposal identifies evolving authorization as an auditing concern [AUDIT-BOF]. The architecture draft [I-D.kuehlewind-audit-architecture] addresses cross-domain record generation and collection. This document proposes a local replayable authority-state component; identity mapping and cross-domain context propagation require separate profiles. Referenced Internet-Drafts are work in progress, and this individual submission implies no working-group adoption. The author would particularly welcome views on four questions: 1. Is a replayable authority-state component, as distinct from record collection and context propagation, useful work for AUDIT? 2. Should refusals, and duties that survive replacement, be first- class audit records? 3. Does the separation of agent, runtime session, office and authority (Section 3.3) align with the vocabularies of OAuth and WIMSE, or should it be reconciled with them? 4. Which concrete encoding would be most useful first: a COSE statement profile suitable for SCITT (Appendix E), or a JSON encoding such as the one in Appendix A? Rampertab Expires 2 May 2027 [Page 11] Internet-Draft Agent Authority History October 2026 The model is drawn from IronTrellis, an implementation in development. Appendix B reports what has been built and independently checked, and Appendix C what has been machine-checked in Lean and which proof paths were chosen. 1.7. Scope and how to read this document The model addresses four questions: what authority supported a request at a captured head; what requests were refused; what work survives replacement; and what supplied host calls have no matching decision. Its proposed requirements apply to a complete model instantiation. A concrete interoperability profile MUST specify closed schemas, canonical encoding, signature challenges, transition and error precedence, identifiers, time semantics, limits, and exact decision and evidence ordering. This document alone does not define byte-level interoperability. Rampertab Expires 2 May 2027 [Page 12] Internet-Draft Agent Authority History October 2026 +===============+=============================+================+ | Section | What it specifies | Of most | | | | interest to | +===============+=============================+================+ | Section 2, | Vocabulary; the parties and | Everyone | | Section 3 | what each is trusted for | | +---------------+-----------------------------+----------------+ | Section 4, | The records, and how they | Implementers | | Section 5 | are signed, chained and | of a writer or | | | replayed | verifier | +---------------+-----------------------------+----------------+ | Section 6 to | Decisions, refusals, | Builders of | | Section 8 | budgets, receipts, duties, | agent runtimes | | | handover, lineage queries | and gateways | +---------------+-----------------------------+----------------+ | Section 9, | Recovery of uncertain | Operators of | | Section 10 | execution; calls that | long-running | | | bypassed the decision point | agents | +---------------+-----------------------------+----------------+ | Section 11 | Exports, what they prove, | Auditors | | | and keeping a history | | | | fresh: local anchors, | | | | witnesses, public chains | | +---------------+-----------------------------+----------------+ | Section 4.5, | Optional profiles | Deployments | | Section 4.6, | | that need them | | Section 11.5, | | | | Section 12 | | | +---------------+-----------------------------+----------------+ | Section 14, | Threats, responses and | Security and | | Section 15 | residual limits | privacy | | | | reviewers | +---------------+-----------------------------+----------------+ | Appendix A, | One encoding; what is | Anyone judging | | Appendix B, | built, proved and machine- | maturity | | Appendix C | checked | | +---------------+-----------------------------+----------------+ Table 4: How this document is organized Rampertab Expires 2 May 2027 [Page 13] Internet-Draft Agent Authority History October 2026 Out of scope: the semantics of actions and resources (these are application identifiers), the policy language used to express constraints beyond the structural ones named here, the content of prompts and responses (see [I-D.birkholz-verifiable-agent-conversations]), a concrete remote- attestation format for the executing environment or biometric ceremony (see [RFC9334]), a record or signing-ceremony transport protocol, and any claim about the business outcome of an action in the world. IronTrellis's rationale manuscript [IRONTRELLIS-RATIONALE] is separate informative material. It does not supply protocol requirements or interpretation rules. 2. Conventions and Terminology 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. BCP 14 requirements apply to profiles claiming this proposed model, not to all agent-auditing systems. An Informational document can state such requirements without claiming an IETF standard. A deployment claim is an assertion to be assessed under stated trust assumptions, not a theorem supplied by this document. Identifiers are opaque strings assigned by the application; the model constrains their relations, not their form. Table 5 defines the terms used throughout. +================+==================================================+ | Term | Meaning | +================+==================================================+ | Principal | The party a history belongs to and the | | (owner) | root of every power in it. Holds the | | | owner keys that sign control records. | +----------------+--------------------------------------------------+ | Controller | The identity under which agents are | | | created and their sessions managed. A | | | label, not a holder of grants. | +----------------+--------------------------------------------------+ | Agent | A durable identity that can hold | | | grants, occupy roles and owe duties. | | | After termination its requests are | | | refused; its record stays. | +----------------+--------------------------------------------------+ Rampertab Expires 2 May 2027 [Page 14] Internet-Draft Agent Authority History October 2026 | Runtime | One running instance of an agent, | | session | admitted with its own public key, a | | | control epoch and an expiry. Signs | | | session records. | +----------------+--------------------------------------------------+ | Control epoch | A per-agent counter. Advancing it | | | retires every session admitted under | | | an older epoch without terminating the | | | agent. | +----------------+--------------------------------------------------+ | Role | A durable office held by one agent at | | | a time, in numbered tenures. | | | Transferring a role does not transfer | | | grants. | +----------------+--------------------------------------------------+ | Succession | Who follows whom in a role, and which | | rule | record kinds the succession may | | | produce. | +----------------+--------------------------------------------------+ | Handover | The predecessor's termination and the | | | transfer of the role to the | | | successor's new tenure, recorded as | | | one atomic operation. | +----------------+--------------------------------------------------+ | Grant | A permission with a grantor, a grantee | | (authority) | and constraints. A grant made by the | | | principal is a *root*. | +----------------+--------------------------------------------------+ | Delegation | A grant issued by an agent under a | | | grant it holds. Always *attenuated*: | | | it may narrow its parent, never widen | | | it. | +----------------+--------------------------------------------------+ | Prohibition | A rule forbidding a subject from | | | specified actions on specified | | | resources. | +----------------+--------------------------------------------------+ | Revocation | A control record that ends a grant, | | | delegation or prohibition. Revoking a | | | parent cascades to its delegations. | +----------------+--------------------------------------------------+ | Control record | A record that creates or withdraws | | | power. Signed by owner keys in force | | | at its position. | +----------------+--------------------------------------------------+ | Session record | A record signed by a session key: | | | intent, admission, consumption, | | | outcome, receipt, refusal, effect or | Rampertab Expires 2 May 2027 [Page 15] Internet-Draft Agent Authority History October 2026 | | observation. | +----------------+--------------------------------------------------+ | Decision | ALLOW with a proof, DENY with a code | | | and evidence, or INDETERMINATE with a | | | code and evidence. | +----------------+--------------------------------------------------+ | Refusal record | A session-signed record of a DENY or | | | INDETERMINATE, with the request, | | | evaluation time, head and code. | +----------------+--------------------------------------------------+ | Duty | Unfinished work owed under a role, | | (obligation) | with a deadline, status, performer and | | | optionally a succession rule. | +----------------+--------------------------------------------------+ | Reconciliation | A signed record that a call was | | observation | observed at a host boundary and | | | matched, or not, to a decision. | +----------------+--------------------------------------------------+ | Head | The identity of a history prefix: | | | chain hash, position and time of the | | | last record. | +----------------+--------------------------------------------------+ | Export | A self-contained view of a history, or | | | a range of it, checkable without the | | | writer. | +----------------+--------------------------------------------------+ | Verifier | A party that checks an export, | | | trusting neither the agent nor the | | | operator. Needs authenticated history | | | identity and owner trust anchors. | +----------------+--------------------------------------------------+ | Witness | A service in another trust domain | | | keeping an append-only log of owner- | | | signed head statements, accepting only | | | extensions. | +----------------+--------------------------------------------------+ | Human-attested | A key for which a verification profile | | key | holds signed evidence binding the | | | exact key to a human at an enrollment | | | ceremony. Not uniqueness, legal | | | identity or continuing control. | +----------------+--------------------------------------------------+ | Voucher | A human who signs a scoped statement | | | about another subject's enrollment. | | | Evidence only; no authority. | +----------------+--------------------------------------------------+ | Budget | An owner-declared stop rule over a | | | group of requests, charged by | Rampertab Expires 2 May 2027 [Page 16] Internet-Draft Agent Authority History October 2026 | | admissions (Section 6.3). | +----------------+--------------------------------------------------+ | State | An owner-signed commitment to the | | checkpoint | state root at a position | | | (Section 5.6). | +----------------+--------------------------------------------------+ | Counterparty | An external party whose registered key | | | signs receipts (Section 7.1). | +----------------+--------------------------------------------------+ | Head | An owner-signed head kept beside the | | attestation; | history, deposited in a log its | | anchor | writers cannot rewrite, or recorded as | | | an owner-signed anchor control record | | | (Section 11.3). | +----------------+--------------------------------------------------+ | Attester | A party named in the policy whose | | | signed statement classes a key as | | | human (Section 4.6). | +----------------+--------------------------------------------------+ Table 5: Terms 3. Model 3.1. Parties and trust +===========+==========================+===========================+ | Party | Trusted for | Not trusted for | +===========+==========================+===========================+ | Principal | Owner keys are the | Being independent of the | | | authority trust anchor, | operator; a signature is | | | once authenticated by an | a key claim | | | independent mechanism | | +-----------+--------------------------+---------------------------+ | Operator | Nothing. Can read and | Anything; the model | | (host) | write every file, | detects changes that | | | including the history | conflict with | | | | authenticated commitments | +-----------+--------------------------+---------------------------+ | Agent and | Nothing. A session | That the claim is true in | | sessions | signature shows that an | the world | | | admitted session made a | | | | claim at a head | | +-----------+--------------------------+---------------------------+ | Verifier | Nothing; it relies only | Needs no access to, and | | | on owner public keys it | places no trust in, the | | | has authenticated, and | agent, operator, writer | | | MAY rely on witness keys | or host | Rampertab Expires 2 May 2027 [Page 17] Internet-Draft Agent Authority History October 2026 +-----------+--------------------------+---------------------------+ Table 6: Who is trusted for what A verifier MUST authenticate the expected history identity and initial owner keys through an independent trust mechanism: an attacker can generate a consistent substitute history with its own keys, so keys in an untrusted genesis authenticate nothing. Later keys are established from verified rotations. The model does not prevent an operator from editing a history; it detects edits that conflict with authenticated signed commitments. Removal of an unattested suffix, or restoration of an older copy with its older genuine commitments, can remain undetected; Section 11.3 bounds that risk. 3.2. The history A history is an ordered, append-only sequence of records starting with a *genesis* that fixes the domain, the first owner keys, the policy identifiers governing replay and any capacity limits; the genesis hash identifies the history. Each record has a unique identifier, a type, a non-decreasing timestamp and type-specific data under a closed schema, and commits to its predecessor by hash (Section 5.1). The state at position p is a deterministic function of records 0 through p. Decisions are computed from that state and explicit request inputs, including evaluation time (Section 5.4). Operational identity, clock-skew and freshness gates are separate from replay and may reject access even when replay is valid. 3.3. Five things kept apart principal ---owns---> history | | creates, grants, appoints v agent (durable) ----occupies----> role (office, tenure n) | | | runs as | owes v v runtime session (key, epoch, expiry) duties (survive handover) | | holds, through grants v authority (root grants, delegations, prohibitions) Figure 2: The principal, agent, session, role and authority are separate records Rampertab Expires 2 May 2027 [Page 18] Internet-Draft Agent Authority History October 2026 An agent can be terminated while its role, tenure history and duties stay on record. A session can be fenced by advancing the epoch without touching the agent. A role can be transferred without the successor inheriting the predecessor's grants. 3.4. Four rules the rest depend on * *Powers and obligations need not pass together.* An instantiation MUST preserve unfinished duties across an applicable succession and MUST require an authorized signed assignment before changing their performer. It MUST NOT transfer the predecessor's grants merely because a role transfers. Duties and role occupancy MUST NOT be accepted as permission to act. * *Interpretation is not authority.* An instantiation MUST evaluate authority from the captured history, the explicit request and the evaluation time. It MUST NOT accept a language model's interpretation as authority evidence. Results MUST distinguish ALLOW, DENY and INDETERMINATE and carry scope and evidence (Section 6). * *Everything ends, and withdrawal is never blocked by a quota.* A profile MUST specify the end conditions of each grant, session and duty, including whether a grant may omit expiry. A capacity rule MUST keep a declared-limit bypass for valid power-reducing controls while reporting absolute storage and signature failures (Section 4.7). * *Evidence is legible.* An instantiation MUST return stable, typed evidence references for each decision and query conclusion, each identifying its captured history and evaluation scope. A historical answer MUST NOT be presented as present execution permission (Section 8.5). 4. The authority history 4.1. Control records A conforming history MUST support the control record kinds in Table 7. Each carries owner authorization satisfying the policy in force at its position (Section 5.2, Section 4.5). +==========================+=====================================+ | Kind | Names | +==========================+=====================================+ | PRINCIPAL_CREATED | A principal. Recorded principals | | | are identities under the one owner | | | key set; a profile must distinguish | Rampertab Expires 2 May 2027 [Page 19] Internet-Draft Agent Authority History October 2026 | | them from the history owner and | | | specify root recognition. | +--------------------------+-------------------------------------+ | AGENT_CREATED | A new agent, its principal, | | | controller and initial epoch | +--------------------------+-------------------------------------+ | ROLE_CREATED | A new role and its principal. | | | Roles are exclusive: one current | | | tenure at a time. | +--------------------------+-------------------------------------+ | SUCCESSION_RULE_DECLARED | A rule: predecessor, successor, | | | role, trigger (the predecessor's | | | termination) and the record kinds | | | the succession may produce | +--------------------------+-------------------------------------+ | AGENT_APPOINTED | A tenure: agent, role, tenure | | | identifier and number, optional | | | succession rule | +--------------------------+-------------------------------------+ | AGENT_UNAPPOINTED | The end of a tenure without a | | | successor | +--------------------------+-------------------------------------+ | ROLE_TRANSFERRED | The end of one tenure and the start | | | of the next for another agent | | | (succession or reassignment) | +--------------------------+-------------------------------------+ | RUNTIME_SESSION_ADMITTED | A running instance: session, agent, | | | controller, epoch, key identifier, | | | public credential, expiry | +--------------------------+-------------------------------------+ | CONTROL_EPOCH_ADVANCED | An agent's next epoch; fences every | | | session under an older one | +--------------------------+-------------------------------------+ | AUTHORITY_GRANTED | A permission or a prohibition | | | (Section 4.2) | +--------------------------+-------------------------------------+ | AUTHORITY_REVOKED | The end of a grant, delegation or | | | prohibition, naming the revoker | +--------------------------+-------------------------------------+ | AGENT_TERMINATED | The end of an agent, with the | | | succession rule, role and tenure | | | when a handover applies | +--------------------------+-------------------------------------+ | OWNER_KEYS_ROTATED | The owner key set from the next | | | position on (Section 4.4) | +--------------------------+-------------------------------------+ Table 7: Control record kinds Rampertab Expires 2 May 2027 [Page 20] Internet-Draft Agent Authority History October 2026 An instantiation MUST support owner-signed anchors and witness binding and unbinding as control capabilities (Section 11.3). A deployment MAY select its anchoring and witness policy; supporting the capability alone establishes no independent anchor. Budget, checkpoint, counterparty, anchor, and witness binding and unbinding records are also control records (Section 6.3, Section 5.6, Section 7.1, Section 11.3). 4.2. Grants, delegations and prohibitions A *permission* has a grantor, a grantee, a root, optionally a parent, a flag saying whether it stands alone or exists only as a partner for another grant, and constraints: actions, resources, an optional validity window, optional per-operation and cumulative amount ceilings, an optional transaction count, a maximum delegation depth, and required partner grants that must be live at the same time. A root permission is issued by the principal; a delegation is issued by an agent under a grant it holds and inherits the parent's root. +====================+======================================+ | Constraint | A delegation, relative to its parent | +====================+======================================+ | Actions, resources | MUST be subsets | +--------------------+--------------------------------------+ | Validity window, | MUST fit inside | | amount ceilings | | +--------------------+--------------------------------------+ | Delegation depth | MUST be strictly smaller | +--------------------+--------------------------------------+ | Required partners | MAY add, MUST NOT remove | +--------------------+--------------------------------------+ Table 8: Attenuation: a widening delegation is a replay rejection, not a warning A conforming replay MUST reject a delegation that is not attenuated as in Table 8. A delegation is evaluated against its delegator's status at evaluation time: a terminated delegator or a revoked parent yields no authority, revocation cascades to delegations, and independent paths to the same authority survive. A *prohibition* with ROOT scope is attached to a root grant and must fit inside it; one with GLOBAL scope is issued by the global policy source named in the genesis and applies across roots. Profiles MUST define path selection when several independent grants exist; a root- scoped prohibition must not be presented as overriding unrelated roots. An unrevoked root-scoped prohibition keeps its effect, within its own validity window, while its *anchor path* is live: it loses Rampertab Expires 2 May 2027 [Page 21] Internet-Draft Agent Authority History October 2026 effect when a grant in its ancestry is revoked or when an actor on that path (its grantor, or the grantor or grantee of a grant in its ancestry) is terminated. A GLOBAL prohibition has no anchor path and no lifecycle term: it loses effect only by revocation or outside its own validity window. 4.3. Sessions and epochs A session-signed record MUST be rejected on replay if the signing session is unknown, if its epoch is not the agent's current epoch at that position (the *epoch fence*), if the agent is not active, or if the record's timestamp is not before the session's expiry. Under an attested owner floor (Section 4.6), a session-signed or administrative record MUST also be rejected if its timestamp is at or past the expiry of an owner attestation that was unexpired at the preceding head: only an owner-signed record carries history time across such an expiry. A genesis MAY set a *session-time horizon*; when it does, a session-signed or administrative record outside a migrated prefix MUST also be rejected if its timestamp is more than that horizon after the latest owner-signed record that advanced history time (or after the genesis, if there is none). Advancing an epoch is the intended response to a session key that may have leaked: it retires every earlier session at once, and declared capacity limits MUST NOT refuse it (Section 4.7). 4.4. Owner keys and pre-rotation epoch 1: keys {K1}, commitment D = H(K2) (fixed by genesis) | | rotation: reveals K2, proves possession, commits H(K3) v epoch 2: keys {K2}, commitment H(K3) | x a thief holding only K1 cannot rotate: K2 is kept elsewhere Figure 3: Pre-rotation: the next key is committed before it is needed The genesis declares the first owner keys; an OWNER_KEYS_ROTATED record, authorized by the policy in force before it, replaces the set from the next position on. A retired key identifier MUST NOT be re- bound or return, and a retired credential MUST NOT return under another identifier. Every owner signature is judged by the keys in force at the position it covers. A history SHOULD carry a *next-key commitment*, fixed by the record that opens the epoch. A rotation out of a committed epoch MUST either reveal at least one committed key and commit again, or, where Rampertab Expires 2 May 2027 [Page 22] Internet-Draft Agent Authority History October 2026 it keeps every key and changes only the approval policy, carry the commitment unchanged. A revealed key MUST be proved by its own signature over the rotation, its digest MUST be in the commitment, and under a policy every revealed key MUST carry its own possession proof, which no quorum of current keys can substitute; a rotation that keeps every key and changes nothing MUST be refused. The converse is a stated limit: no quorum of current keys can replace or drop a commitment, so a quorum holding no committed key can change the policy and reduce power but can never add, remove or replace a key. 4.5. Owner approval policies An instantiation MAY require separate signatures from M of N enrolled owner keys, with a global threshold and per-type overrides. A selected profile MUST define distinct credential identity, eligible membership, effective thresholds, duplicate handling, policy-update authorization and recovery. The rules below are the ones everything else rests on. * *Pre-event authority.* The effective policy and membership MUST be selected from the accepted pre-event state. New keys, new classifications and a proposed policy MUST NOT authorize their own adoption. A rotation MUST satisfy at least the greater of the preceding global threshold and its rotation threshold. A policy change with an unchanged key set is itself a rotation (a *policy rotation*): authorized by the pre-event policy with agent keys counting zero, effective from the next position, unable to add, remove or re-key, and carrying any commitment unchanged. * *One owner signature, always.* Every covered control record MUST retain at least one owner signature. A user-interface selection of zero extra co-signers MUST NOT be encoded or verified as zero owner authorization. Under a policy, enrolled credentials MUST be pairwise distinct, and a key's class MUST be a function of its credential, never of its identifier. A writer MUST NOT silently reset a non-default policy when a rotation omits one. * *Recovery is opt-in and never free.* Where the policy opts in to *recovery through committed next keys*, a committed key that a rotation reveals, with its proof of possession, counts toward that rotation's threshold as if in force; it is admissible on no other record, never lowers the threshold, and MUST be custodied as a current key. Without the option, loss of every current key is permanent: no unsigned, agent-only or emergency route exists, and a profile MUST NOT silently lower M on loss of availability. The profile MUST define the effective-threshold and signer-eligibility rules for recovery; a deployment enabling recovery with a rotation Rampertab Expires 2 May 2027 [Page 23] Internet-Draft Agent Authority History October 2026 threshold above one MUST commit at least that many next keys or accept that recovery needs the difference in surviving current keys. * *Reducing power may need fewer signatures; adding it never does.* A per-type threshold below the global one MAY be declared only for the record types in Table 9, and applies only when the record *reduces power by effect*, decided from its content and the pre- event state before any signature is counted. Such a record MUST NOT make any request pass the authority procedure (judged before the proof-size preflight, Section 14.4), or any session live, that did not before it, at any evaluation time at or after the record, and MUST NOT change owner keys, commitment, policy or bound witnesses. A lowered threshold MUST NOT exceed the number of non- agent credentials, so that no agent key is ever needed to reduce power. * *Agents never own.* A profile permitting registered agent keys as co-signers MUST require at least one eligible human-class owner signature on every covered control event and MUST exclude agent signatures from policy and owner-key changes. Under the *declared* floor, human class is a label set by the owner quorum. Under the *attested* floor (Section 4.6), a key counts as human only while an attester's statement embedded in the policy covers the record's time. * *Credentials have one job.* Under a policy, owner keys, committed keys, attesters, session credentials and counterparty credentials MUST be pairwise distinct; a credential recorded as a session or counterparty credential MUST NOT become an owner, attester or committed key while a policy is in force, and conversely. A commitment carried into a policy epoch that names such a credential MUST NOT be revealed while the policy is in force. The rule cannot catch a credential the history never recorded. Rampertab Expires 2 May 2027 [Page 24] Internet-Draft Agent Authority History October 2026 +========================+==========================================+ | Reduces power by | Needs the ordinary quorum | | effect | | +========================+==========================================+ | Revoking a | Revoking a prohibition; revoking a | | permission; advancing | permission that an unrevoked prohibition | | an epoch; terminating | has in its ancestry; terminating an | | or unappointing an | agent on an unrevoked prohibition's | | agent; declaring a | anchor path (Section 4.2); unappointing | | new budget; | an agent a live role budget could match; | | tightening a budget; | raising a cap; narrowing a budget's | | retiring a | subjects; ending a budget earlier; | | counterparty; a | tightening a budget that carries unused | | checkpoint | allowance forward | +------------------------+------------------------------------------+ Table 9: Which records may use a lowered threshold The profile MUST reject, when a policy is set, a configuration that cannot satisfy its own human and threshold rules. A strict profile MUST NOT be disabled by omission of fields; any downgrade requires the preceding policy's authorized change. A history that never selects a policy MUST replay exactly as it did without these rules. Remote signers MAY take part through an encrypted ceremony that authenticates the parties, binds history, head, epoch, action and exact challenge, protects responses, and rejects expired, replayed or mismatched responses; it MUST provide the signer with the effect being approved and preserve uncertainty across retries. Transport encryption never replaces owner authorization, human eligibility or effect-boundary checks, and voucher participation in enrollment grants no owner vote. 4.6. Proof of Human Lineage attestation An instantiation MAY support a Proof of Human Lineage (PHL) attestation profile to decide which signing keys qualify as human- attested for a selected policy. The claim concerns the origin and assessment of a key's enrollment evidence, not authorship of content and not a guarantee that an agent will never use the key later. Biometric verification, key possession, identity, uniqueness, live presence and informed intent are distinct properties. A selected profile MUST define its biometric assurance, authenticator and verifier trust roots, exact-key binding, vouching requirements, bootstrap, validity and status rules, disclosure dependencies and a deterministic acceptance predicate. A generic user-verification result MUST NOT be described as biometric evidence when the mechanism also permits a PIN without distinguishing the method. WebAuthn Rampertab Expires 2 May 2027 [Page 25] Internet-Draft Agent Authority History October 2026 [WEBAUTHN3] supplies useful authenticator evidence; attesting its credential does not attest a separate history-signing key. The proposed enrollment combines a method-qualified biometric ceremony, possession and explicit adoption of the exact signing key, and, for a remote subject, at least one other qualified human's signed vouch; the vouch MUST bind the same subject key, ceremony and assurance context, state what was observed, and be verifiable under the selected voucher trust policy. A circular chain of new vouches MUST NOT be accepted as a bootstrap. Verifiable credentials [VC-DM2] can carry claims; they do not establish their truth. An instantiation claiming replay enforcement MUST bind sufficient authenticated eligibility evidence into the replay input; a mutable registry lookup MUST NOT silently decide historical validity, and missing evidence MUST NOT silently qualify a key as human. Evidence MUST identify the key, profile, enrollment, issuer, voucher, time and status context and limitations; a profile MUST specify whether the verifier checks trusted admission statements or also revalidates their underlying evidence; missing required evidence MUST be reported as incomplete or unverified. Under the attested floor, a key's class is a function of the policy in force, its credential and the record's timestamp (Table 10). An *attester* is a party named in the policy in force. Its *statement* is a signed assertion bound to the exact credential, to the history's domain and, after the genesis, to the history's identity, with a validity interval; it is embedded in the policy and removed only by the owner quorum, never by the attester alone, and its subject MUST be an enrolled key or a committed next key not classed as an agent. +========+===================+================================+ | Class | When | May count toward | +========+===================+================================+ | HUMAN | An attester's | Everything the policy allows | | | statement covers | | | | the record's time | | +--------+-------------------+--------------------------------+ | LAPSED | The epoch's | Only a record that reduces | | | statement for the | power by effect, a state | | | key has expired | checkpoint, or a *restoration* | +--------+-------------------+--------------------------------+ | AGENT | So classed by the | Ordinary actions; never the | | | policy | floor, policy changes or | | | | rotations | +--------+-------------------+--------------------------------+ | NONE | Otherwise | Nothing | +--------+-------------------+--------------------------------+ Table 10: Key classes under the attested floor Rampertab Expires 2 May 2027 [Page 26] Internet-Draft Agent Authority History October 2026 A restoration is a policy rotation that keeps every key, the commitment and every other field and only carries each statement as written or renews it; a renewal MUST name the same credential, MUST have started by the record's timestamp and after the epoch opened, and MUST extend the expiry. Lapse never removes a key: a carried expired statement MUST be kept through every rotation that keeps the key; a restoration MUST NOT add or remove a subject, and no subject's class may drop; a lapsed key never counts on a recovery rotation. A statement removed by the quorum is final. The policy MUST name at least two attesters; it MUST be refused when set unless at least a rotation quorum of its keys have valid statements and every lowered threshold is within the count of keys with started statements. The attested floor bounds history time: a control record whose counting signatures include at most one human-class credential MUST keep the preceding head's time or advance it no further than the *attestation horizon*, the latest expiry among the policy's statements, and MUST NOT reach the maximum representable time; two or more human-class signers MAY set any legal time. A committed next key MAY be attested before it is revealed; that is the only way a recovery signer counts as human. Three limits are stated and known not to hold: under the declared floor, class is a label; an attester's honesty and independence are not verified; and a key that can authorize a record alone chooses its timestamp, bounded only by the horizon under the attested floor and not at all under the declared one. Enrollment establishes a bounded prior association; a profile claiming fresh human approval of a particular action MUST bind a fresh biometric approval to the exact action challenge and displayed effect. Profiles MUST specify renewal, suspension and revocation, including the consequences of voucher or issuer misconduct, MUST distinguish historical acceptance under the committed evidence cutoff from current risk, and MUST keep later adverse evidence inspectable without rewriting yesterday's replay. A single key's head attestation MUST NOT be taken as proof of the human floor for its preceding history, and a head attestation signed by a lapsed, agent or unclassed key MUST NOT seed an abbreviated replay; nor may any single-key head attestation where the policy requires more than one signature for a checkpoint. A checkpoint recorded in the history under its own quorum MAY seed one. A profile supporting abbreviated replay MUST specify and validate an adequate starting-state authentication policy; otherwise full replay is required. Rampertab Expires 2 May 2027 [Page 27] Internet-Draft Agent Authority History October 2026 4.7. Capacity A history MAY declare size limits. A declared limit MUST NOT refuse a control record that reduces power (revocation, epoch advance, termination, unappointment, witness unbinding). Absolute format or storage caps, unavailable durable storage or inability to sign may still prevent append; a history at an absolute terminal cap is extended by a successor history with its own genesis, which is distinct from same-case continuation (Section 9). A profile MUST define both operational and terminal limits and distinguish their failure reports. 5. Records and their verification 5.1. The chain and the head pos: 0 1 2 p +-----+ +-----+ +-----+ +-----+ | gen |<--| r1 |<--| r2 |<-- ... <-| rp | +-----+ +-----+ +-----+ +-----+ hash h0=H(0,gen) h1=H(h0,r1) h2=H(h1,r2) hp=H(h(p-1),rp) head at p = (hp, p, timestamp_p) Figure 4: Each record commits to its predecessor; the head names a prefix A conforming encoding MUST define a record hash at each position as a function of the previous hash and the record's content, under a collision-resistant hash with domain separation. The head at p is the triple (hash, position, timestamp), compared field by field. An edit, insertion or reordering changes every later hash; a fully rehashed substitute is detected only by a conflicting authenticated signature or held commitment, and removal of a complete suffix is not detectable from the chain alone (Section 11.3). A profile MUST distinguish internal consistency from authenticity. 5.2. Control signatures Every control record after the genesis MUST carry at least one valid owner signature and satisfy the selected approval policy. Each counting signature MUST be made by an admissible owner key (one in force at that position, or, on a recovery rotation, a committed key the rotation reveals with its possession proof) over a challenge that binds at least: * the history's domain, so the record cannot be replayed into another history; Rampertab Expires 2 May 2027 [Page 28] Internet-Draft Agent Authority History October 2026 * the record's identifier, type and timestamp; * the head before the record, so the record cannot be moved; * a hash of the record's effect, under profile-defined exclusions for the authorization containers themselves. A replay MUST reject a control record with absent, malformed, out-of- epoch or invalid required signatures, or whose eligible distinct signatures do not satisfy its effective policy. A multi-signature profile MUST define surplus, duplicate and ineligible entries and the exact container exclusions; an exclusion MUST NOT allow unsigned effect changes. Which threshold applies, and whether a record is a restoration or a recovery rotation, MUST be decided from the record, the signers' identifiers, the epoch record and the pre-event state alone, before any signature is verified, so the verdict never depends on verification order. 5.3. Session signatures Every session record MUST carry a session binding and a type-specific signature. Profiles MUST specify exactly which bytes are authenticated; a generic claim that all envelopes are signed is insufficient. Records constructed after the final envelope is fixed SHOULD bind identifier, type, timestamp, preceding head, binding and effect. In the example encoding, declarations, refusals, effects, lifecycle events and counterparty wrappers bind their envelope; admissions instead sign the decision-time challenge (request, evaluation time, preceding head and session, role, intent and nonce bindings), and the admission's own identifier is committed by a later owner attestation. Migrated prefixes keep their source authorization. Session checks occur in each type's validation stage: find the session and credential, check the epoch fence, active agent, binding, expiry, challenge hash and signature. An admission additionally carries the authorization proof; replay MUST re-derive it from the pre-admission state and recorded inputs and require canonical byte equality. A missing or mismatched credential is not a fence failure. 5.4. Replay and determinism A reader reconstructs state by replaying every record from genesis under the profile's fixed check order; the profile MUST specify chain, schema, authorization, transition and capacity precedence. A rejected record leaves the state unchanged, the rejection names the position, and a history containing a rejected record is invalid as a whole. Given the same history, request and evaluation time, every conforming implementation MUST produce the same decision, proof and Rampertab Expires 2 May 2027 [Page 29] Internet-Draft Agent Authority History October 2026 evidence list; evaluation time is an explicit input, never the reader's clock, and evidence lists MUST be ordered deterministically. A specification instantiating this model SHOULD publish conformance vectors and SHOULD have at least two independent implementations pass them; passing a finite set is bounded evidence, not universal correctness. 5.5. Evidence references Every claim a decision or query makes MUST be supported by an evidence reference naming a record by identifier, type, position and history hash. Further kinds MAY name an authority by its grant record, a credential by its admission, a receipt by content hash and record, or an external attestation by type, reference and attester. Evidence is bounded; a result whose evidence would exceed the bound is INDETERMINATE with an explicit code, never silently truncated. 5.6. State commitment A conforming encoding MUST define a *state root* committing to the complete set of state records at a position, such that matching roots commit to matching record sets. Inclusion needs a verified path, leaf index and tree size; sorted non-membership additionally needs authenticated adjacent indices and boundary proofs and an authenticated commitment whose ordering and uniqueness were validated; two arbitrary inclusion paths are insufficient. A Merkle tree over the sorted state records in the manner of [RFC6962] satisfies this. An instantiation MUST support owner-signed checkpoints and root-bearing head attestations, distinguishing the state before a checkpoint from the state including it. A reader resuming from a cache MUST recompute the root and compare it with an owner-signed root at exactly that position, falling back to full replay on mismatch; a mismatch alone does not establish owner-key misuse. A signed starting state is an owner assertion unless independently replayed. 6. Decisions and refusals 6.1. The decision procedure A *request* names an actor, an action, a resource and a claimed time, and optionally an amount, a counterparty and a commitment to terms. A decision is one of the results in Table 11. Rampertab Expires 2 May 2027 [Page 30] Internet-Draft Agent Authority History October 2026 +===============+=================+================================+ | Result | Meaning | Carries | +===============+=================+================================+ | ALLOW | Authority | A proof: the root, the | | | exists | permission path from root to | | | | actor, intersections | | | | satisfied, effective | | | | constraints after attenuation, | | | | the controlling authority | | | | identifiers, usage snapshot of | | | | every capped grant, authority | | | | evidence, prohibitions checked | +---------------+-----------------+--------------------------------+ | DENY | Authority does | A code and a sorted list of | | | not exist or is | failures with evidence. Codes | | | overridden | MUST at least distinguish: | | | | action not allowed, no | | | | authority, revoked, expired, | | | | not yet valid, prohibited, | | | | agent inactive, session | | | | fenced, missing intersection, | | | | amount exceeded | +---------------+-----------------+--------------------------------+ | INDETERMINATE | The history or | A code and evidence. MUST NOT | | | request cannot | be treated as ALLOW; an | | | support a | enforcement point that must | | | decision | choose MUST treat it as a | | | (unverifiable | refusal | | | relation, | | | | invalid causal | | | | time, evidence | | | | over the bound) | | +---------------+-----------------+--------------------------------+ Table 11: The three decision results The procedure MUST evaluate, in order: domain and policy identifiers; causal time (evaluation time not before the head's time); the actor's lifecycle; the session binding when the request is consequential; candidate permission paths from recognized roots; delegation status along each path; required intersections; prohibitions; per-grant limits including cumulative usage. Budgets (Section 6.3) are consulted only after an ALLOW and can only turn it into a DENY. Every result MUST state, as constant values, that it is a reading of the captured history and not a capability to execute anything. Rampertab Expires 2 May 2027 [Page 31] Internet-Draft Agent Authority History October 2026 6.2. Consequential requests and admissions A request intended for consequential execution is *consequential*. The runtime declares an *intent* (actor, action, resource, role and tenure, the adapter that will carry it out, optional amount, counterparty and terms commitment, and a nonce); the engine records an *admission* carrying the evaluation time, the expected head and the proof. After an admission the record may show a *consumption* (the adapter's signed acknowledgment), an *outcome* (confirmed, failed, disputed or unknown), a *receipt* (a compact artifact checkable against a supplied prefix), and *effects* (measurements reported by a session, connector or counterparty). None establishes that the world changed; each establishes that a signer claimed something at a head. A job with an uncertain submission stays outcome-unknown until reconciled; exactly-once effects require executor idempotency and recovery, which a signed history cannot supply by itself. 6.3. Budgets An instantiation MUST support *budgets*: owner-declared stop rules over a group of requests selected by actors, roles, actions, resources and metric, with a cap per period, per operation or in count, and bounded carry-over. A budget selected by role MUST follow the role across a handover. Budgets are charged by admissions only, never by refusals or effects; a matching selector alone does not meter effects. 6.4. Refusals as records A conforming history MUST support a *refusal record*, session-signed, with the fields in Table 12. Rampertab Expires 2 May 2027 [Page 32] Internet-Draft Agent Authority History October 2026 +============+====================================================+ | Field | Rule | +============+====================================================+ | Source | The authority procedure (CORE), a budget, or a | | | *connector* (an enforcement point outside the | | | engine) | +------------+----------------------------------------------------+ | Request | As evaluated | +------------+----------------------------------------------------+ | Evaluation | MUST equal the record's timestamp | | time | | +------------+----------------------------------------------------+ | Expected | MUST be the head immediately before the record | | head | | +------------+----------------------------------------------------+ | Decision | DENY or INDETERMINATE; the budget identifier for a | | and code | budget refusal; connector identifier, code and | | | detail digest for a connector refusal | +------------+----------------------------------------------------+ | Signer | For CORE and budget refusals the signing session's | | | agent MUST be the request's actor; for a connector | | | refusal, the connector's own admitted agent | +------------+----------------------------------------------------+ Table 12: The refusal record For CORE and budget refusals, replay MUST re-run the decision on the state before the record and MUST reject the record unless decision, code and budget identifier are reproduced; a refusal the state would have allowed is a replay rejection. A connector refusal is *attested, not re-derived*: the engine cannot reproduce a decision it did not make. A reproduced DENY establishes the recorded denial at that head; INDETERMINATE establishes that the inputs could not support ALLOW; an attested refusal proves only that an admitted connector claimed to have refused. An expired, fenced, terminated or never-admitted actor cannot sign its own CORE or budget refusal; a live connector session can attest the mapped attempt instead. Refusals never change usage counters. A writer SHOULD coalesce identical refusals per actor within a short window and SHOULD rate- limit them, and MUST report whether a refusal was recorded and, if not, why; the history therefore need not enumerate every attempt. A deployment that wants refusals enforced as well as recorded MUST place the decision point where the action is executed (Section 10.1). Rampertab Expires 2 May 2027 [Page 33] Internet-Draft Agent Authority History October 2026 7. Counterparty receipts and external policy 7.1. Counterparty receipts An instantiation MUST support owner-authorized registration and retirement of counterparty verification keys and session-recorded counterparty receipts, distinguishing a local issuer receipt, a commitment to an artifact, and a separately counterparty-signed artifact; a digest alone MUST NOT be reported as authenticated counterparty evidence. A receipt MUST bind the history identity, counterparty and key, the earlier admitted intent and its declaration digest, and the reported effect and time; its wrapper MUST bind the recording session and preceding head. Replay MUST require an ACTIVE counterparty with the named key at the wrapper position and verify the envelope signature before the wrapper authorization. Retirement MUST NOT invalidate an earlier accepted wrapper; new wrappers during retirement MUST be rejected. Re-registration may replace keys while preserving the receipt chain; a credential replaced this way leaves the history's records and the one-job rule (Section 4.5) can no longer see it. A profile MUST specify uniqueness, duplicate and reference-ordering rules and the consistency of duplicated receipt and effect fields; a wrapper referencing an earlier envelope MUST carry or reference it so an exporter can supply the dependency. Verification MUST report artifact authenticity, historical authority, canonical inclusion and current usability separately. A counterparty's signature establishes its claim, not settlement, delivery or legal effect. 7.2. External policy composition An instantiation MUST support composition with an application- selected external decider (Cedar and OpenFGA are examples) through a profile-defined interface. The application MUST bind both decisions to the same captured actor, action, resource, arguments or their commitment, and contextual inputs. For a required external policy, the broker MUST admit a new effect only when the model returns ALLOW and the decider returns an authenticated, supported ALLOW under the configured policy identity; denial, error, missing evidence and an unavailable required decider MUST prevent dispatch. An external ALLOW MUST NOT override a model denial or create a grant, duty discharge or succession power. The profile MUST identify policy, model and store versions, input provenance, freshness, error handling and restart behavior, and MUST distinguish a pinned policy model from mutable relationship data. The application MUST durably retain the external result before admission and link it to the captured request, and MUST recheck current history, authority and clock after asynchronous evaluation or signing. Post-admission external-policy liveness MUST be checked at the executor boundary or the enforcement Rampertab Expires 2 May 2027 [Page 34] Internet-Draft Agent Authority History October 2026 claim refused; a profile MUST NOT advertise cross-service atomicity merely because both decisions allowed at admission. 8. Duties, handover and lineage 8.1. Duties An instantiation MUST support durable obligations and attempt duties with signed creation, assignment and status records. A duty is created from a recorded operation and its receipt, by an administrative session record, and carries its identifier, source intent, causal receipt, durable role, tenure, description, deadline, status, beneficiary, terms commitment, current performance assignee, optional succession rule and transition policies. Statuses are OPEN, OUTCOME_UNKNOWN, DISPUTED, DISCHARGED and IMPOSSIBLE_OR_ESCALATED; a status change and a performance assignment are each signed administrative records. An *attempt duty* preserves follow-up responsibility for an uncertain operation; a profile MUST distinguish its creation rules, and an investigation review MUST NOT be interpreted as fulfillment or automatic discharge. 8.2. Succession and handover When a predecessor is terminated under a succession rule, the writer MUST provide a specified atomic handover operation; profiles MUST define crash recovery and the visibility of intermediate prefixes, since two adjacent valid events alone do not prove atomic storage. Table 13 states what MUST hold across a handover. Rampertab Expires 2 May 2027 [Page 35] Internet-Draft Agent Authority History October 2026 +===================+===========================================+ | What | Across a handover | +===================+===========================================+ | Open duties under | Belong to the role; stay OPEN and are | | the applied rule | reported as surviving until the successor | | | records a signed performance assignment | +-------------------+-------------------------------------------+ | Grants | Do *not* follow. The report MUST list | | | every live grant of the predecessor, each | | | marked as not following | +-------------------+-------------------------------------------+ | Delegations the | Evaluated against the predecessor's | | predecessor | status; after termination they yield no | | issued | ALLOW | +-------------------+-------------------------------------------+ | Budgets selected | Follow the role | | by the role | | +-------------------+-------------------------------------------+ | The predecessor's | Cease to authorize requests while the | | sessions | agent is inactive; credentials are not | | | deleted and the epoch is not advanced | +-------------------+-------------------------------------------+ Table 13: Handover rules 8.3. Queries A conforming instantiation MUST support the queries in Table 14, each answered from the captured history with evidence references and an explicit epistemic status: established from a verified replay, or not established and why. Rampertab Expires 2 May 2027 [Page 36] Internet-Draft Agent Authority History October 2026 +=============+==================================================+ | Query | Answers | +=============+==================================================+ | WHY | For a request: which grants, in which order, | | | under which constraints, from which root, in | | | which session and tenure | +-------------+--------------------------------------------------+ | RESPONSIBLE | For an action: who is attributable at the time | | | (actor, session, role, principal, mandator, | | | authority source, controller) and who holds the | | | duty afterwards. A statement about the records, | | | not a legal judgment | +-------------+--------------------------------------------------+ | SURVIVES | For an agent: lifecycle status, tenures, duties | | | that outlive it, assignments, unresolved | | | intents, reported outcomes, and authority | | | dependencies its termination invalidates | +-------------+--------------------------------------------------+ | LINEAGE | For an authority, admission or request: the | | | capability roots and grant paths that support | | | it, including required intersections and | | | issuance authorizations, with any established | | | human-lineage assessment. Confers no permission | +-------------+--------------------------------------------------+ Table 14: The four queries 8.4. Proof of Human Lineage A PHL lineage query verifies recorded authority lineage and stated human-evidence predicates under selected policies. It MUST identify its selector, authenticated history identity, evaluated head and time, interpretation and assessment policies, disclosure scope and path-selection rule; an admission query MUST use the replay- reproduced decision path with all required intersections. The *capability root* is the root permission a path descends from; it is distinct from the history owner, the owner keys in force at the root- grant event and the grantor named there, and an answer MUST identify these separately. A valid owner signature on a grant establishes the recorded edge; it MUST NOT by itself be reported as human evidence for the grantor or grantee. For a root issued under several owner approvals the answer MUST distinguish (a) whether its actual counting quorum contains a qualifying human-attested credential, (b) whether every quorum permitted by its policy requires one, and (c) any assessment of the named grantor; "human-authorized capability root issuance" denotes (a), judged in the root-grant event's frozen context. Counting MUST Rampertab Expires 2 May 2027 [Page 37] Internet-Draft Agent Authority History October 2026 use the policy in force before the event. A query MUST distinguish established-true, established-false and unknown; missing or withheld evidence MUST NOT be treated as non-human; verification MUST terminate within declared limits and report partial coverage; and for several roots the answer MUST name its quantifier and MUST distinguish alternative paths from required partner paths. An authority-only query MUST distinguish provenance and liveness from action-specific authorization, and each returned path MUST keep its own root and result. Per-edge assessments MUST carry evidence references and MUST distinguish assessment at the edge's event, at query time and as current risk; under the attested floor a lapsed class MUST be reported as lapsed, and later expiry or revocation MUST NOT silently rewrite an established event-time conclusion. An unknown required branch prevents an established-true all-required- roots conclusion; an established-false required branch can establish a false one despite another unknown branch. A limited or redacted view MUST NOT assert an exhaustive all-path or total-count conclusion. Invalid supplied evidence MUST be distinguished from evidence unavailability. Ordinary authority validity and PHL attestation assurance MUST be reported separately unless the selected authority profile makes the latter an acceptance condition. A human signature in one observed quorum MUST NOT establish proposition (b); a genesis key set MUST NOT be presented as an inferred root-grant signing quorum; actor binding MUST NOT be counted as an owner approval. Counts MUST state their unit, deduplicate exact credentials, exclude evidence-only vouchers (a human-associated credential count MUST include only credentials whose assessment is established and report counting-authorization and actor-binding sets separately, and a count under a uniqueness policy MUST name that policy's domain, issuer assumptions and incomplete coverage), and MUST NOT present distinct keys as distinct humans; absent an authenticated uniqueness policy, a distinct-human count is reported as not established. A declared HUMAN class or omitted-class default MUST NOT be reported as a verified assessment. Disclosure MAY hide identities through a reviewed selective-disclosure profile whose public proof binds the same predicate, scope and context. 8.5. Query scope and investigation A query result MUST bind the exact domain, genesis identity, interpretation versions, disclosure scope, evaluated head and time, and MUST distinguish a replay-derived conclusion from unavailable evidence, unsupported interpretation or unverified freshness; missing evidence MUST NOT be relabeled as DENY, and a caller-supplied proof or serialized state MUST NOT acquire established status from matching metadata alone. A query about an earlier prefix MUST report whether the supplied history's head is the same prefix, a verified strict extension (later position and matching commitment) or unverified. A Rampertab Expires 2 May 2027 [Page 38] Internet-Draft Agent Authority History October 2026 historical ALLOW remains an answer about that prefix; present consequential use requires a separate current authorization. Commitment integrity, inclusion, finality, availability, historical authorization, freshness and external outcome MUST be reported as distinct axes. A private or commitment-only deployment MUST NOT claim a publicly reconstructible undisclosed graph. Public reconstruction MUST require independently obtainable bodies, schemas, policies and opening material; an unexplained root alone is insufficient. An indexer, cache or explanation interface MUST NOT be accepted as an authority source because it displays the records. An instantiation MUST support a prospective, duty-scoped investigation policy, an authorized evidence-bound disposition and a durable contest. Activation MUST identify one existing duty, its rules commitment, the activating actor and the prior head, and MUST NOT rewrite earlier meanings or grant general upgrade power; the profile MUST specify one-activation and compatibility rules, signer purposes, authority prerequisites and finite disposition and contest allowances. A disposition MUST distinguish the attester's signed finding from the performer's authorization to record it; replay MUST check each purpose-bound signature, role and session binding, authority and exact evidence commitment; the same actor MAY fill both roles only if both powers and both signature purposes are checked; the writer MUST re-evaluate fresh eligibility of both after each asynchronous signature and again under the writer lock, with the head unchanged, fresh time at or after the signed time and both authority routes unchanged, without altering signed challenges. Assignment, a restored resource, a reported APPLIED outcome or a reviewed report MUST NOT alone close the duty. The duty view MUST distinguish OPEN, COMPLETED_UNDER_POLICY, ESCALATED, NEEDS_REVIEW and CONTESTED, keep the original creation status, apply the profile's review-freshness rule on new evidence or assignment, and report accepted contests until an explicit adjudication resolves them. Completion under a local policy MUST NOT be reported as external proof or legal discharge, and old readers MUST return an explicit unsupported result rather than a misleading status. 9. Execution recovery and continuation 9.1. Admission, dispatch and uncertain outcomes An instantiation MUST support distinct intent, admission, submission attempt, consumption, outcome, observation and receipt states. A configured executor profile MUST bind target identity, schema and version, captured arguments, enforcement mode, business identity and idempotency identity before signing the intent; untrusted request data MUST NOT select callbacks, credentials or destinations outside the configured profile. Rampertab Expires 2 May 2027 [Page 39] Internet-Draft Agent Authority History October 2026 intent --> admission --> [submit] --> consumption --> outcome | | | timeout / crash | unknown v v keep original identity, reconcile via status reserved allowance, and evidence route; outcome UNKNOWN never re-dispatch on an empty lookup Figure 5: An uncertain submission keeps its identity; it is never silently repeated A broker MUST durably record the admitted submission identity before sending. After a timeout, lost response or crash it MUST preserve the original identity, reserved allowance and unknown outcome, MUST NOT dispatch again merely because a lookup is empty, and MUST recover through the original identity and a status or evidence route. A new operation, compensation or restoration MUST obtain its own current authority; a late report MUST be recorded as evidence under current recording authority without manufacturing a receipt, releasing allowance or granting execution permission. The profile MUST state its rollback, full-state-loss and host-trust limitations. A cooperating destination MUST authenticate the coordinator, accept checkpoints only as exact history extensions, durably acknowledge the effective fence and recheck the admission's control tuple and required authority liveness, under the declared time and policy assumptions, at its commit boundary; cancellation and application MUST share the profile's durable ordering boundary; a cancellation after APPLIED MUST be reported as too late; staging a new checkpoint MUST NOT be reported as an acknowledged fence. Atomic effect-and- idempotency commitment MUST be one durable transaction; missing or corrupt restart state MUST fail closed and MUST NOT silently reinitialize a destination; retention of attempt identities and tombstones MUST be bounded and MUST refuse growth rather than forget replay protection. 9.2. Same-case continuation An instantiation MUST provide an explicit continuation mechanism. A same-case storage profile MUST preserve the original domain and genesis, canonical bytes and global positions, interpretation versions, signatures, usage, revocations, nonce state, reservations, attempts and open duties; a suffix-only replay or a fresh genesis MUST NOT be represented as a continuation. A segmented profile MUST reconstruct from genesis or an authenticated starting state, commit immutable segments before publishing their manifest, acknowledge only after the required durable barriers, and reconcile uncertain writes against the committed manifest; conditional append MUST check the Rampertab Expires 2 May 2027 [Page 40] Internet-Draft Agent Authority History October 2026 storage generation and canonical head under an exclusive writer boundary, and orphan data MUST NOT silently become canonical or cause fallback to an older head. Migration MUST be explicit, preserve the originals and existing attempts, usage, identities and capacity obligations, verify the source and prevent concurrent use of the old write path; destination transfer MUST independently validate the transferred complete history before acknowledging its checkpoint; an exact same-history retry MUST preserve the original durable result and MUST NOT create another effect or reset allowance. A storage manifest is integrity evidence under host assumptions, not finality. 9.3. Interfaces and service boundaries An instantiation MUST expose separate read-only inspection, authorization evaluation and controlled write interfaces. CLI, SDK, Model Context Protocol (MCP) and agent-framework bindings are application interfaces, not authority sources; an authenticated caller binding MUST map a connection to the configured actor, session and tenure; untrusted caller parameters MUST NOT select another actor's privilege; and read-only handles MUST NOT become execution capabilities. A protected-resource profile MUST identify the trusted host, custody and access boundary; restoration requires separate authorization and MUST NOT discharge the investigation duty. A service MUST bound its resources, capture one consistent observation per composite query and apply an explicit disclosure policy; a natural-language explanation interface MUST retain the typed result and evidence links and MUST NOT upgrade an unverified conclusion. A durable-job interface MUST persist an opaque handle bound to the original attempt before launch, check caller access and permission on every poll, inspection or cancellation, and MUST NOT infer an effect retry from reconnection; a handle MUST NOT confer authority, and a cancellation acknowledgment MUST distinguish stopping later outgoing phases from cancellation at the destination and from rollback of an applied effect. An authenticated HTTP binding MUST validate issuer, audience, token type and lifetime, MUST reject token-supplied discovery keys or URLs outside the configured trust policy, MUST NOT forward bearer credentials upstream or retain them in records, MUST recheck caller access around asynchronous signing, dispatch and disclosure, and MUST NOT interpret a disconnect, expired token or refusal as cancellation or proof of no effect. A public service profile MUST specify HTTPS and custody boundaries. Access loss after an effect MUST preserve the attempt while withholding disclosure under current policy. 10. Reconciliation Rampertab Expires 2 May 2027 [Page 41] Internet-Draft Agent Authority History October 2026 10.1. Why a decision point is not enough No decision point sees every call: a host may execute a tool without asking, a sub-agent may run without the hook, a script may call a service directly, and a token the agent holds may be used outside any gate. A history that records only what passed through the decision point proves what the decision point saw and decided, not what the agent did. A deployment claiming coverage under this model MUST publish an assessed coverage table (scope, version, period, assessor, known unknowns) classifying every identified effect path as in Table 15. A claim that an agent is "governed" without this table is not supported by the model. +==========+===================================================+ | Class | Meaning | +==========+===================================================+ | enforced | The decision point both decides and performs, or | | | holds the only credentials, with assessed | | | controls that prevent the effect on DENY: | | | credential isolation, protected executors, stale- | | | decision checks, fail-closed behavior. Holding a | | | credential on a hostile host is insufficient | +----------+---------------------------------------------------+ | recorded | The effect can occur without a decision, but an | | | observation feed with documented coverage and | | | loss guarantees is reconciled against the history | | | (Section 10.2) | +----------+---------------------------------------------------+ | open | Neither enforced nor observed | +----------+---------------------------------------------------+ Table 15: Coverage classes for an effect path 10.2. Reconciliation observations An instantiation MUST support RECONCILIATION_OBSERVED as a session- signed finding. The signer MUST be an admitted session whose agent equals the recorded reconciler; an owner signature MUST NOT be accepted in its place. Each observation MUST carry a unique identifier, the reconciler, the source stream and event reference with a digest, the observed call fields with explicit unsupplied- field markers under profile-defined optional-field and absence rules, a MATCHED or UNMATCHED result, the immediately preceding head, the session binding and a purpose-specific signature. A MATCHED reference MUST identify an earlier admission or refusal whose actor equals the observed actor; a match to a refusal MUST NOT be treated as permission or as an effect claim, and the verifier MUST list fields that differ from the matched request and observations whose Rampertab Expires 2 May 2027 [Page 42] Internet-Draft Agent Authority History October 2026 reconciler equals the observed actor. A later observation whose digest equals an accepted one for the same stream and reference MUST be rejected as a duplicate; one whose digest differs, if accepted, MUST carry an equivocation reference to the earliest, which verification lists without invalidating the history. Replay MUST validate schema, session authorization with its fence precedence, reconciler binding and preceding head, then the match and duplicate rules, before capacity. Replay MUST NOT infer provider completeness or re-create undisclosed source bytes from the digest; a cursor keyed by reconciler and stream MUST track the last accepted reference, and opaque source references MUST NOT be assumed ordered. Under the writer lock the writer MUST match at the append head, sign and durably append before advancing its collection checkpoint, recovering a crash through the original source identity without recording twice. A verifier MUST present unmatched, equivocation and mismatch listings as signer claims about supplied feed events: they prove neither complete coverage nor an external effect. Legacy ledger migration MUST append each observation at the current head and MUST NOT back-date history records. Collection intervals, feed loss and matching criteria MUST be reported as deployment evidence. 11. Export, verification and freshness 11.1. The export view An export MUST carry at least: the domain, the concrete profile identifier, authenticated history identity and the genesis event hash, distinguished from the genesis record-chain hash; the heads at both ends of the range; every record in the range with its hash; every owner key rotation at or before the end; where state roots are defined, the roots at both ends, the full state at the start and audit paths for requested records; the owner attestations and witness receipts held for both heads; and the dependency closure of earlier bodies read by transitions. A verifier MUST authenticate its trust anchors and identity first, then signatures and transitions. A later starting state requires full prefix replay or an authenticated starting-root commitment, and the export MUST report starting-state authentication separately from transition validity. Rampertab Expires 2 May 2027 [Page 43] Internet-Draft Agent Authority History October 2026 11.2. What a verifier establishes Given an export and the owner public keys, a verifier that trusts neither agent nor operator can establish: *chain integrity*; *control-record authenticity* (every change of power satisfies the policy in force, bound to position and effect); *session-record authenticity* under each type's rules; *decision reproduction* (every admission was authorized at the head it names and every CORE or budget refusal reproduces); *captured authority* at any position and explicit evaluation time; *refusals*, including which were attested rather than reproduced; *duties and handovers*, including that no grant followed; *reported observations* with their results; *state equality* where an owner-signed root is available; and, where selected, *human-eligibility evidence* against the named policy. It does *not* establish that an action had its effect in the world, that every call passed through the decision point, that timestamps are true, that an owner key was held by the right person, or that the export is the latest state unless freshness evidence from outside the host is available (Table 2). 11.3. Rollback and freshness: local anchors, witnesses and public chains Chain hashing cannot distinguish a history from the same history with a valid suffix removed. Table 16 lists the mechanisms, from a file beside the history to a public chain; they differ in who must be compromised to roll the history back undetected. Rampertab Expires 2 May 2027 [Page 44] Internet-Draft Agent Authority History October 2026 +=============+==================+==============+==================+ | Mechanism | Where the | Defeats | Does not defeat | | | evidence lives | | | +=============+==================+==============+==================+ | Head | A file beside | Truncation | An operator who | | attestation | the history, | by anyone | restores an | | | written after | who cannot | older copy with | | | each owner- | rewrite the | its older | | | attested write | attestation | genuine | | | | | attestation | +-------------+------------------+--------------+------------------+ | Local | An append-only | Truncation | Restoration of a | | anchor log | log the | past any | copy from before | | | history's | logged head | the logged head; | | | writers cannot | | an administrator | | | rewrite | | of both | +-------------+------------------+--------------+------------------+ | Remote | A Merkle- | Rollback to | A copy from | | witness | committed log of | any head the | before the first | | | owner-signed | witness | binding; the | | | head statements | holds; | window while | | | in another trust | records | unreachable; an | | | domain, one | equivocation | administrator of | | | linear chain per | evidence | host and witness | | | history | | | +-------------+------------------+--------------+------------------+ | Public | A commitment to | Rollback or | Unpublished work | | chain | the head, | fork of any | after the last | | anchor | published to a | anchored | anchor; a hidden | | | public, | prefix, for | fork; chain-side | | | permissioned or | anyone who | finality and | | | hybrid ledger | can read the | availability | | | (Section 11.4) | chain | limits | +-------------+------------------+--------------+------------------+ Table 16: Freshness mechanisms, weakest to strongest A conforming instantiation MUST support head attestations and the witness protocol; a deployment MUST configure at least one of the two and SHOULD use an independent witness when its claim requires protection against restoration of all local side files. The deployment MUST report the attested position and the unauthenticated tail, and a reader MUST refuse a copy that lacks an attested head it knows of. A witness accepts a head statement only if it is signed by an owner key in force at that head and its stated previous head is exactly the latest the witness holds; owner code signs only after obtaining the witness's latest head and checking it is a prefix of the history being extended. Every answer is signed over a fresh Rampertab Expires 2 May 2027 [Page 45] Internet-Draft Agent Authority History October 2026 client nonce and validated within a deadline, and is the witness's claim at response time, not proof of unsubmitted work. Clients verify checkpoints with an out-of-band key and check consistency with earlier ones; gossip or independent comparison is needed to reveal disjoint views. Witnesses SHOULD be bound in the history by a control record, and an external identity or creation policy SHOULD require that binding. A witness sees only the genesis, key rotations and head hashes. 11.4. External anchoring profiles An instantiation MAY publish authenticated history commitments to a public, permissioned or hybrid ledger. Anchoring commits a particular prefix; it does not establish the truth of records, complete capture or the absence of a later prefix, and it does not replace Section 11.3's mechanisms or ordinary replay. history head ---> anchor statement ---> outbox (durable, journaled) (owner side) (publisher-signed) | v chain connector --> ledger | barrier: ELIGIBLE / DELAYED <------ finality verifier (effects may wait for a label) (labels, below) Figure 6: Anchoring: statement, outbox, connector, finality, barrier A selected profile MUST identify its chain and trust bootstrap, commitment encoding, publisher authorization, destination and upgrade policy, inclusion and successful-execution checks, finality rule, freshness and availability policy, and behavior on timeout, outage or conflicting evidence. A commitment MUST bind the intended history and authenticated genesis, the exact committed head and state-root semantics, the profile and its predecessor commitment, with an explicit absent-predecessor form for the first; it MUST NOT accept an arbitrary restart as continuation. Owner authentication remains distinct from the publisher's key. A verifier MUST check that a successor's prefix extends the previously accepted committed head rather than accept an increasing sequence number as continuity; a contract accepting a hash proves neither validity nor extension. The profile MUST distinguish independently validated consensus evidence from reliance on a named node; agreement among RPC responses is not a consensus proof, and for layered chains execution and settlement MUST be distinguished. As an informative example, not part of the model, Table 17 shows the labels the reference connector uses for a rollup settling on a layer-1 chain, and the three verification modes it reports. Rampertab Expires 2 May 2027 [Page 46] Internet-Draft Agent Authority History October 2026 +=================+=========================================+ | Label (ordered) | Meaning | +=================+=========================================+ | SUBMITTED | The transaction left the outbox; | | | inclusion unknown | +-----------------+-----------------------------------------+ | L2_INCLUDED | Included in a rollup block reported by | | | the connector's node | +-----------------+-----------------------------------------+ | L1_POSTED | The rollup batch containing it was | | | posted to the settlement chain | +-----------------+-----------------------------------------+ | L1_FINAL | The settlement chain has finalized that | | | batch (about 12 s on the example chain) | +-----------------+-----------------------------------------+ | CEMENTED | The rollup commitment has passed its | | | refutation period (about two weeks) | +-----------------+-----------------------------------------+ Table 17: Informative: the reference connector's finality labels, weakest to strongest; its modes are CONSENSUS_VERIFIED, TRUSTED_NODE and UNVERIFIED Deployments MUST report the latest verified commitment, committed position, known unanchored tail, and the assurance and freshness of chain evidence, and MUST state whether external effects wait for finality or may occur within an exposure window. A timeout is an uncertain submission; retries MUST preserve commitment identity and MUST NOT authorize repeated effects. A profile requiring finality before dispatch MUST recheck current authority at the effect boundary. Public, private and hybrid are deployment descriptions, not assurance levels: a permissioned profile MUST disclose membership, quorum, fault assumptions and governance; a hybrid one MUST say whether it mixes validators, publicly anchors a private commitment, or both. It MUST NOT claim required external participation if an entirely internal quorum can commit; data- availability participation alone is not consensus over the history. Three opt-in tiers are defined, in increasing exposure: *anchoring* of heads (the reference implementation's default); *persistence* of complete record bodies on the chain, which makes the history public and MUST be disclosed as such; and *on-chain execution or verification* of the authority rules, in which the chain is a second implementation that MUST agree with replay and is never an authority over it: no certificate, inclusion proof or quorum can admit an event that replay refuses or refuse one it admits. Rampertab Expires 2 May 2027 [Page 47] Internet-Draft Agent Authority History October 2026 11.5. Federated operators A deployment MAY distribute operation of one history among a consensus committee. Ordering hash publications alone is federated anchoring; federated execution additionally requires participants to validate the record profile and agree on exact bytes, order and resulting commitments. The profile MUST specify membership and epochs, quorum and fault assumptions, deterministic execution, canonical publication, checkpoint and bootstrap rules, available bodies, recovery and membership change; its evidence MUST bind predecessor, ordered records and resulting roots at the heights where they are authenticated, and a pre-state commitment MUST NOT be presented as a post-state one. Several processes under one administrator MUST NOT be described as independent trust domains. Committee membership grants no owner or session authority; every record MUST still satisfy its ordinary rules, and a quorum certificate is not an owner signature. A committee MAY hold a co- signing key enrolled in the AGENT class: it is never sufficient alone, never counts on a rotation or policy change, can never block a power reduction, and can be rotated out by the human-class holders. Replicated execution MUST NOT itself perform external effects; a deployment claiming governed dispatch MUST specify a separate executor boundary, leadership fencing and a retry policy, including how uncertain outcomes are handled. Under its honest-quorum assumptions, federation prevents one operator from replacing committed history and evidences conflicting commits; it does not prevent valid acts signed by a compromised owner, prove exclusive routing, or make false reports true. 12. Optional zero-knowledge proofs An instantiation MAY provide zero-knowledge proofs over an authenticated history, so that a useful fact can be checked while the records establishing it stay private: a disclosed field authenticated, a private delegation chain shown to satisfy an authority or lineage predicate, or an aggregate shown to follow from committed histories. This document selects no mandatory proof system. A proof result MUST identify its evidence scope and MUST NOT itself grant execution authority; a verifier MUST NOT substitute an unspecified proof for required replay evidence. *Relation and statement.* A profile MUST specify a relation R(x, w) with public statement x and private witness w, its permitted record kinds, encodings, bounds, commitments, predicate, outputs and soundness and privacy assumptions. Every value used to satisfy the predicate MUST be constrained to the corresponding committed record; hash-to-field encodings MUST be injective, so reducing a 256-bit Rampertab Expires 2 May 2027 [Page 48] Internet-Draft Agent Authority History October 2026 digest modulo a smaller field is insufficient. The statement MUST bind the relation and version, the intended history and full head, the state root or projection head and count, the subject or selection rule, the question and context, the disclosure policy, the audience, and an explicit non-execution result; the verifier MUST obtain the expected anchor and verifying key independently of the prover. An existential predicate does not identify the verifier's intended subject; universally quantified claims require coverage of their whole domain. A root-membership proof relates to a commitment; a claim over accepted signed histories MUST say how identity, keys, signatures, ordered transitions and resulting roots are verified, and MUST report whatever is assumed rather than proved. A claim relying on absence, revocation status, intersecting authority or accumulated usage MUST cover every record that can change the answer, by complete replay, authenticated exhaustive ranges or another specified completeness relation; an inclusion proof for a granting record alone does not establish the absence of a prohibition. The profile MUST say which witness components are private, public or checked outside the relation; a membership relation MUST bind the canonical record, its leaf, path and anchor; a projection relation MUST bind its encoding, range and projection head and its verifier MUST NOT report omitted transitions as verified; a subject-specific profile MUST bind the selected subject, or a hiding commitment opened inside the relation, to the record used for the predicate. *Profiles.* Selective disclosure MAY reveal chosen fields or predicates of a hidden record, binding them to the same canonical record and anchor; selective-disclosure signatures such as [I-D.irtf-cfrg-bbs-signatures] are a building block, not a replacement for transitions, and ordinary Merkle openings MUST NOT be labeled zero-knowledge. A private authority profile MAY prove that a request met a named predicate at a head while keeping delegators and terms private; its relation MUST evaluate session, lifecycle, edges, attenuation, intersections, prohibitions, revocations and selected budgets under the same request and state. A private human-lineage profile MUST give distinct identifiers to its predicates (the named root actor, human participation in the actual issuance quorum, or a policy requiring one), MUST keep lapsed distinct from human and unknown from non-human, and proves satisfaction of the evidence rules, not biological truth. An aggregate profile MUST define the population's enrollment and inventory commitment, selection and deduplication rules, the unit counted, treatment of unknowns, and the statistic; the verifier MUST authenticate the inventory independently, and the relation MUST account for every eligible item. An illustrative result such as 62 established-true of 100 paths with 10 unknown is a statement about that declared population and denominator, not about non-human remainder. A selective-disclosure- signature profile MUST specify issuer trust, message-to-record Rampertab Expires 2 May 2027 [Page 49] Internet-Draft Agent Authority History October 2026 binding and history relationship and MUST NOT reinterpret an existing signature under another scheme. A private lineage relation MUST bind each classification to the signing credential, its issuer and voucher, the assessment-policy version and the status context, evaluated under the policy in force before the event. A private budget relation MUST bind its inputs to the same admitted operations, periods, policy and carry state and enforce exhaustion and ordering; a continuation MUST NOT substitute recaptured inputs under an old identity. *Privacy and lifecycle.* Zero knowledge limits disclosure beyond the public statement; it does not conceal the statement. A profile MUST list observable outputs and metadata, assess low-entropy guessing and linkage, and specify cohort, suppression and repeated-release rules; a verifier MUST NOT label an exact aggregate differentially private because its computation is proved. Any differential-privacy mechanism MUST be separately specified and bound to the proved computation ([DWORK-ROTH]). The verifier MUST report the predicate proved, the assurance axes covered, proof-system and setup trust (for example [GROTH16]), external checks and remaining unproved axes; STATE, BUDGET and BOTH modes keep their meanings; multi-stage proofs MUST bind each stage's anchors, program and counters and reject joins across unrelated states. A deployment MUST version relations, circuits and keys and state which it accepts historically. Fully homomorphic encryption [FHE-INTEGERS] is named as a forward path for computing selected statistics over encrypted inputs; an FHE profile MUST specify who encrypts, evaluates and decrypts, exact or approximate arithmetic and its error bound, and the integrity mechanism, since confidentiality alone does not show the right inputs were used ([SEAL-SECURITY]). Appendix B reports what has been proved so far. A differential-privacy profile MUST define adjacency, the protected unit, contribution bounds, sensitivity, mechanism, parameters, randomness and an accountant for repeated releases, and MUST include public commitments and auxiliary outputs in its analysis. An FHE profile with several key holders MUST specify its key-sharing, threshold or multi-key construction, and a combined FHE/ ZK profile MUST bind ciphertexts, keys, program, input commitments and result across every component and assess output, size and access- pattern leakage. *Rules that hold across every profile.* Failure, unsupported profiles and absent required evidence MUST remain distinguishable from verified success. A composed verifier MUST compare the shared statements of its components and require every selected component check and every proof dependency; two valid proofs alone are insufficient. A profile MUST define empty-input and missing-evidence behavior, and its verifier MUST reject a success obtained by omitting a required subject, range or dependency. An owner signature on a Rampertab Expires 2 May 2027 [Page 50] Internet-Draft Agent Authority History October 2026 root alone MUST NOT be reported as proof of accepted replay. A hidden-record inclusion result MUST NOT be reported as authority, revocation freshness, budget compliance, duty closure, complete capture or external truth unless those checks are covered by its relation and authenticated context. STATE, BUDGET and BOTH modes MUST retain their declared meaning. Counting qualified credentials MUST NOT be reported as counting distinct people without a separately verified uniqueness mechanism. An aggregate over an empty population MUST return an explicit no-data result rather than a percentage; a profile selecting a non-default denominator MUST disclose its exclusions; any external inventory certification or participant- selection assumption MUST appear in the result. A deployment relying on a trusted setup MUST identify the ceremony, custody and compromise assumptions it accepts; provers MUST use fresh proof randomness where the system requires it; unknown or retired versions MUST be rejected under the stated acceptance policy. An FHE profile MUST NOT silently use approximate equality for an exact authority predicate, and encryption confidentiality alone MUST NOT be reported as proof that the right inputs were used. A profile MUST identify its proof system, verifying-key and parameter identities, circuit bounds and the configuration that provides zero knowledge in every wrapper; MUST specify opening retention, prover access, key-compromise response and treatment of unavailable evidence; and, where it claims hiding commitments, MUST identify the hiding construction, entropy assumptions and custody of openings. 13. Applicability beyond AI agents The separation of authority, actor, session, office and effect applies wherever an actor is a process or a credential subject (Table 18). A profile using these mappings MUST preserve the distinction between a recorded grant, evidence of a request's authorization, and mediated execution. Rampertab Expires 2 May 2027 [Page 51] Internet-Draft Agent Authority History October 2026 +===============+=============================+====================+ | Setting | Mapping | Stated limit | +===============+=============================+====================+ | Processes and | Each process an agent, each | Recording a | | operating | instance a session, inter- | process as an | | systems | process operations requests | agent provides no | | | under grants; epochs fence | isolation, memory | | | old instances | safety or truthful | | | | device reports; a | | | | profile claiming | | | | mediation MUST | | | | publish its | | | | coverage under | | | | Section 10.1 | +---------------+-----------------------------+--------------------+ | Revocable | The history records an | Offline | | credentialing | issuer's grants to people | verification of an | | | or agents, their scope and | old status cannot | | | withdrawal; a profile MUST | show that no later | | | distinguish subject, issuer | revocation exists; | | | and owner and define | a credential is | | | presentation (authenticated | not permission to | | | subject-to-key binding and | act without an | | | presentation proof, | explicit policy | | | audience, purpose, replay | | | | resistance), expiry, | | | | suspension and revocation | | +---------------+-----------------------------+--------------------+ | Lineage of | The succession of models, | Recorded heritage, | | non-human and | services or robots recorded | not identical | | embodied | under the same history; a | behavior or | | actors | lineage answer MUST derive | physical integrity | | | from signed creation, | | | | appointment, handover and | | | | revocation records | | +---------------+-----------------------------+--------------------+ | State | A root class for authority | No claim of legal | | authority | asserted by a public body | validity or | | roots | under law, with public key | enforceability; | | | ceremonies and rotations; a | participation is | | | relying party MUST report | voluntary and no | | | whether a chain terminates | registry is | | | at such a root, elsewhere, | defined | | | or cannot be resolved | | +---------------+-----------------------------+--------------------+ Table 18: Other settings the model applies to Rampertab Expires 2 May 2027 [Page 52] Internet-Draft Agent Authority History October 2026 In addition: a process profile claiming that all interaction is mediated MUST identify and enforce its execution boundaries, including privileged calls, shared memory, device access, background tasks and administrative bypasses; a credentialing verifier MUST state the captured status position, evaluation time and freshness policy it used, and renewals MUST preserve linkage without silently restoring withdrawn authority; an actor-lineage profile MUST state how a successor is bound to its predecessor's records, which predicate classifies an actor as non-embodied or embodied, and how unknown or unverifiable links are reported; a state-authority profile MUST identify the issuing body and its legal basis, MUST create and publish the root's keys through a public ceremony recorded in a publication of record, MUST make rotation and revocation equally public, MUST define how a history references the root and authenticates that reference, and an unresolved chain MUST NOT be treated as state authority. 14. Security Considerations 14.1. Threat model Operational guidance that complements this section is described in Appendix B. The verifier distrusts agents, the writer and the operator; an execution claim separately depends on a disclosed executor boundary. Cryptographic conclusions assume authenticated trust anchors, correctly implemented profile rules, collision-resistant hashes and unforgeable signatures. No language model is a proof or policy authority. Table 19 lists each adversary, the response and the residual limit. +=============+=================+===============+===================+ |Adversary | Ability | Verification | Residual limit | | | | or deployment | | | | | response | | +=============+=================+===============+===================+ |Host/operator| Bypass hooks, | Authenticate | Unseen effects, | | | alter | trust | withheld | | | files/clock/ | anchors; | evidence, and | | | configuration, | replay; | unattested tails | | | withhold | compare held/ | remain unproved | | | bodies | witnessed | | | | | heads; | | | | | classify | | | | | effect paths | | +-------------+-----------------+---------------+-------------------+ |Agent/session| Propose false | Epoch/expiry/ | Valid key claims | Rampertab Expires 2 May 2027 [Page 53] Internet-Draft Agent Authority History October 2026 |thief | claims, sign | lifecycle | need not be true | | | with an | fences, | externally | | | admitted | authority re- | | | | session, or | derivation, | | | | advance | purpose- | | | | history time | specific | | | | up to the | signatures; a | | | | session's | writer that | | | | expiry, the | checks | | | | next owner- | session | | | | attestation | timestamps | | | | expiry under | against a | | | | the attested | trusted clock | | | | floor, or, | (Section | | | | where the | 14.2); a | | | | genesis sets a | session-time | | | | session-time | horizon | | | | horizon, that | | | | | horizon past | | | | | the latest | | | | | time-advancing | | | | | owner-signed | | | | | record | | | +-------------+-----------------+---------------+-------------------+ |File writer | Edit, rehash, | Check | A previously | |without | splice or | signatures, | valid prefix with | |signing keys | truncate a | chain, exact | all old local | | | store | heads and | side files can be | | | | external | restored | | | | commitments | | +-------------+-----------------+---------------+-------------------+ |Owner-key | Satisfy a | Eligible | A valid | |thief | compromised | distinct-key | signature/quorum | | | control | thresholds | does not prove | | | quorum, or the | where | human intent; | | | separate head- | selected, | head and control | | | signature rule | dedicated | policies can | | | | keys, | differ | | | | committed- | | | | | next | | | | | possession, | | | | | rotation and | | | | | incident | | | | | review | | +-------------+-----------------+---------------+-------------------+ |Compromised | Contribute one | Policies | Cannot authorize | |or | signature | requiring at | alone or alter | |manipulated | toward a | least one | owner keys or | Rampertab Expires 2 May 2027 [Page 54] Internet-Draft Agent Authority History October 2026 |agent co- | threshold on | human-class | policy; its one | |signer key | non-policy | signature; | contribution | | | control events | exclusion of | still counts | | | | agent | where the policy | | | | signatures | permits | | | | from owner- | | | | | key and | | | | | policy | | | | | changes; | | | | | rotation | | +-------------+-----------------+---------------+-------------------+ |Holder of a | Under the | Rotation | Under a rotation | |stolen or | recovery | threshold of | threshold of one | |escrowed | option, sign | two or more | it takes the | |committed | the rotation | with distinct | history alone; | |next key | that reveals | custodians | without recovery, | | | it; otherwise | per committed | loss of every | | | withhold it | key; leaving | current key is | | | and freeze the | recovery | permanent by | | | key set | absent and | design | | | | relying on | | | | | key-material | | | | | backup; | | | | | custody of | | | | | each | | | | | committed key | | | | | as a current | | | | | key | | +-------------+-----------------+---------------+-------------------+ |Sole | Choose the | Attestation- | A single signer | |authorizer of| record's | horizon bound | still sets time | |a control | timestamp: | on a single | up to the | |record | lapse co- | human-class | horizon; two | | | owners, expire | signer under | human-class | | | sessions, | the attested | signers set any | | | budgets and | floor; | time; under the | | | dated grants, | rotation | declared floor | | | or pin time | threshold of | there is no | | | | two or more | bound; the model | | | | | has no clock | +-------------+-----------------+---------------+-------------------+ |Coerced or | Attest an | Statements | Collusion between | |colluding | agent-held key | inert until | quorum and | |attester | as human, or | the owner | attester is | | | refuse renewal | quorum embeds | indistinguishable | | | | them; two | from consent; | | | | attesters | with no | | | | required; the | cooperating | Rampertab Expires 2 May 2027 [Page 55] Internet-Draft Agent Authority History October 2026 | | | quorum | attester, keys, | | | | removes | attesters, | | | | attester and | thresholds and | | | | statement by | floor stay frozen | | | | policy | | | | | rotation; | | | | | lapsed keys | | | | | keep power | | | | | reduction, | | | | | checkpoints | | | | | and | | | | | restoration | | +-------------+-----------------+---------------+-------------------+ |Witness or | Withhold | Pinned keys, | A nonce alone | |witness-key | replies or | nonce/ | does not stop | |thief | serve disjoint | deadline, | split views; | | | views | inclusion/ | unsubmitted work | | | | consistency | is invisible | | | | checks, | | | | | remembered | | | | | checkpoints | | | | | and | | | | | independent | | | | | comparison | | +-------------+-----------------+---------------+-------------------+ |Provider/ | Omit, rewrite | Retain | Signatures | |counterparty | or fabricate | digest/issuer | authenticate the | | | reports | evidence, | reporter, not | | | | list | effect or | | | | equivocation | complete coverage | | | | and match | | | | | differences | | +-------------+-----------------+---------------+-------------------+ |Reconciler | Mis-map calls, | Admitted- | No completeness | | | omit | session | theorem; matching | | | observations, | binding, | actor alone does | | | self-observe | explicit | not establish | | | | absent | execution binding | | | | fields, | | | | | source | | | | | identity, | | | | | duplicate/ | | | | | equivocation | | | | | lists | | +-------------+-----------------+---------------+-------------------+ |External | Change policy, | Same-request | Cross-service | |decider/ | disappear, | policy | atomicity and | |destination | return stale | binding, | full destination | Rampertab Expires 2 May 2027 [Page 56] Internet-Draft Agent Authority History October 2026 | | results | fail-closed | rollback require | | | | required | a stronger | | | | policy, | profile | | | | acknowledged | | | | | fence/status | | | | | recovery | | +-------------+-----------------+---------------+-------------------+ |Anchor | Withhold or | Authenticate | Unpublished work/ | |publisher or | misreport | chain/profile | forks remain | |chain-facing | publication; | and intended | invisible; fees, | |RPC | submit a stale | history; | outage and stale | | | or conflicting | validate | bootstrap can | | | commitment | execution, | stop freshness | | | | finality and | | | | | committed- | | | | | prefix | | | | | continuity; | | | | | retain | | | | | independent | | | | | checkpoints | | +-------------+-----------------+---------------+-------------------+ |Federation | Propose | Independent | Corrupt quorum, | |member or | invalid order/ | deterministic | common | |coordinator | state, | replay, | administration, | | | withhold | authenticated | unavailable | | | bodies, | membership/ | evidence or | | | equivocate or | quorum, | unsafe membership | | | censor | actual post- | change can defeat | | | | state | the profile | | | | commitment | | | | | evidence and | | | | | retained | | | | | bodies | | +-------------+-----------------+---------------+-------------------+ |Dispatcher or| Repeat an | Fresh effect- | Consensus alone | |former leader| external call | boundary | supplies neither | | | or execute | checks, | external | | | after | committed | atomicity nor | | | authority | attempt | exactly-once | | | changes | identity, | effects | | | | leadership | | | | | fencing and | | | | | downstream | | | | | idempotency/ | | | | | status | | +-------------+-----------------+---------------+-------------------+ |Agent using a| Reuse enrolled | Exact-key | Enrollment alone | |human's | credentials, | enrollment | does not prove | Rampertab Expires 2 May 2027 [Page 57] Internet-Draft Agent Authority History October 2026 |device or key| automate | binding; | current human | | | prompts or | qualified | participation; an | | | sign after | custody; | unlocked/exported | | | unlock | fresh action | key can be | | | | approval | misused | | | | where | | | | | required | | +-------------+-----------------+---------------+-------------------+ |Dishonest | Certify | Authenticated | Colluding roots | |voucher or | fabricated | bootstrap, | or real humans | |Sybil ring | relationships | another- | can lie; distinct | | | or agent- | person | keys are not | | | controlled | checks, | necessarily | | | keys | scoped signed | distinct people | | | | vouches, | | | | | diversity and | | | | | prospective | | | | | status | | | | | handling | | +-------------+-----------------+---------------+-------------------+ |Coercer or | Manipulate the | Independent | No biometric/ | |deepfake | subject or | contact, | signature proves | |attacker | impersonate | context-bound | voluntary intent; | | | live | live checks, | remote presence | | | interaction | in-person | tests remain | | | | option and | fallible | | | | incident | | | | | recovery | | +-------------+-----------------+---------------+-------------------+ |Authenticator| Falsify | Qualified | Verification | |or | biometric/key- | method- | still depends on | |attestation | protection | specific | the device, | |issuer | evidence | profiles, | issuer and | |compromise | | pinned | assessment | | | | metadata/ | process | | | | trust and | | | | | status | | | | | evidence, re- | | | | | attestation | | +-------------+-----------------+---------------+-------------------+ |Registry/ | Hide | Committed | Availability and | |status | revocation, | historical | unseen later | |operator | replay old | cutoffs, | status remain | | | good status or | current | separate; hashes | | | correlate | freshness | may still enable | | | subjects | checks, | correlation | | | | private | | | | | evidence, | | Rampertab Expires 2 May 2027 [Page 58] Internet-Draft Agent Authority History October 2026 | | | independent | | | | | checkpoints | | +-------------+-----------------+---------------+-------------------+ Table 19: Threat model The cryptographic basis is: chain hashing for integrity within the record; owner signatures over position and effect for every change of power; type-specific session signatures; re-derivation of non- migrated admissions and CORE/BUDGET refusals on replay, while CONNECTOR, reconciliation and external-decider findings remain signer claims; and, for freshness, owner-attested heads held outside the host. 14.2. The host is trusted by the engine, not by the verifier The engine runs inside the host with the host's permissions; a host can skip the check, patch the clock or read key files. The model confines what the host can do undetected rather than pretend otherwise. Unhooked calls are not seen (Section 10.1); a verifier assessing a completeness claim MUST obtain and report the coverage table. A decision is point-in-time. History time is the writers' claim: a clock set forward expires grants early, a clock set backward is caught only when it would precede the head. Deployments SHOULD use a monotone, trusted clock, readers SHOULD refuse a head unreasonably ahead of their own clock, and where grants and budgets depend on time a deployment SHOULD identify a trusted-time or witness-receipt-time binding and its uncertainty. A single signer's control over time is bounded only as Section 4.6 states. A session key has similar control. A session record carries a timestamp chosen by its signer. Replay rejects it if that time is at or past the session's expiry, and, under the attested floor, at or past the expiry of an owner attestation that was still valid at the preceding head (Section 4.3). Someone who steals a session key and can add records directly can therefore move history time forward to just before the earlier of those limits. Advancing the epoch stops further records but does not move time back. Deployments SHOULD accept session records only through their own writer, which checks each timestamp against the deployment's trusted clock; a verifier cannot tell afterwards whether that writer was used. A history whose genesis sets a session-time horizon (Section 4.3) bounds this in replay itself: a session key can then move history time no further than that horizon past the time of the latest owner-signed record that advanced history time. The cost is operational: once the horizon is reached, sessions cannot record until an owner writes such a record, so an unattended deployment needs scheduled owner records and therefore an owner key that is available. Rampertab Expires 2 May 2027 [Page 59] Internet-Draft Agent Authority History October 2026 14.3. Key compromise +==========+====================+==================+================+ |Key | What its thief | Response | Limit | | | can do | | | +==========+====================+==================+================+ |Owner | Produce valid | Rotation; pre- | Signatures | |(enough to| control records | rotation keeps a | establish | |meet the | and attestations | thief holding | which keys | |policy) | | only current | signed, not | | | | keys from | who | | | | locking the | authorized; | | | | owner out, | one key | | | | provided the | suffices in a | | | | committed key is | single-key | | | | kept off the | profile; a | | | | host | retired key | | | | | still signs a | | | | | copy cut back | | | | | to before its | | | | | rotation, and | | | | | only later- | | | | | head evidence | | | | | tells that | | | | | copy from the | | | | | real one | +----------+--------------------+------------------+----------------+ |Committed | Under recovery, | Custody as a | Under a | |next key | co-sign the | current key; | threshold of | | | revealing | rotation | one, its | | | rotation; | threshold of two | holder takes | | | otherwise freeze | with distinct | the history | | | the set by | custodians | alone; the | | | withholding | | threshold | | | | | counts keys, | | | | | not custodians | +----------+--------------------+------------------+----------------+ |Session | Sign admissions, | Epoch advance, | Can still fail | | | refusals, | which bypasses | at absolute | | | receipts and | declared limits; | caps or on | | | duties until | finite session | unavailable | | | expiry or epoch | expiry | storage | | | advance; advance | | | | | history time up | | | | | to its expiry, | | | | | the next owner- | | | | | attestation | | | | | expiry under the | | | Rampertab Expires 2 May 2027 [Page 60] Internet-Draft Agent Authority History October 2026 | | attested floor, | | | | | or a set session- | | | | | time horizon past | | | | | the latest time- | | | | | advancing owner- | | | | | signed record, if | | | | | its records | | | | | bypass the | | | | | deployment's | | | | | writer | | | | | (Section 14.2) | | | +----------+--------------------+------------------+----------------+ |Witness | Equivocate: show | Remembered | Cannot forge | | | different logs to | checkpoints; | owner | | | different clients | several | statements or | | | | independent | alter contents | | | | witnesses | it never sees | +----------+--------------------+------------------+----------------+ |Reconciler| Mis-map or omit | Admitted-session | Admission does | |session | observations | binding, listing | not certify | | | | rules | honesty or | | | | | independence | +----------+--------------------+------------------+----------------+ |Chain | Stall progress or | Verifiers check | None can forge | |publisher,| publish invalid | validity and | owner | |validator,| commitments; | prefix | authorization; | |dispatcher| repeat a call | continuity; | a hidden fork | | | | committee fault | stays hidden | | | | threshold; | | | | | fencing and | | | | | idempotency | | +----------+--------------------+------------------+----------------+ Table 20: Key compromise Rampertab Expires 2 May 2027 [Page 61] Internet-Draft Agent Authority History October 2026 A key used under this model SHOULD sign only domain-separated challenges defined by its profile, so that it cannot serve as a signing oracle for another protocol. Distinct committed keys SHOULD be held by distinct custodians; profiles SHOULD require finite session expiry outside migrated prefixes; and the incident procedure SHOULD review the compromise interval, append revocations and advance epochs. FROST [RFC9591] or another threshold scheme may produce an ordinary profile-valid signature; that is distinct from a policy requiring separate signatures by several enrolled keys. A deployment with more than one human key SHOULD require at least two signatures for a key rotation, and with a threshold of two or more SHOULD set the power-reducing types to one so that one present human can always stop an agent. Uninstall, upgrade and file-deletion restrictions are operating-system controls, not consequences of the signature scheme. 14.4. Rollback, refusals, delegation, availability, claims *Rollback.* Without evidence outside the host, a rollback to any head the owner once attested is undetectable. A reachable witness bound to the history closes this; what remains is a copy from before the first binding, the window while the witness is unreachable, the administrator of both host and witness, and the records after the last witnessed head. A deployment MUST state which apply. Anchors and committee checkpoints add known-head evidence; a fresh reader needs an authenticated bootstrap; a hidden fork remains hidden. *Unsigned records and refusals.* Only control records carry an owner signature; a party who can write the file but holds no admitted session cannot add admissions, refusals or observations. Instantiations SHOULD sign intent declarations, so that a file writer cannot squat identifiers. A denied agent cannot fill the history with refusals: they are session-signed, coalesced and rate-limited, bounded by declared capacity that never refuses power-reducing controls, and a CORE or budget refusal the state would have allowed is rejected on replay. CONNECTOR claims can still be false. *Delegation and prohibition.* Attenuation is a replay rule, prohibition scope and path selection decide what is overridden, and required intersections need live partners; these three let a verifier bound the maximum authority any actor could have had from the history alone. Retiring a counterparty does not deny consequential requests that name it; stop them with a prohibition, a budget or at the connector. A proof-size refusal is not a denial of authority: a power-reducing revocation or termination can remove an oversized winning path and let a smaller granted path produce a proof, turning that refusal into an ALLOW. To stop an actor, use a prohibition, a zero-cap budget, a fence or a termination, never a proof-size limit. Rampertab Expires 2 May 2027 [Page 62] Internet-Draft Agent Authority History October 2026 *Availability.* Declared capacity preserves withdrawal; absolute caps, disk failure, a stale lock or signer failure can still stop revocation and termination, so an independent executor stop channel is a deployment requirement where safety depends on withdrawal. Deployments MUST plan for a history's terminal state and a successor, MUST choose and document whether a witness outage stops gated owner writes or permits them up to a bound, and must keep a separate emergency stop boundary when effects are finality-gated. *Receipts and outcomes are local claims.* A receipt establishes that a session signed a claim at a head; an effect, that a measurer reported a quantity; an outcome, that an attester reported a status. Deployments MUST NOT describe a history as proof of what an agent did, as opposed to what the decision point saw and decided and what signers claimed. *Cryptographic agility.* The model names no mandatory algorithm. An instantiation MUST specify its hash, signature suites and canonical encoding, MUST bind the suite to each key when the key is declared, and SHOULD require strict signature verification (for Ed25519 [RFC8032]: canonical encodings, no small-order keys, cofactorless verification). 15. Privacy Considerations A history records who was allowed to do what, who was refused and who owes what; it is not confidential by construction. Deployments SHOULD keep secrets out of identifiers and descriptions, SHOULD commit to terms by digest and hold content elsewhere, and SHOULD limit disclosure and retention. Encryption requires a profile defining what is committed and how auditors recover it. The model provides no erasure: a record needed for replay cannot be removed, so identifiers that must later be erasable SHOULD be pseudonymous or held outside the history under a salted commitment. Observation call fields, effects and counterparty receipts import third-party data into the history and SHOULD be minimized to what matching and verification need. Query answers MAY withhold fields under a disclosure policy; that policy does not protect the file. Refusal records deserve particular care, since they record what a person's agent attempted and was denied; access to them SHOULD be governed at least as strictly as access to admissions. A witness or transparency service learns that a history existed and advanced at given times; the witness design exposes only genesis, rotations and head hashes, while registration of records exposes their content unless by hash, and even hash-only registration reveals cadence. Unsalted hashes of low-entropy names permit guessing. Public anchors reveal publication cadence, account and commitment Rampertab Expires 2 May 2027 [Page 63] Internet-Draft Agent Authority History October 2026 metadata; the persistence tier makes the history public. Cross- history correlation is possible wherever an identifier recurs; deployments that need unlinkability SHOULD use pairwise identifiers and SHOULD avoid registering raw identifiers with a shared service. Selective disclosure cannot remove transitions needed for replay, and a redacted view must state which conclusions remain verifiable. A PHL attestation profile should retain only minimal signed verification and vouching facts, keeping biometric templates and media out of the history and registry. Device identifiers and vouch graphs can still reveal identities and relationships; a digest is not anonymization, and hashes alone MUST NOT be described as anonymity. Optional proofs keep the public-statement and aggregate-release limits of Section 12: computing an aggregate correctly does not establish unbiased enrollment, and a private lineage predicate does not establish physical humanity beyond its evidence policy. RFC 6973 [RFC6973] describes the correlation and identification threats that apply. 16. IANA Considerations This document has no IANA actions. A future wire profile may register media types for exports and head statements, and COSE header parameters or CBOR Web Token (CWT) claims for the SCITT mapping; those registrations belong to the profile. 17. References 17.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, . 17.2. Informative References [AUDIT-BOF] Kuehlewind, M., Birkholz, H., and P. Dingle, "BoF request: Agent Use of Delegation and Interaction Traceability (AUDIT)", October 2026, . Rampertab Expires 2 May 2027 [Page 64] Internet-Draft Agent Authority History October 2026 [DWORK-ROTH] Dwork, C. and A. Roth, "The Algorithmic Foundations of Differential Privacy", DOI 10.1561/0400000042, 2014, . [FHE-INTEGERS] van Dijk, M., Gentry, C., Halevi, S., and V. Vaikuntanathan, "Fully Homomorphic Encryption over the Integers", Cryptology ePrint Archive 2009/616, 8 June 2010, . [GROTH16] Groth, J., "On the Size of Pairing-based Non-interactive Arguments", Cryptology ePrint Archive 2016/260, 31 May 2016, . [I-D.birkholz-verifiable-agent-conversations] Birkholz, H., Heldt, T., and O. Steele, "Verifiable Agent Conversation Records", Work in Progress, Internet-Draft, draft-birkholz-verifiable-agent-conversations-01, 31 August 2026, . [I-D.helixar-hdp-agentic-delegation] Dalugoda, A., "Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems", Work in Progress, Internet-Draft, draft-helixar-hdp- agentic-delegation-03, 6 October 2026, . [I-D.ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, . [I-D.ietf-wimse-arch] Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . Rampertab Expires 2 May 2027 [Page 65] Internet-Draft Agent Authority History October 2026 [I-D.irtf-cfrg-bbs-signatures] Looker, T., Kalos, V., Whitehead, A., Lodder, M., and G. Bernstein, "The BBS Signature Scheme", Work in Progress, Internet-Draft, draft-irtf-cfrg-bbs-signatures-14, 29 October 2026, . [I-D.izmaylov-agent-permission-receipts] Izmaylov, P., "Signed Permissions and Action Receipts for Automated Agents", Work in Progress, Internet-Draft, draft-izmaylov-agent-permission-receipts-01, 24 October 2026, . [I-D.kuehlewind-audit-architecture] Kuehlewind, M. and H. Birkholz, "An Architecture for Auditing Agent Delegation and Interactions", Work in Progress, Internet-Draft, draft-kuehlewind-audit- architecture-01, 7 September 2026, . [IRONTRELLIS-CHECKLIST] RAmEx Labs, "IronTrellis Install Checklist", Informative operational guidance only, October 2026, . [IRONTRELLIS-DISCLOSURE] RAmEx Labs, "IronTrellis Commissioning Disclosure", Informative operational guidance only, October 2026, . [IRONTRELLIS-LEAN] RAmEx Labs, "Why We Check IronTrellis With Lean", Informative note on what was machine-checked, what it caught, and its limits, October 2026, . [IRONTRELLIS-LEAN-PROOFS] RAmEx Labs, "Selected Lean proofs, IronTrellis 1.0.0-rc.2", Lean 4 sources of the headline theorems, with premises and rebuild commands, October 2026, . Rampertab Expires 2 May 2027 [Page 66] Internet-Draft Agent Authority History October 2026 [IRONTRELLIS-RATIONALE] RAmEx Labs, "Why IronTrellis, Why Now, What is the Long Horizon", Informative rationale only, October 2026, . [IRONTRELLIS-RELEASE] RAmEx Labs, "IronTrellis 1.0.0-rc.2 release downloads", Packages, checksums, documents and the zero-knowledge demonstration download, October 2026, . [IRONTRELLIS-REPO] RAmEx Labs, "IronTrellis 1.0.0-rc.2", Open-source implementation, release candidate, October 2026, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Rampertab Expires 2 May 2027 [Page 67] Internet-Draft Agent Authority History October 2026 [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9591] Connolly, D., Komlo, C., Goldberg, I., and C. A. Wood, "The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures", RFC 9591, DOI 10.17487/RFC9591, June 2024, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . [SEAL-SECURITY] Microsoft, "Microsoft SEAL: Correct Use and Security Guidance", Mutable project security guidance; inspected 11 October 2026., n.d., . [VC-DM2] "Verifiable Credentials Data Model v2.0", 15 May 2025, . [WEBAUTHN3] "Web Authentication: An API for accessing Public Key Credentials, Level 3", 25 August 2026, . Rampertab Expires 2 May 2027 [Page 68] Internet-Draft Agent Authority History October 2026 Appendix A. Example encoding: an append-only JSON Lines history This appendix is informative. It describes the "format 2" history of the IronTrellis implementation, to show that the model is implementable and to fix vocabulary. Format 2 was released with the first public release candidate; later rule changes are a new format, and format-2 histories keep their verdicts. Nothing here is normative for the model. A.1. Store, chain and state A history is a UTF-8 file with one JSON object per line: a version literal, the previous record hash, the event {id, type, timestamp, data} with data canonically encoded (keys in UTF-8 byte order, integers only, amounts as decimal strings), and the line's own record hash: recordHash(p) = SHA-256( "irontrellis-record/2" || 0x00 || prev || SHA-256(canonical(event_p)) || be64(p) ) with prev thirty-two zero bytes at p = 0. The head is {hash, position, canonicalTime} and recordHash(0) identifies the history. After every event the state is a sorted set of closed records (event, genesis, owner key epoch, principal, agent, role, tenure, succession, session, authority, usage, nonce, intent, receipt, obligation, duty, anchor, witness binding and policy, budget, counterparty, refusal, effect, observation, reconciliation cursor); leaves are SHA- 256(0x00 || kind || 0x00 || key || 0x00 || SHA- 256(canonical(record))) sorted by (kind, key), and the root follows [RFC6962]'s recursion. A checkpoint at c commits to the state after c-1. A.2. Record kinds and signatures +================+================================+================+ | Class | Types (42 in all, codes 0 to | Signed by | | | 40 and 42; code 41 is | | | | unassigned) | | +================+================================+================+ | Genesis | 1 | Unsigned; | | | | identity | | | | authenticated | | | | out of band | +----------------+--------------------------------+----------------+ | Control | Principal, agent, role, | Owner key(s) | | | succession rule, appointment, | in force, over | | | unappointment, transfer, | the control | | | session admission, epoch | challenge | Rampertab Expires 2 May 2027 [Page 69] Internet-Draft Agent Authority History October 2026 | | advance, grant, revocation, | | | | termination, anchor, owner key | | | | rotation, witness binding and | | | | unbinding, budget declaration, | | | | update and close, state | | | | checkpoint, counterparty | | | | registration and retirement | | +----------------+--------------------------------+----------------+ | Session | Intent declaration, admission, | The admitted | | | consumption, outcome, receipt, | session's key | | | refusal, effect, counterparty | | | | receipt wrapper, | | | | reconciliation observation | | +----------------+--------------------------------+----------------+ | Administrative | Obligation creation, | A session, | | | performance assignment, status | under an | | | change, outcome observation, | administrative | | | attempt-duty creation, | authorization | | | assignment and review, | carrying its | | | investigation activation, | own authority | | | disposition, contest | proof | +----------------+--------------------------------+----------------+ Table 21: Event classes in format 2 A control event carries controlAuthorization = {keyId, signature} over the SHA-256 of { "version": "irontrellis-control-authorization/2", "domain": , "eventId", "eventType", "timestamp", "previousHead": {"hash": recordHash(p-1), "position": p-1}, "effectHash": SHA-256(canonical(data without the authorization containers)) } Owner key epochs are [{fromPosition, keys, nextKeyDigests}]; a rotation out of a committed epoch reveals a committed key with its proof of possession over the same challenge and commits again. Optional distinct-key policies add a global threshold, per-type thresholds, agent and human classes, pre-event quorum checks and a second authorization container excluded from the effect hash; a history without these fields replays unchanged. Session events carry {runtimeSessionId, credentialKeyId, controlEpoch} and a type-specific challenge; admissions sign the decision-time challenge of Section 5.3. Rampertab Expires 2 May 2027 [Page 70] Internet-Draft Agent Authority History October 2026 A.3. Refusals, duties, export, witness A refusal is REQUEST_REFUSED with refusalSource CORE, BUDGET or CONNECTOR, the request, evaluationTime, expectedHistoryHead, decision, code, optional budgetId or connector: {connectorId, refusalCode, detailDigest}, the session binding and refusalAuthorization. Replay re-runs CORE and BUDGET refusals and rejects the event with REFUSAL_NOT_REPRODUCED on any difference; a CONNECTOR refusal carries CONNECTOR_REFUSED. A handover is the operation succeed: AGENT_TERMINATED then ROLE_TRANSFERRED, sealed by a STATE_CHECKPOINT, with a report listing open duties, live grants each marked as not following, sessions, tenures and the SURVIVES answer. The export view irontrellis-export/2 carries the domain, genesis hash, heads, roots and counts at both ends of a range, every event with its hashes, checkpoints, optional full record sets, requested inclusion paths, every rotation at or before the end, held attestations and the complete earlier-body dependency closure. Type 42 RECONCILIATION_OBSERVED carries the observation fields of Section 10.2 under the challenge irontrellis-reconciliation- authorization/2; its error order is schema, session and fence, reconciler binding, preceding head, match, duplicate or equivocation, uniqueness, capacity. The witness protocol irontrellis-witness/1 keeps per history a chain of statements {version, historyId, domain, head, previous | null}, accepted only if signed by a key in force at the head and previous is the witness's latest. Entries (REGISTERED, HEAD, ROTATED, EQUIVOCATION, SUPERSEDED) are leaves of an [RFC6962] tree with [RFC9162] proofs; checkpoints are signed notes; every latest-head answer is signed over a client nonce. The anchor statement for the public-chain tier, irontrellis-anchor-statement/1, has a frozen field list and canonical rule; its first vector (1,076 bytes, chain eip155:42793) has been reproduced independently. Appendix B. Implementation status This appendix is informative, in the spirit of [RFC7942], and reports documentary evidence as of 29 October 2026. It is not a certification of conformance. The IronTrellis implementation was released as open source on 29 October 2026, as the release candidate 1.0.0-rc.2 [IRONTRELLIS-REPO]. The release tag is signed with a hardware-held key, and the eleven npm packages built from it were published by the repository's release workflow with provenance statements linking each package to that build; the downloads, checksums and documents are listed with the release [IRONTRELLIS-RELEASE]. It connects to coding agents through hooks Rampertab Expires 2 May 2027 [Page 71] Internet-Draft Agent Authority History October 2026 for Claude Code, OpenAI Codex CLI and Cursor, and to agent frameworks through shims for the OpenAI Agents SDK and LangGraph; the repository's quick start is the easiest way to try the model. The implementation pairs this model with two operational documents. A commissioning disclosure [IRONTRELLIS-DISCLOSURE], which every party commissioning an installation reads and signs, states each critical failure mode (time base, anchoring, witnesses, key custody, host compromise, unhooked paths, the limits of replay, federation, privacy and outages) in three parts: what can go wrong, what the implementation does about it, and what the installation itself must do. Where a duty could fall between the two, it is named on both sides, and protections the current release does not yet provide are marked as such. An install checklist [IRONTRELLIS-CHECKLIST] turns these duties into steps for a single experimenter and for an organisation, with an optional external review before commissioning. Both are informative; this document does not require them. +==============+=========+=============+===============+============+ |Part of the |Specified|Built |Independently |Machine- | |model | | |checked |checked (see| | | | | |the next | | | | | |appendix) | +==============+=========+=============+===============+============+ |Authority |Yes |Yes, |Yes: an |Decision | |history, | |TypeScript |engine-free |procedure, | |decisions, | | |Python checker |including | |refusals, | | |written from |revocation | |replay | | |the text alone |monotonicity| | | | |agrees with |at the stage| | | | |the engine on |before the | | | | |446 of 460 |final | | | | |checks of the |checks; | | | | |regenerated |admission | | | | |suite (253 |accounting | | | | |vectors) and | | | | | |on all 446 | | | | | |checks of | | | | | |three further | | | | | |suites, | | | | | |including the | | | | | |86 frozen | | | | | |vectors; the | | | | | |other 14 | | | | | |checks | | | | | |exercise a | | | | | |later rule | | | | | |(the session | | Rampertab Expires 2 May 2027 [Page 72] Internet-Draft Agent Authority History October 2026 | | | |time horizon) | | | | | |that the | | | | | |checker | | | | | |predates. It | | | | | |checks | | | | | |admission | | | | | |proofs for | | | | | |consistency | | | | | |and does not | | | | | |re-derive the | | | | | |decision | | | | | |procedure | | | | | |itself | | +--------------+---------+-------------+---------------+------------+ |Owner approval|Yes |Yes |Yes: 89 owner- |Yes, two | |policies, | | |policy and 68 |independent | |attested | | |human- |models | |floor, | | |attestation | | |recovery, | | |vectors, 157 | | |restoration | | |of 157 | | +--------------+---------+-------------+---------------+------------+ |Duties, |Yes |Yes |Partly (within |Export | |handover, | | |the suites |record | |investigation,| | |above) |machine; | |continuation | | | |observation | | | | | |uniqueness | +--------------+---------+-------------+---------------+------------+ |Reconciliation|Yes |Yes |28 engine- |Uniqueness | |observations | | |derived |only | | | | |vectors; | | | | | |independent | | | | | |batch pending | | +--------------+---------+-------------+---------------+------------+ |Witness |Yes |Yes |Within the |Anchor- | |protocol | | |suites above |verifier | | | | | |continuity | | | | | |(model) | +--------------+---------+-------------+---------------+------------+ |Public-chain |Yes |Outbox, |Statement |Anchor- | |anchoring | |barrier, |vector |verifier | |(tier 1), | |finality |reproduced; |continuity | |outbox, | |verifier and |contract: 174 | | |barrier | |raw-byte |author and 428 | | | | |statement |independent | | | | |contract |checks | | | | |built and | | | | | |locally | | | | | |tested; live | | | Rampertab Expires 2 May 2027 [Page 73] Internet-Draft Agent Authority History October 2026 | | |publication | | | | | |deferred (see| | | | | |below) | | | +--------------+---------+-------------+---------------+------------+ |Persistence |Yes |Design and |No |Tier | |and on-chain | |partial | |separation | |execution | |prototype; a | |within | |(tiers 2 and | |predecessor | |anchor- | |3) | |project | |verifier | | | |deployed its | |continuity | | | |engine as a | |(model) | | | |contract on a| | | | | |test network | | | +--------------+---------+-------------+---------------+------------+ |Federated |Yes |No |No |Committee is| |operation | | | |not an | | | | | |owner; | | | | | |committee | | | | | |time rule | +--------------+---------+-------------+---------------+------------+ |Zero-knowledge|Yes |Experiment; |Yes for those |No | |profiles | |seven |seven: two | | | | |demonstration|separately | | | | |proofs on |built | | | | |synthetic |verifiers | | | | |histories are|accepted them | | | | |published |and refused | | | | |with the |tampered | | | | |release, see |copies; | | | | |below |whether the | | | | | |proved program | | | | | |implements | | | | | |this model is | | | | | |under review | | +--------------+---------+-------------+---------------+------------+ |PHL enrollment|Proposed |No |No |No | |and lineage | | | | | |queries | | | | | +--------------+---------+-------------+---------------+------------+ Table 22: Implementation status On 29 October 2026 the reference writer's test suite passed on a Linux host for the release commit: 1,810 tests, 1,797 passing, none failing, and 13 skipped because they need a secrets service, administrator rights or an earlier release build that the host did not provide. On the repository's hosted Linux runners the same suite passed under Node.js 22 and 24, and the published irontrellis package Rampertab Expires 2 May 2027 [Page 74] Internet-Draft Agent Authority History October 2026 ran its demo on a clean host. The hosted macOS and Windows jobs did not pass for this release; Windows is not yet a supported platform. Running the suite on faster hosted runners before the release found a race in the coding-agent hook: two copies of the hook deciding the same call could refer it to the user instead of refusing it, because one read the clock before the other's refusal was recorded; the hook never allowed such a call on its own. It was fixed before the release tag, with regression tests. One engine defect, in the encoding of a succession record, was found by a separate conformance exercise; it has been fixed, with regression tests. The TypeScript verifier shares code with the writer and is not independent of it; the Python checker is advisory and is not a writer. In the one checker comparison that found disagreements, all seven were the checker lagging rulings already in force. No external cryptographic audit is claimed. *Public-chain anchoring.* The release candidate does not itself verify chain anchors: its anchor check produces no report and lists chain inclusion and finality as missing evidence. Separate tools in its repository record histories on Etherlink Shadownet (chain 127823) under a test profile, and on 25 October 2026 they recorded a first worked history on Etherlink mainnet (chain 42793); those tools report finality in TRUSTED_NODE mode, from nodes the operator chose (Table 17). Anchoring in CONSENSUS_VERIFIED mode, which needs an independently administered, validating Tezos node to confirm finality, is defined and partly vectored, and is not part of this release candidate; when it comes, it adds to these records rather than correcting them. *Zero-knowledge proofs.* Seven zero-knowledge proofs are published with the release as a demonstration [IRONTRELLIS-RELEASE], one for each of the seven synthetic workloads (revocation, three-period, count, cumulative, exhaustion, handover of both, handover of state). They were produced on 29 October 2026 with a pinned build of the implementation's segmented proof program, made on Linux, on synthetic histories; rebuilding that program byte for byte from published source is future work (below). The download holds the root proofs, the root verification key, the proof program with its configuration, and a small verifier that can be built from the public OpenVM source. Before publication, two verifiers built and run separately, one written independently against the published OpenVM library, accepted all seven and refused tampered copies, and the program's commitments and verification key were regenerated from the published program and configuration and matched. Each proof shows only that the program's checks passed for one small synthetic history, within the rules the program supports; the proofs are not production-qualified, whether the program implements this model faithfully is under review, and they establish neither authority, completeness nor freshness. A Rampertab Expires 2 May 2027 [Page 75] Internet-Draft Agent Authority History October 2026 research experiment produced and verified Groth16/BN254 proofs of hidden principal-record membership under an actual format-2 state root (arkworks 0.5.0, single-party setup, eight-event fixture), with signatures and replay outside the circuit. In October 2026 an earlier edition of the implementation's segmented proof program was also proved on seven synthetic workloads; that program followed an earlier edition of the rules and could not be rebuilt byte for byte on Linux, so those proofs are not published. A larger proof run is in progress and has not yet completed. Appendix C. Formal verification: what was chosen, what it proves, what it does not This appendix is informative. IronTrellis does not model every path through the implementation; it chose the paths where a mistake would hurt most and wrote each as a model in Lean 4, stating properties the model must satisfy and letting the kernel check them. Table 23 lists each path, and [IRONTRELLIS-LEAN] explains the choices for a general reader. A selection of these proofs is published with the release [IRONTRELLIS-LEAN-PROOFS]: a self-contained Lean project of 32 source files and 15 headline theorems covering the decision procedure, revocation, owner keys and attestation, spending accounting, committees and anchoring, with each theorem's exact premises and the commands that rebuild them and print the axioms each one relies on. Every result listed passed under one gate: Lean 4.34.1 with core and Std only, no sorry, admit, native_decide or custom axioms, with #print axioms recorded for every theorem. The integrated edition of 17 October 2026 (186 modules, 2,048 theorems) was rebuilt from source on separate hardware with an independently installed Lean, and every theorem in it depends only on Lean's three standard axioms. A rebuild checks the proofs, not whether each model states the rules faithfully; that is reviewed separately. The models are being brought up to the current edition of the rules: the 17 October edition predates the optional session-time horizon (Section 4.3), so its results hold for histories that set none. +==============+================+==================+================+ | Path chosen | Why it was | What is proved | Limits | | | chosen | | | +==============+================+==================+================+ | The | Every ALLOW | A model of path | A model of the | | authority | rests on it; | selection, | rules, not the | | decision | delegation | attenuation, | code; | | procedure | paths, | intersections, | agreement on | | (Section | intersections, | prohibitions | cases is | | 6.1) | prohibitions | and caps; the | evidence, not | | | and caps | model and the | proof. | | | interact | engine agree on | Monotonicity | Rampertab Expires 2 May 2027 [Page 76] Internet-Draft Agent Authority History October 2026 | | | 120,000 | of the final | | | | generated | verdict is not | | | | cases. | claimed: the | | | | Revocation is | proof-size | | | | monotone at the | preflight can | | | | authority- | still differ | | | | verdict stage: | (Section 14.4) | | | | revoking a | | | | | permission | | | | | never turns a | | | | | request that | | | | | was not allowed | | | | | into one that | | | | | is allowed, | | | | | before the | | | | | proof-size | | | | | preflight. | | | | | This is proved | | | | | for the | | | | | executable | | | | | procedure model | | | | | under a valid | | | | | record set, | | | | | when no | | | | | unrevoked | | | | | prohibition has | | | | | the revoked | | | | | permission in | | | | | its ancestry | | | | | (the revocation | | | | | entries of | | | | | Table 9), and | | | | | rebuilt | | | | | independently; | | | | | terminating an | | | | | agent is proved | | | | | likewise | | +--------------+----------------+------------------+----------------+ | Owner | The owner's | Two | Several | | approval and | keys are the | independently | results are | | the attested | trust anchor; | written models | assumption- | | floor | the rules for | prove: a one- | relative; one | | (Section | lapse, | signature | of the two | | 4.5, | restoration | floor, pre- | models still | | Section 4.6) | and recovery | event | states the | | | are easy to | authority, | termination | | | get subtly | commitment | rule in its | | | wrong | conservation, | earlier, | Rampertab Expires 2 May 2027 [Page 77] Internet-Draft Agent Authority History October 2026 | | | lapsed keys | grantor-only | | | | limited to | form, which | | | | power | the procedure | | | | reduction, | model proves | | | | checkpoints and | in its current | | | | restoration, | form; two | | | | separation of | liveness | | | | owner, | claims in the | | | | committed, | companion | | | | attester, | property list | | | | session and | were found | | | | counterparty | false and | | | | credentials, | withdrawn | | | | the single- | | | | | signer time | | | | | bound, and non- | | | | | expansion of | | | | | power-reducing | | | | | records | | | | | relative to | | | | | five stated | | | | | assumptions | | | | | about the | | | | | decision | | | | | procedure, the | | | | | first of which | | | | | (revocation | | | | | monotonicity) | | | | | is itself | | | | | proved for the | | | | | procedure model | | | | | (previous row) | | +--------------+----------------+------------------+----------------+ | Admission | Shared | Under immutable | Budgets have | | accounting | ancestors on a | caps and one | only a | | (Section | path could be | serialized | conditional | | 6.2) | charged twice | order, every | bound | | | or not at all | controlling | | | | | authority is | | | | | charged once | | | | | per accepted | | | | | admission and | | | | | recorded usage | | | | | never exceeds | | | | | its cap; | | | | | rejection | | | | | atomicity, | | | | | admission-time | | Rampertab Expires 2 May 2027 [Page 78] Internet-Draft Agent Authority History October 2026 | | | epoch fencing | | | | | and the | | | | | capacity census | | | | | are proved | | | | | alongside | | +--------------+----------------+------------------+----------------+ | A committee | Federation | A committee co- | Rotation out | | is not an | must never | signing key is | assumes the | | owner | turn a | never | human-class | | (Section | committee into | sufficient | holders still | | 11.5) | the principal | alone, never | exist and can | | | | counts on a | sign, and that | | | | rotation or | an attester | | | | policy change, | named in the | | | | can never block | policy issues | | | | a power | their renewal | | | | reduction, can | statements | | | | always be | | | | | rotated out by | | | | | the human-class | | | | | holders, and is | | | | | never human | | | | | under the | | | | | attested floor | | | | | without a | | | | | statement | | +--------------+----------------+------------------+----------------+ | Checkpoint | A | The | A wording | | availability | counterexample | counterexample | result, not a | | under | was found | is accepted: a | replay change | | committee | | policy | | | loss | | requiring the | | | | | committee for | | | | | checkpoints | | | | | blocks them | | | | | until a | | | | | rotation; the | | | | | rule's wording | | | | | was corrected | | +--------------+----------------+------------------+----------------+ | Anchor- | A public | Accepted heads | Chain finality | | verifier | anchor is only | always form a | and | | continuity | as good as the | prefix chain, | availability | | (Section | rule that | so the modelled | are outside | | 11.4) | accepts it | verifier never | the model | | | | accepts a | | | | | rollback or | | | | | fork; a | | Rampertab Expires 2 May 2027 [Page 79] Internet-Draft Agent Authority History October 2026 | | | strictly | | | | | increasing | | | | | sequence number | | | | | with valid | | | | | linkage is not | | | | | sufficient | | | | | without the | | | | | prefix check | | | | | (counterexample | | | | | given); two | | | | | statements for | | | | | one predecessor | | | | | are always | | | | | detected; a | | | | | wrapper | | | | | requiring both | | | | | a certificate | | | | | and replay | | | | | acceptance | | | | | never admits | | | | | what replay | | | | | refuses nor | | | | | refuses what | | | | | replay admits | | | | | on certificate | | | | | grounds | | +--------------+----------------+------------------+----------------+ | Committee | Time is the | The vote rule | The hypothesis | | time and the | writers' | composes with | is stated, not | | attested | claim; the | the attested- | discharged | | floor | vote rule and | floor bound; a | | | | the time bound | history | | | | must compose | violating the | | | | | vote rule | | | | | replays | | | | | identically, so | | | | | the rule is | | | | | evidence, not | | | | | replay; | | | | | committed | | | | | timestamps are | | | | | bounded under | | | | | an honest- | | | | | quorum | | | | | hypothesis | | +--------------+----------------+------------------+----------------+ | Renewal, | The largest | Several hundred | Restoration | | restoration | remaining | typed-model | and removal | Rampertab Expires 2 May 2027 [Page 80] Internet-Draft Agent Authority History October 2026 | and removal | surface of the | statements | results assume | | under the | owner rules | across the | that an | | attested | | renewal, | attester named | | floor | | restoration, | in the policy | | (ongoing) | | selective | issues the | | | | removal and | renewal | | | | reachable- | statements; no | | | | successor | native- | | | | cases, kernel- | signature or | | | | checked, and | replay- | | | | rebuilt | correspondence | | | | independently | result | | | | as part of the | | | | | 17 October | | | | | edition | | +--------------+----------------+------------------+----------------+ Table 23: Proof paths chosen, and their limits *What the proofs caught.* A signed twelve-event history in which revoking a grant turned a clear DENY into an ALLOW, because the engine checked a cumulative cap after choosing a path; the rule was moved. A single-signature termination of an agent in the middle of a delegation chain that would have silently switched off a prohibition depending on it; the rule was tightened. A null-expiry session from a migrated prefix that could still attest a duty finding; the rule now expires it. Two liveness promises of the "you can always do X" kind that were false in edge cases, such as a policy where one key is enough. *What they do not show.* The proofs are about models of the rules, not the TypeScript that runs; the two are connected by testing on large case sets, which is strong evidence, not proof. Cryptography is assumed: signatures cannot be forged and hashes do not collide. A proof shows exactly the statement written down. Some results hold only under named assumptions, and each is listed. Nothing shows that a person meant to approve something or that a report from the world is true. The largest open piece is a proof that replaying any history always rebuilds exactly the same state. *Where this is going.* Each rule change is followed by re-checking the proofs it touches. The selection published with the release rebuilds with two commands, so that a reader can rerun it rather than take this appendix's word; the full editions, a claims ledger naming every theorem with its assumptions and exclusions, the counterexamples that changed rules, and the scripts that compare the models with the engine are to follow in the same way. The zero- knowledge demonstration of Appendix B is to be completed the same Rampertab Expires 2 May 2027 [Page 81] Internet-Draft Agent Authority History October 2026 way: the source of the proof program with a pinned recipe for rebuilding it, the EVM verifier contract and its proof, and the questions and results for each synthetic history. Appendix D. Relation to other work *Signed Permissions and Action Receipts* ([I-D.izmaylov-agent-permission-receipts], revision -01) specifies passkey permissions, attenuating delegation, signed action receipts, acknowledged cancellation and signed tree heads, and maps its records onto the AUDIT architecture's record types; its verifier separates malformed evidence from sound records reporting actions outside permission, whereas this model rejects admissions that do not reproduce ALLOW. Replayed actor, session and epoch state, role tenures and surviving duties are not specified there. Neither design proves complete execution history from agent-generated records alone. *AUDIT* ([I-D.kuehlewind-audit-architecture], revision -01) organizes cross-domain record generation, audit context and auditing services, including delegation and authorization transition records, and keeps real-time enforcement outside its post-hoc scope. This document supplies a proposed state-transition component; duties and reconciliation are proposals for discussion, not adopted work items. *OAuth and WIMSE.* Token exchange [RFC8693] and transaction tokens [I-D.ietf-oauth-transaction-tokens] carry delegation inside tokens for a request; the WIMSE architecture [I-D.ietf-wimse-arch] gives workloads identifiers and short-lived credentials. A session admission can bind a WIMSE credential's key, a grant can be the authority behind a token issuance, and a token's claims can reference the grant identifier; the record of authority is the history, the token a derived credential whose issuance and revocation can themselves be recorded. *RATS* [RFC9334] can establish properties of the environment that produced a record; this model carries evidence references for that purpose and does not define attestation. *Human delegation provenance* ([I-D.helixar-hdp-agentic-delegation]) describes session-bound human authorization and a signed delegation chain with optional proof-of-humanity credentials. Overlapping concerns do not imply wire interoperability or identical assurance. Rampertab Expires 2 May 2027 [Page 82] Internet-Draft Agent Authority History October 2026 Appendix E. SCITT mapping This mapping is informative. Registering IronTrellis signatures does not automatically create SCITT Signed Statements or Receipts. A future profile could wrap an owner head attestation, export digest, control record or session claim in a newly signed COSE_Sign1 statement [RFC9052], defining payload canonicalization, issuer identity and key discovery; reusing a raw signature as a COSE signature is invalid because the signing inputs differ. SCITT requires protected iss and sub claims on statements and Receipts [RFC9943] [RFC9942]; a profile could scope the subject to a history identity. The witness evidence of Section 11.3 is analogous but has no compliant COSE mapping. Registration does not establish statement truth or issuer completeness, and submitted-head chaining cannot detect an unsubmitted suffix. Appendix F. Worked model example This informative sequence is illustrative, not a conformance fixture. 1. An authenticated owner creates two agents and an exclusive purchasing role, admits their sessions, and declares a succession rule. Only the current agent receives a bounded purchasing grant. 2. A purchase is admitted under the current head. A separately signed counterparty report is recorded. An uncertain submission preserves its original identity and allowance; the replacement may observe its result but does not dispatch it again. 3. A request exceeding a grant or budget produces a reproduced refusal. A supplied provider event is separately recorded as MATCHED or UNMATCHED; matching the refusal does not authorize the reported call. 4. An investigation duty remains attached to the role. Handover terminates the predecessor, transfers the tenure and reports surviving work and non-transferring grants. The successor needs fresh authority for performance assignment, resource restoration and disposition. 5. A prospective policy permits a purpose-bound finding and authorized disposition. A contest remains visible. Segmented continuation preserves the same genesis, usage, pending identity and duties. Rampertab Expires 2 May 2027 [Page 83] Internet-Draft Agent Authority History October 2026 6. An auditor authenticates the intended history and export boundaries, replays the range with its dependencies, and reports authority, claims, inclusion, freshness and outcome assurance separately. An optional hidden-record proof establishes only its pinned predicate. Acknowledgments The model draws on the IronTrellis design and its predecessor and the cited AUDIT proposals. The author thanks the AUDIT BoF proponents for the problem statement and the author of [I-D.izmaylov-agent-permission-receipts] for a clear prior design against which to state the differences. Author's Address Ramesh Rampertab RAmEx Labs United States of America Email: ramesh.rampertab@ramex.com Rampertab Expires 2 May 2027 [Page 84]