Replayable Authority Histories for Auditing Automated Agents

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.¶

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    |
                            +-----------------------------+

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).¶

• 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.¶

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.¶

1.4. What a verifier can and cannot conclude

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.¶

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?¶

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.¶

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.¶

3.1. Parties and trust

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)

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.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).¶

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.¶

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 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

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 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 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.¶

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 [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.¶

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.¶

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.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)

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;¶

• 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 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.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.¶

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.¶

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.¶

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).¶

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 claim refused; a profile MUST NOT advertise cross-service atomicity merely because both decisions allowed at admission.¶

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.¶

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.¶

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 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 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.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.¶

  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

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 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.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.¶

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 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.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.¶

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.¶

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 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)

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.¶

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.¶

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.¶

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.¶

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.¶

14.3. Key compromise

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.¶

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).¶

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/>.

[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>.

[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>.

[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>.

[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/>.

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

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.¶

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.¶