Replayable Authority Histories for Auditing Automated Agents
draft-rampertab-audit-agent-authority-history-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Ramesh Rampertab | ||
| Last updated | 2026-10-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
IronTrellis 1.0.0-rc.2, open-source implementation
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rampertab-audit-agent-authority-history-00
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
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, <https://datatracker.ietf.org/doc/
bofreq-kuhlewind-audit-agent-use-of-delegation-and-
interaction-traceability/>.
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,
<https://www.cis.upenn.edu/~aaroth/Papers/
privacybook.pdf>.
[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, <https://eprint.iacr.org/2009/616>.
[GROTH16] Groth, J., "On the Size of Pairing-based Non-interactive
Arguments", Cryptology ePrint Archive 2016/260, 31 May
2016, <https://eprint.iacr.org/2016/260>.
[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, <https://datatracker.ietf.org/doc/html/draft-
birkholz-verifiable-agent-conversations-01>.
[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,
<https://www.ietf.org/archive/id/draft-helixar-hdp-
agentic-delegation-03.html>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-11>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
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, <https://www.ietf.org/archive/id/draft-irtf-
cfrg-bbs-signatures-14.html>.
[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, <https://www.ietf.org/archive/id/draft-izmaylov-
agent-permission-receipts-01.txt>.
[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,
<https://www.ietf.org/archive/id/draft-kuehlewind-audit-
architecture-01.txt>.
[IRONTRELLIS-CHECKLIST]
RAmEx Labs, "IronTrellis Install Checklist", Informative
operational guidance only, October 2026,
<https://github.com/zerohourzulu/irontrellis/blob/v1.0.0-
rc.2/docs/INSTALL-CHECKLIST.md>.
[IRONTRELLIS-DISCLOSURE]
RAmEx Labs, "IronTrellis Commissioning Disclosure",
Informative operational guidance only, October 2026,
<https://github.com/zerohourzulu/irontrellis/blob/v1.0.0-
rc.2/docs/COMMISSIONING-DISCLOSURE.md>.
[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,
<https://github.com/zerohourzulu/irontrellis/blob/v1.0.0-
rc.2/docs/FORMAL-VERIFICATION.md>.
[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,
<https://github.com/zerohourzulu/irontrellis/tree/v1.0.0-
rc.2/verification/SelectLeanProofs>.
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,
<https://github.com/zerohourzulu/irontrellis/blob/v1.0.0-
rc.2/docs/WHY-IRONTRELLIS.md>.
[IRONTRELLIS-RELEASE]
RAmEx Labs, "IronTrellis 1.0.0-rc.2 release downloads",
Packages, checksums, documents and the zero-knowledge
demonstration download, October 2026,
<https://github.com/zerohourzulu/irontrellis/releases/tag/
v1.0.0-rc.2>.
[IRONTRELLIS-REPO]
RAmEx Labs, "IronTrellis 1.0.0-rc.2", Open-source
implementation, release candidate, October 2026,
<https://github.com/zerohourzulu/irontrellis/tree/
v1.0.0-rc.2>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
[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,
<https://www.rfc-editor.org/rfc/rfc6973>.
[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,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[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,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
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, <https://www.rfc-editor.org/rfc/rfc9162>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[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,
<https://www.rfc-editor.org/rfc/rfc9591>.
[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,
<https://www.rfc-editor.org/rfc/rfc9942>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
[SEAL-SECURITY]
Microsoft, "Microsoft SEAL: Correct Use and Security
Guidance", Mutable project security guidance; inspected 11
October 2026., n.d.,
<https://github.com/microsoft/SEAL/blob/main/SECURITY.md>.
[VC-DM2] "Verifiable Credentials Data Model v2.0", 15 May 2025,
<https://www.w3.org/TR/2025/REC-vc-data-model-
2.0-20250515/>.
[WEBAUTHN3]
"Web Authentication: An API for accessing Public Key
Credentials, Level 3", 25 August 2026,
<https://www.w3.org/TR/2026/REC-webauthn-3-20260825/>.
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": <genesis 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]