Identity-Bound Governance Under Execution Uncertainty: An Accountability Proof Block for LLM Agent Persistent Halts, with Cryptographic Implementation and Cross-Model Calibration
Analyze & explore related research in Conceptio
Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.
Identity-Bound Governance Under Execution Uncertainty An Accountability Proof Block for LLM Agent Persistent Halts, with Cryptographic Implementation and Cross-Model Calibration
arXiv:2610.00787v1 [cs.CR] 30 Sep 2026
Agent Governance Series — Paper 8
Marcelo Fernandez TraslaIA info@traslaia.com DOI: 10.5281/zenodo.20157139
September 2026
Paper
Short title
Zenodo DOI
arXiv
P0 P1 P2 P3/4 P5 P6 P7 P8
Atomic Decision Boundaries [6] Agent Control Protocol (ACP) [7] From Admission to Invariants (IML) [10] Irreducible Governance Structure [9] Reconstructive Authority Model (RAM) [12] Operationalizing Reconstructive Authority [11] Closing the Execution Gap [8] Identity-Bound Governance (APB)
10.5281/zenodo.19670649 10.5281/zenodo.19672575 10.5281/zenodo.19672589 10.5281/zenodo.19708496 10.5281/zenodo.19669430 10.5281/zenodo.19699460 10.5281/zenodo.19929771 10.5281/zenodo.20157139
arXiv:2604.17511 arXiv:2603.18829 arXiv:2604.17517 TBD arXiv:2604.22898 arXiv:2605.23935 TBD TBD
Abstract A correctly governed LLM agent can reach a state in which neither continuing execution nor automatically halting is admissible: the system has detected a persistent failure of its observability or drift-detection layer, but cannot itself decide who has the authority to resume, deny, or recalibrate the deployment. We call this an identity-bound governance event, and we formalise the mechanism that resolves it. We introduce the Accountability Proof Block (APB), a two-part record consisting of a systemconstructed evidence block Es , a human-supplied decision block Dh , and a cryptographic signature σh binding the two to a registered principal Hi ∈ P. The system can construct Es but cannot forge σh (it lacks the principal’s secret key); the principal can issue Dh but cannot alter Es undetected (the signature covers both). We prove four theorems about this construction: Protocol-Bounded Governance Completeness (every halt resolves through either the recovery loop or a signed APB, within the execution model induced by DC.1/DC.2), Non-Repudiability (no principal can deny a governance act for which a valid APB exists), Impossibility of Anonymous Re-Authorization (the execution layer cannot generate a valid APB without the principal’s private credential), and Finite-Time APB Construction Termination. The implementation uses the RFC 8785 JSON Canonicalization Scheme (JCS) for cross-implementation-safe signatures and extends replay defence with a UUID4-based semantic-uniqueness predicate (V5).
1
We provide a real-cryptography implementation in cryptography/ed25519, expose the result through an Authority Resolution Function G, and validate the construction empirically. With a MockLLM stack across 10 seeds and 10,000 steps, governance completeness holds identically under two threshold policies (3,812 halt events, zero unresolved cases). Across 9 adversarial vectors against 200 freshly-signed APBs, the verifier achieves 100.0000% detection. A multiprincipal threshold experiment across 7,000 events confirms Byzantine principal resistance: 0 false acceptances in 2,000 single-key capture attempts under k = 2. A cross-model study of six open LLMs (mistral, deepseek-r1, gemma, gpt-oss, qwen, llama3) finds that the modelspecific drift threshold T ∗ is stable within model (σ/T ∗ < 2% for all measurable cases) but varies across models by a factor of 1.7×, refuting any size-monotone hypothesis: the largest model in our sample is the one that does not drift within the 500-step window. A temperature sweep across three of those models at T ∈ {0.2, 0.4, 0.6, 0.8} replicates the temperature-insensitivity conjecture for the two fast-drifting models (per-model range ≤ 5 steps) but reveals a drift-floor effect for the slow-drifter (T ∗ range of 51 steps for gemma4). We conclude that T ∗ must be measured per deployment — not predicted from architecture, and not assumed temperatureinvariant for slow-drifting models — and that the APB is the operational vehicle by which that measured threshold yields accountable authority transfer.
1
Introduction
P7 of this series [8] established that persistent halts are not implementation failures but structural consequences of bounded runtime governance: when drift accumulates past the recovery authority of the autonomous stack, execution stops and accountability remains unresolved. P8 answers the question that structural halt leaves open — who has the authority to lift it, under what evidence, and with what non-repudiable record? Concretely: once a halt is persistent in the formal sense (§3), the system cannot issue a unilateral resumption without recalibrating its own authority, which design constraints DC.1 and DC.2 of [8] explicitly forbid. This paper introduces the Accountability Proof Block (APB) as the minimal mechanism for binding that authority to a verifiable human decision. We refer to this as the problem of identity-bound governance under execution uncertainty. The standard accountability mechanisms in deployed AI systems are not a solution to this problem. Documentation artefacts such as model cards [15] and OpenAI’s system cards [16] are static; they describe behaviour at training or deployment time, not at the moment of an unexpected halt. Alignment techniques such as constitutional AI [2] bias the agent’s behaviour but do not provide a non-repudiable record of the human decisions that surround a deployment. Compliance audit trails as mandated by GDPR, SOX, or PCI-DSS are typically post-hoc and not cryptographically bound to specific runtime events. None of these mechanisms provides a per-event, identity-bound, cryptographically verifiable record that the system itself cannot forge. Contributions. This paper introduces the Accountability Proof Block (APB) as the formal object that fills this role, and validates it empirically. Specifically: 1. We define the Principal Set P, the Authority Resolution Function G, and the APB structure APB = (Es , Dh , σh ) formally (§3), and we make the threat model explicit: five attacker classes, with the boundary between what the APB defends against and what it does not made precise. 2. We prove four theorems (§4): Protocol-Bounded Governance Completeness (T8.1), Non2
Repudiability (T8.2), Impossibility of Anonymous Re-Authorization (T8.3), and Finite-Time APB Construction Termination (T8.4). Each is supported by auxiliary lemmas that decompose the argument. 3. We provide a real-cryptography implementation (§5) using ed25519 signatures over the RFC 8785 JSON Canonicalization Scheme (JCS), with a Principal Registry, a five-predicate verifier (V1–V5, including a semantic-uniqueness check via UUID4 event identifiers), and an append-only log with HMAC chaining for persistence. 4. We validate the construction empirically through five experiments (§6–§10): Governance Completeness over 10 seeds and two threshold policies; APB Integrity under nine adversarial vectors; cross-model T ∗ across six open LLM families; temperature insensitivity across three of those families and four sampling temperatures; and multi-principal threshold governance with Byzantine resistance validation across 7,000 events covering seven attack scenarios. 5. We extract Proposition 5.1 (§5.1) as an operational design recipe: given a measured T ∗ for a model, the persistence window ∆T that the execution layer uses to classify a halt as a governance event admits a calibrated range. We discuss what this means for deployments where T ∗ is not finite (one of our six models did not drift within the experimental window). Independence from prior work. Although this paper sits in the Agent Governance series, its claims do not depend on the empirical results of prior papers. The formal framework, the theorems, and all four experiments are self-contained: fresh evidence is generated under identical software but different runs, and the cryptographic claims are entirely new (no cryptography appears in P0–P7). Where prior work is referenced (notably the design constraints DC.1 and DC.2 of [8]), the references are contextual rather than constitutive. Roadmap. §2 situates the APB against existing accountability mechanisms. §3 introduces the Principal Set, the Authority Resolution Function, and the APB structure. §4 proves the four theorems. §5 describes the implementation and the threat model boundary. §6–§10 report the five validation experiments. §12 discusses limitations and integration paths. §13 concludes.
2
Related Work
We organise prior work along the dimensions that the APB engages simultaneously: runtime, cryptographic, identity-bound, and LLM-agent specific. To our knowledge no existing mechanism combines all four; Table 1 maps the landscape. Documentation-based. Model cards [15], system cards [16], and data sheets are static artefacts authored prior to deployment. They describe what an agent is supposed to do or not do; they do not record what a specific human authorised the agent to resume after a halt at t = te . Alignment-based. Constitutional AI [2] and RLHF approaches shape the agent’s behaviour at training time. They affect how the agent acts but not who authorised a recovery decision. The APB is orthogonal: it does not constrain the agent’s behaviour; it constrains the act of re-authorising the agent. 3
Table 1: Accountability mechanisms relevant to LLM agent governance, characterised by whether they operate at runtime, are cryptographic, bind to a specific human identity, and are designed for the LLMagent setting. The APB is, to our knowledge, the first construction that satisfies all four. Mechanism Model / system cards [15, 16] Constitutional AI [2] Compliance audit trails (GDPR, SOX) Smart-contract logs [18] Threshold signatures [5] APB (this work)
Runtime
Crypto
Identity-bound
LLM-agent specific
— ✓ ✓ ✓ — ✓
— — — ✓ ✓ ✓
— — — ✓ ✓ ✓
✓ ✓ — — — ✓
Audit-trail and compliance. Regulatory audit trails (GDPR Article 30, SOX section 404, PCIDSS) log access events but typically lack cryptographic binding to a specific human credential at the moment of decision. Recent work on verifiable audit logs [14] brings cryptographic guarantees to logs themselves, but does not address per-event authorisation by named principals. Smart contracts and on-chain governance. Smart-contract execution [18] and on-chain DAO governance produce records that are runtime, cryptographic, and identity-bound. They are, however, not designed for LLM-agent runtime state: they bind to wallet addresses (which are not the same as human identities), assume a public ledger, and are not intended to operate at the latency of an in-process governance event. The APB borrows the cryptographic-binding insight while keeping the deployment local. Threshold and multi-signature schemes. Threshold and multi-signature constructions [5, 13] address which principals must concur before an action is authorised. They complement the APB rather than replace it: §3 notes that an APB-typed governance event may require k-of-n signatures, in which case each cosigner contributes their own σh over the same canonical (Es ∥ Dh ) payload. Position. The APB is, to our knowledge, the first construction that is simultaneously runtime, cryptographic, identity-bound, and designed for LLM-agent governance. The closest analogues are smart-contract logs (which lack the LLM-agent fit) and threshold signatures (which are a subcomponent, not a complete governance mechanism).
3 3.1
Formal Framework Setting and Inherited Constraints
We assume an agent system whose execution layer maintains a runtime admission snapshot A0 , b a drift estimator D(t) with threshold θ, and a halt mechanism that may emit HALT when its observability or risk-attribution gates fail. Two design constraints from prior work in the series [8] are inherited verbatim: DC.1 (Separation of Recalibration Authority). For all t, A0 (t) = A0 (0). The execution layer is forbidden from modifying its own admission baseline at runtime. 4
b ) ≥ θ for τ within a bounded DC.2 (Drift Event Classification). A halt is transient if D(τ b window ∆T and returns below θ thereafter; it is persistent if D(t) ≥ θ for all t ∈ [t0 , t0 + ∆T ]. Transient halts route to the recovery loop; persistent halts constitute governance events.
DC.1 implies that, when a persistent halt occurs, the system cannot recalibrate its own A0 to clear the halt. DC.2 routes such halts out of the execution layer’s authority. The role of this paper is to specify what is on the other side of that boundary. 3.2
Principal Set P
Definition 3.1 (Principal Set). The Principal Set of a governed system is a finite set P = {H1 , . . . , Hn } of identity-bound human principals. Each Hi has a public verification key pki and an associated private signing key ski held exclusively by Hi . The mapping Hi 7→ pki is recorded in a registry that the execution layer treats as read-only. DC.1 specialised to P: the registry is fixed at A0 construction time, and any modification to it is itself a governance event of type RECALIBRATE. We thus obtain a self-referential modification discipline — P is mutable only through APBs that authorise its mutation. Revocation. A principal may be revoked. We model revocation by recording a timestamp of revocation; APBs signed before the revocation timestamp remain verifiable (with a flag indicating the principal’s later revoked status), while APBs signed after are rejected at verification time. This historical-validity discipline is enforced by the predicate is_active(Hi , te ) used by the verifier (§5). 3.3
Authority Resolution Function G
Definition 3.2 (Authority Resolution Function). G : P × S × E → {RESUME, DENY, RECALIBRATE}, where S denotes the space of system runtime states and E the space of governance evidence packages. G is the governance-layer analog of the runtime authority function F of [8]: it constructs authority from human attestation over a defined evidence set, not from sensor state. The output RECALIBRATE is the only authorised path by which A0 may change after initialisation; RESUME permits a single resumption under stated scope; DENY permanently bars the queried action. The APB is the recorded artefact that witnesses an evaluation of G. 3.4
Accountability Proof Block (APB)
Definition 3.3 (APB). An Accountability Proof Block signed by principal Hi is a triple APB = (Es , Dh , σh ) where b e ), te , eid, hash(trace≤t ), cause) Es = (hash(A0 ), D(t e
Dh = (Hi , decision, rationale, scope) σh = Signski canon(Es ) ∥ canon(Dh )
(System Evidence Block)
(Human Decision Block) (Signature) 5
eid is a UUID version 4 generated once at evidence-construction time; it provides semantic uniqueness across governance events independently of te (enabling V5, §5). canon(·) denotes the RFC 8785 JSON Canonicalization Scheme (JCS) [17]: keys sorted by Unicode codepoint, IEEE 754 number representation, no insignificant whitespace, UTF-8 encoding. This cross-implementation-safe encoding is the deterministic input to the signature, removing any ambiguity that could otherwise weaken the non-repudiability and tamper-detection guarantees. Sign is the ed25519 signature operation. The construction has three structural properties enforced by its typing alone: b and 1. Only the execution layer can correctly produce Es : it is the only party that holds A0 , D, the trace.
2. Only Hi can produce σh : it is the only party that holds ski . 3. σh covers both Es and Dh : any modification to either invalidates the signature. 3.5
Threat Model
The APB is designed to defeat a specific class of attackers; we make the boundary of its protection explicit. Five actor classes are considered. A1. External attacker. No system access. Goal: forge an APB attributed to Hi . Defence: T8.3 (§4). A2. Compromised system process. Has runtime access to the execution layer but does not hold ski for any Hi ∈ P. Goal: synthesise a σh that verifies against some registered pki . Defence: T8.3. A3. Replay attacker. Holds a previously-valid APB and tries to use it in a new context. Defence: two complementary predicates in the verifier (§5): V4 (temporal freshness, rejects APBs outside the acceptable age window) and V5 (semantic uniqueness, rejects any APB whose eid was already accepted, even within the V4 window). A4. Man-in-the-middle. Intercepts an APB in transit and tries to modify either Es or Dh before delivery. Defence: σh covers both blocks, so any tampering invalidates verification. A5. Compromised principal. Has obtained ski for some Hi . Out of scope. The APB cryptographically binds decisions to keys; if a key is compromised, the binding attaches to the compromised key. Mitigation lies outside the APB protocol (multi-signature, key rotation, out-of-band review). 3.5.1
What APB Does Not Prevent
The APB is an accountability mechanism, not an access-control mechanism. A principal Hi holding a valid ski can sign any Dh they wish, including a malicious one, and the resulting APB will verify cryptographically. What the APB ensures, against this case, is that: 1. the malicious decision is attributable to Hi and cannot be denied (T8.2); 2. the system itself did not synthesise the decision behind Hi ’s back (T8.3). 6
Mitigations for adversarial principals (multi-signature, separation of duties, out-of-band review) are configurable on top of the APB but are not part of the APB protocol itself. We return to this distinction in the discussion (§12). 3.6
Multi-Principal APB Extension
The base APB carries a single signature σh from one principal. For deployments that require stronger governance guarantees, we extend the construction to support threshold signing: a MultiPrincipal APB requires k valid, distinct-principal signatures out of n registered principals (k-of-n). Definition 3.4 (Multi-Principal APB). A Multi-Principal Accountability Proof Block with threshold k is a quadruple APB(k) = (Es , Dh , Σ, k) where Es and Dh are as in Definition 3.3, and Σ = {(H 1 , σ 1 ), . . . , (H m , σ m )} is an ordered set of signature entries (H j ∈ P, σ j ∈ {0, 1}512 ), each satisfying σ j = Signskj (canon(Es ) ∥ canon(Dh )). The APB is valid under threshold k iff at least k entries in Σ pass predicates V1–V3 and V5 over distinct principals H j ∈ P. Three structural properties hold by construction: 1. Each signer attests independently to the same (Es , Dh ) pair; no coordination between signers’ devices is required. 2. Duplicate signer entries (same Hi appearing twice) are rejected: each distinct principal counts at most once toward the threshold. 3. The signed message is identical to the single-principal APB, so the non-repudiability and anonymous-re-authorization impossibility guarantees (T8.2, T8.3) apply to each entry in Σ individually. The k-of-n structure is the formal basis for Byzantine principal resistance (Proposition 4.12 below): governance capture under APB(k) requires the adversary to hold k distinct signing keys simultaneously.
4
Theorems
We prove four theorems about the APB. The first three are properties promised in the framework section of [8]; we restate them precisely and give full proofs. The fourth (T8.4) is new: it establishes that the construction of Es terminates in bounded time, which is required for T8.1 to be nonvacuous. 4.1
T8.1 — Protocol-Bounded Governance Completeness
Theorem 4.1 (Protocol-Bounded Governance Completeness). Let h be a HALT event emitted by an execution layer satisfying DC.1 and DC.2. Then, within the execution model induced by DC.1, DC.2, and the APB verifier predicates, exactly one of the following resolutions holds:
7
(R1) h is transient under DC.2 and the recovery loop produces a RESUME within its bounded attempt budget; (R2) h is persistent under DC.2 and a valid signed APB is produced through an evaluation of G. No third resolution path exists within the protocol boundary. Proof. By DC.2, h is exactly one of transient or persistent. Case (transient): the recovery loop is defined for transient halts ([8], P6 Recovery Loop) and terminates in at most k attempts with a RESUME, HALT, or DENY outcome on the augmented state. If the outcome is RESUME, we are in case (R1). If the outcome on the augmented state is HALT or DENY, the halt is reclassified as persistent (the recovery loop has exhausted the ways in which the halt could be transient), reducing to the persistent case below. Case (persistent): by DC.1 the execution layer cannot modify A0 to clear the halt; the only authorised path to a state in which execution may continue is an output of G. By Theorem 4.9 below, Es can be constructed in finite time. By Definition 3.3, given Es and a principal Hi with valid ski , an APB is produced. We are in case (R2). The two cases are exhaustive (DC.2) and disjoint (the recovery loop’s output of RESUME excludes persistence within the same window). Therefore no third resolution exists within the protocol boundary. Scope of the claim. This completeness result is relative to the execution model induced by DC.1, DC.2, and the APB verifier predicates V1–V5. It does not assert completeness under arbitrary infrastructure failures, compromised principal sets, or events external to the protocol boundary (e.g. a fully inoperative registry or unreachable signing device). Those failure modes are addressed by the composability layer discussed in §12. Lemma 4.2 (Resolution Path Exhaustivity). The recovery loop’s exit set {RESUME, HALT, DENY} partitions the post-halt state space into transient (RESUME) and persistent (HALT ∪ DENY). The latter is exactly the domain of G. Note that HALT and DENY are semantically distinct: HALT denotes an unresolved system state (the loop exhausted its authority without a decision), while DENY denotes a resolved human decision to refuse resumption. Both share the property that the execution layer cannot self-resolve them without external authority, which is the criterion relevant here. Proof. The recovery loop’s outputs are mutually exclusive by construction (it returns at most one). Definition of transient (DC.2): the drift estimator returned below threshold within ∆T , observable by the recovery loop’s own measurements. If RESUME, by P6 the loop has confirmed observability is restored, hence transient. If HALT or DENY, the loop has confirmed it cannot resolve, hence persistent. 4.2
T8.2 — Non-Repudiability
Theorem 4.3 (Non-Repudiability). Let APB = (Es , Dh , σh ) be a verifiable APB whose Hi field in Dh identifies a registered, non-revoked principal at te , and let σh verify against pki . Then no efficient adversary can produce a Dh′ ̸= Dh on Es that also verifies under pki , except with negligible probability. Proof. Verification of an APB requires that σh = Signski (canon(Es ) ∥ canon(Dh )). Suppose, for contradiction, that an adversary produces APB′ = (Es , Dh′ , σh ) with Dh′ ̸= Dh that verifies. Because σh is a fixed value and the canonical serialisation is injective on dataclass content (Lemma 4.4), 8
canon(Dh′ ) ̸= canon(Dh ), so the message under the signature differs. A successful verification of σh over the new message contradicts the existential unforgeability of ed25519 under chosen-message attack [3, 4]. This event has negligible probability in the security parameter. Lemma 4.4 (Es Post-Construction Integrity). The canonical encoding canon used in the APB construction is collision-resistant on dataclass content: distinct values of the six Es fields produce distinct byte-strings. Proof. canon is the RFC 8785 JSON Canonicalization Scheme [17]: keys sorted by Unicode codepoint, IEEE 754 representation for numbers, UTF-8 encoding, no insignificant whitespace. The RFC 8785 canonical mapping is injective over the primitive dataclass domain used here: all Es and Dh fields are strings or IEEE 754 floats, and for this domain distinct field values produce distinct byte-level representations (the key-sort order is deterministic and no two distinct primitive values share a canonical encoding under RFC 8785). The eid field is a UUID4 string, which is a primitive and thus covered by the same argument. Lemma 4.5 (Signature Verifiability Under Tamper). Let APB verify against pki with original Es . For any modification of Es to Es′ ̸= Es , retaining σh and Dh , the modified APB does not verify under pki . Proof. By Lemma 4.4, canon(Es′ ) ̸= canon(Es ), hence the message under verification differs from the message that was signed. Verification of an ed25519 signature against a different message succeeds only with negligible probability. 4.3
T8.3 — Impossibility of Anonymous Re-Authorization
Theorem 4.6 (Impossibility of Anonymous Re-Authorization). Let an adversary A have full read and write access to the execution layer’s runtime state but not hold ski for any Hi ∈ P. Then A cannot produce a verifying APB attributed to any registered principal, except with negligible probability. Proof. A verifying APB requires σh such that Verifypki (σh , canon(Es ) ∥ canon(Dh )) = ⊤ for some registered pki . The adversary may construct Es and Dh at will; the question is whether they can produce σh . Lemma 4.8 establishes that producing such a σh without access to ski requires breaking the existential unforgeability of ed25519, which is infeasible under the discrete log assumption on the curve25519 group [3]. Lemma 4.7 (Attribution Uniqueness). A verifying APB uniquely identifies a registered principal: there is no efficient way to produce an APB whose σh verifies under two distinct registered pki simultaneously. Proof. Two distinct ed25519 public keys verify the same signature over the same message only with negligible probability (the signature is bound to the secret key, and finding a colliding key pair reduces to solving discrete log on the curve). Lemma 4.8 (Forge Resistance under Computational Hardness). Any polynomial-time algorithm that produces a verifying σh over a chosen message without access to ski has success probability negligible in the security parameter. 9
Proof. This is the standard EUF-CMA property of ed25519 over the curve25519 group, established under the discrete-log assumption [3, 4]. 4.4
T8.4 — Finite-Time APB Construction Termination
Theorem 4.9 (Finite-Time APB Construction Termination). For any persistent halt event h on a system with bounded admission snapshot A0 and bounded trace trace≤te , the construction of Es terminates in time bounded by O(|A0 | + |trace≤te |). b e ), te , eid, hash(trace≤t ), and cause. Proof. By Definition 3.3, Es has six fields: hash(A0 ), D(t e Lemma 4.10 establishes that the field count is fixed; Lemma 4.11 establishes that each field’s capture time is bounded. Their conjunction gives the stated bound.
Lemma 4.10 (Bounded Es Field Count). The number of fields in Es is fixed at six and does not depend on runtime state. Proof. By Definition 3.3, fixed at compile time. Lemma 4.11 (Bounded Capture Time Per Field). Each of the six Es fields can be computed in time b e ) in O(1) (already bounded linearly in the size of its underlying input: hash(A0 ) in O(|A0 |); D(t computed by the IML monitor); te in O(1); eid in O(1) (UUID4 generation is a bounded-time operation under standard OS entropy assumptions, reading a fixed-length random bitstring from the kernel’s CSPRNG); hash(trace≤te ) in O(|trace≤te |); cause in O(1) (a fixed-vocabulary string). Proof. SHA-256 is linear in input size; the remaining operations are elementary. 4.5
Proposition 8.5 — Byzantine Principal Resistance
Proposition 4.12 (Byzantine Principal Resistance). Under the k-of-n threshold construction of Definition 3.4, an adversary A who controls j < k principal signing keys cannot produce a verifying APB(k) , except with negligible probability. Proof. A verifying APB(k) requires at least k entries in Σ to satisfy V1 (valid signature against a registered public key). By T8.3 (Impossibility of Anonymous Re-Authorization), each valid entry requires possession of the corresponding signing key sk j : producing a valid σ j without sk j reduces to breaking EUF-CMA of ed25519, which is infeasible under the discrete-log assumption. If A holds j < k keys, they can produce at most j valid entries; the threshold check fails. Entries for keys not held by A fail V1 with all but negligible probability. Therefore A cannot produce a verifying APB(k) with j < k keys. Remark 4.1. Proposition 4.12 formalises the security intuition for the composable access-control layer described in §12: with k = ⌈n/2⌉ + 1, the construction achieves strict majority quorum; with k = n, it requires unanimous governance. The adversary’s capture cost grows linearly in k, independently of the specific policy encoded in Dh .
10
Table 2: Implementation modules introduced in this work. LOC counts include docstrings. Module
LOC
Responsibility
agent/principal.py stack/apb.py stack/apb_verifier.py stack/governance_layer.py stack/multi_principal.py stack/apb_log.py
140 220 155 190 280 230
Principal Set P, keypair generation, registry, revocation. Es , Dh , APB classes; RFC 8785 encoding; signing; event_id. 5-predicate verification (V1–V5); failure-mode enum; attribution. Authority Resolution Function G; built-in policies. APB(k) , k-of-n verifier, threshold governance layer. HMAC-chained JSONL log; tamper-evident append; thread-safe writes.
Total
1215
Plus 103 unit tests over all modules.
5
Implementation
We provide a real-cryptography reference implementation of the APB in Python on top of the existing governance stack of [8]. All four theorems’ empirical claims (§6–§9) are verified against this implementation. Cryptography. We use ed25519 from the cryptography library [1], version ≥ 42. Each Hi ∈ P has a 32-byte private key (held only by Hi ) and a 32-byte public key held in the registry. Signatures are 64 bytes. Canonical serialisation is the RFC 8785 JSON Canonicalization Scheme (JCS), implemented via the jcs library [17]: keys sorted by Unicode codepoint, IEEE 754 number representation, no insignificant whitespace, UTF-8 encoding. This replaces ad-hoc sort_keys=True JSON and eliminates any cross-implementation ambiguity in the signed message. Modules. Four new modules implement the framework (see Table 2). Verifier predicates. The verifier evaluates five predicates against an APB and a registry, and returns the first failing predicate (or VALID): V1. The signed message verifies against pki for the Hi named in Dh . V2. Hi is in the registry. V3. Hi was active at te (not revoked before signing). V4. te lies within an acceptable window relative to the verification time (temporal freshness / clock-based replay defence). V5. eid has not been accepted in the current verification session (semantic uniqueness / duplicatesubmission defence). The verifier maintains a caller-supplied nonce store; the first accepted APB with a given eid adds it to the store, and any subsequent submission of the same eid is rejected regardless of te . V4 and V5 are complementary: V4 rejects temporally stale or future APBs; V5 rejects exact replays within the acceptance window. Together they provide both temporal freshness and semantic uniqueness. The enumerated failure modes (INVALID_SIGNATURE, PRINCIPAL_NOT_FOUND, PRINCIPAL_REVOKED, REPLAY, DUPLICATE_EVENT_ID, MALFORMED) allow Experiment B (§7) to count detection rates per attack class. 11
Persistence. APBs are persisted in append-only JSONL files with HMAC chaining: each entry’s HMAC is computed over the previous entry’s HMAC concatenated with the current entry’s canonical bytes. This gives log-level tamper evidence orthogonal to the per-APB signature: any deletion or reordering of entries breaks the chain. We do not use a Merkle tree in this implementation (it adds machinery for a distributed-log scenario that the present paper does not need); we note in §12 that a Merkle structure is the natural extension for distributed deployments. Decision policies. We provide three built-in DecisionPolicy callables that the governance layer can route to: always_resume, always_deny, and threshold_policy(deny_above, b e ) < deny_above; DENY when recalibrate_above). The threshold policy issues RESUME when D(t b deny_above ≤ D(te ) < recalibrate_above; RECALIBRATE otherwise. The choice of (θd , θr ) is operator configuration; Experiment A (§6) shows that governance completeness is invariant under this choice. 5.1
Proposition 5.1 — T ∗ Calibration
∗ with Proposition 5.1 (T ∗ Calibration Range). Let model M have measured drift threshold TM run-to-run standard deviation σM . The persistence window ∆T in DC.2 satisfies the calibration criterion if ∗ k1 · σM ≤ ∆T ≤ k2 · TM ,
with k1 ≥ 3 to bound the false-positive rate below the run-to-run noise of T ∗ and k2 ≤ 0.5 so that the persistence window declares a halt before the measured drift threshold is reached. This is a design recipe rather than a deductive theorem: k1 and k2 are operator choices reflecting tolerance to false positives and false negatives respectively. The empirical content of Proposition 5.1 ∗ ] is non-empty for the models we measure — equivalently, is the claim that the range [k1 σM , k2 TM ∗ that σM /TM is small. We verify this in §8 for five of the six models in our study; one model does not drift within the experimental window and is treated separately in §12.
6
Experiment A: Governance Completeness
Goal. Empirical demonstration that T8.1 holds: every runtime halt produced by the governance stack resolves through either the recovery loop (R1) or a signed APB (R2), with no third path observed. Setup. The full stack ACP + IML + RAM + RecoveryLoop + GovernanceLayer is run for 1000 steps per seed (50-step burn-in plus 950 drift steps), with 10 seeds (42–51), coverage 0.70, θ = 0.20, and a single principal Halice in P. Whenever the recovery loop returns HALT or DENY on a halt, the governance layer is invoked with a threshold-based decision policy; the resulting APB is verified through the full verifier (V1–V5) before being recorded. V5 is vacuously satisfied in this experiment: each governance event generates a fresh UUID4 event_id, so the nonce store never contains a duplicate.
12
Table 3: Governance Completeness (T8.1) (default policy): every HALT resolves through Recovery or a signed APB. NEITHER count is 0 across all seeds (assertion PASSED).
Seed
HALTs
Recovery RESUME
APB-signed
NEITHER
42 43 44 45 46 47 48 49 50 51
396 401 368 387 364 387 371 378 398 362
211 207 174 191 201 217 168 173 231 239
185 194 194 196 163 170 203 205 167 123
0 0 0 0 0 0 0 0 0 0
Total
3812
2012
1800
0
Table 4: Policy sensitivity in Exp A: T8.1 (Governance Completeness) holds identically under both threshold policies. The APB decision distribution varies with policy parameters; Completeness is policy-agnostic.
Policy default low_thresh
(θd , θr )
HALTs
Rec. RESUME
APB-signed
(0.40,0.70) (0.25,0.32)
3812 3812
2012 2012
1800 1800
RES/DENY/RECAL
NEITHER
1800/0/0 1037/727/36
Policy sensitivity. We run the same stack under two threshold policies. The default policy uses (θd , θr ) = (0.40, 0.70), which causes essentially all governance events to receive RESUME given b distribution under this protocol. The low-threshold policy uses (0.25, 0.32), which the empirical D exercises the full {RESUME, DENY, RECALIBRATE} output range. Both policies are run against the same seeds. Result. Table 3 reports the per-seed and aggregate counts for the default policy. Across 10 seeds and 3,812 halt events, every halt resolves through exactly one of the two paths; no third path is observed. The neither count, which would witness a violation of T8.1, is zero. Table 4 shows that the low-threshold policy produces an identical halt count and an identical APB count, but a different distribution of decisions (1037 RESUME / 727 DENY / 36 RECALIBRATE instead of 1800/0/0): completeness is policy-invariant; the decision distribution is not. Reading. The two tables together separate two distinct empirical claims. T8.1 is about path exhaustivity: every halt ends through R1 or R2, never neither, regardless of operator policy. The decision distribution within R2 is a property of the policy, not of T8.1; the framework is policyagnostic.
13
0 0
Table 5: APB Integrity (T8.2 + T8.3): four attack vectors against 200 freshly-signed APBs. All tampering attempts are detected by the verifier. T8.2: PASSED. T8.3: PASSED.
Attack vector
Trials
Detected
Missed
Detection rate
Tamper Es .A_0_hash Tamper Es .D_hat Tamper Es .t_e Tamper Es .trace_hash Tamper Es .cause
200 200 200 200 200
200 200 200 200 200
0 0 0 0 0
100.00% 100.00% 100.00% 100.00% 100.00%
Forge σh (random bytes) Forge σh (attacker key) Identity swap (Hi replaced) Replay (at te + 360 s)
200 200 200 200
200 200 200 200
0 0 0 0
100.00% 100.00% 100.00% 100.00%
1800
1800
0
100.00%
Total
7
Experiment B: APB Integrity
Goal. Empirical demonstration that T8.2 and T8.3 hold: no modification of an APB after signing is undetectable, and no forgery without ski verifies. We exercise nine adversarial vectors covering the threat-model classes A1–A4 of §3.5. Setup. 200 freshly-signed APBs are generated under varied evidence (each Es uses random A0 b across [0.20, 0.45], and a current te ). A baseline run confirms all 200 untampered hash, varying D APBs verify cleanly. Each attack vector is then applied to each APB, and the verifier output is recorded. Vectors. A1.1–A1.5: tamper Es field-by-field. For each of the five Es fields (A_0_hash, D_hat, t_e, trace_hash, cause), substitute a modified value while retaining Dh and σh . A2a: forge with random bytes. Replace σh with 64 random bytes. A2b: forge with attacker keypair. Re-sign canon(Es ) ∥ canon(Dh ) with a freshly-generated key whose public counterpart is not in P. A3: identity swap. Replace Hi in Dh with a different registered principal, retaining σh . A4: replay. Verify the (untampered) APB at a clock value te + 360 s with replay window 300 s. Result. Table 5 reports the per-vector counts. Across 1,800 attack attempts, the verifier detects every attack: 1800/1800, 0 misses, 100.0000% detection rate. T8.2 and T8.3 hold empirically. Reading. The five Es -tampering vectors collectively exercise Lemma 4.5 on every Es field, witnessing T8.2. The two forgery vectors witness T8.3 (the system layer cannot produce a valid signature without ski ). The identity-swap vector witnesses Lemma 4.7: substituting Hi in Dh 14
Table 6: Cross-model T ∗ : 6 LLM families, 3 runs each, 500 drift steps, T = 0.4, θ = 0.2. T ∗ as mean ± std across runs; σ/T ∗ is the intra-model coefficient of variation. Proposition 5.1 calibration criterion (σ/T ∗ < 5% for measured T ∗ ): HOLDS. 1 model(s) did not reach θ within the 500-step window.
Model
Family
Params
llama3.2:3b gemma4:latest mistral:7b qwen2.5:7b deepseek-r1:8b gpt-oss:20b
Meta Google Mistral Alibaba DeepSeek OpenAI
3.2B 4.0B 7.2B 7.6B 8.0B 20.0B
T ∗ (mean±std)
Dfinal
σ/T ∗
151 ± 0.9 264 ± 5.2 157 ± 0.0 154 ± 2.9 160 ± 0.8 —
0.430 ± 0.000 0.272 ± 0.010 0.434 ± 0.001 0.427 ± 0.001 0.424 ± 0.000 0.071 ± 0.005
0.62% 1.99% 0.00% 1.91% 0.51% —
without recomputing σh under the new principal’s key is detected. The replay vector witnesses the verifier’s V4 predicate.
8
Experiment C: Cross-Model T ∗
Goal. Empirical characterisation of the model-specific drift threshold T ∗ across six open LLM families and validation of the calibration criterion of Proposition 5.1. Setup. Six models (mistral:7b, deepseek-r1:8b, gemma4:latest, gpt-oss:20b, qwen2.5:7b, llama3.2:3b) are run via Ollama through the LiveLLM tool selector, 50-step burn-in plus 500 drift steps, sampling temperature T = 0.4, θ = 0.20, 3 runs per model. T ∗ is the first drift-step index at b ≥ θ. which D b values, sorted by parameter count. The intraResult. Table 6 reports per-model T ∗ and final D ∗ model coefficient of variation σ/T is reported in the rightmost column.
Reading. Five of six models reach θ within the 500-step window, with σ/T ∗ between 0.00% (perfect replication on mistral:7b) and 1.99% (gemma4). For these five models, the calibration ∗ ] = criterion σ/T ∗ < 5% of Proposition 5.1 holds with substantial margin: the range [k1 σM , k2 TM ∗ ] is non-empty for every measured model. [3σM , 0.5TM The sixth model, gpt-oss:20b, the largest in our sample at 20B parameters, does not drift within b = 0.071 ± 0.005, well below θ = 0.20. We discuss this case the experimental window: final D explicitly in §12; for the purposes of T8.1’s empirical verification it is sufficient to note that the calibration criterion is reported per-model rather than as a global property, and that the deployment recipe of Proposition 5.1 requires a measured T ∗ before ∆T can be set. Family-wise consistency. The Mistral family entry in our sample (mistral:7b, T ∗ = 157 ± 0) coincides with the Mistral-family T ∗ reported in [8] for a larger mistral-small-3.1 model under the same protocol (T* = 156 ± 1). Two distinct sizes within the same family yield T ∗ within one step, supporting the architectural rather than scale-driven character of the threshold.
15
Table 7: Temperature insensitivity of T ∗ . Three models were each run at four sampling temperatures, three runs per cell, 500 drift steps. Cell entries are mean ± std of T ∗ across runs at that temperature; the rightmost column is the per-model range maxT T ∗ (T ) − minT T ∗ (T ) of the cell means. Insensitivity criterion (range ≤ 10 steps): VIOLATED.
Model
T = 0.2
T = 0.4
T = 0.6
T = 0.8
range
gemma4:latest llama3.2:3b mistral:7b
239±6.9 155±0.9 154±2.6
255±7.3 155±1.6 157±2.2
249±3.9 156±1.2 156±1.9
290±18.4 156±2.5 152±1.6
51 2 5
Refutation of size-monotonicity. The largest model in the sample is the only one that does not drift. This refutes any monotone hypothesis under which larger models would be more (or less) susceptible to compliant drift than smaller ones. The empirical implication is that T ∗ must be measured per deployment rather than predicted from architectural parameters.
9
Experiment D: Temperature Insensitivity
Precondition for APB construction. An APB is constructible only after a governance event has been triggered — and a governance event requires that T ∗ be stable and measurable for the deployed model. If T ∗ drifted substantially with the LLM’s sampling temperature, the threshold would need to be recalibrated per deployment configuration, undermining the Proposition 5.1 calibration recipe (§5.1). Experiment D validates this precondition: T ∗ must be determined by the escalation protocol embedded in the system prompt, not by sampling stochasticity. A model whose T ∗ is temperature-stable can have its APB trigger calibrated once and deployed confidently across configurations. Goal. Test the conjecture that T ∗ is determined by the escalation protocol embedded in the system prompt rather than by LLM sampling stochasticity. Empirical translation: across a sweep of sampling temperatures, the per-model spread of mean T ∗ should be small. Setup. Three models from §8 are selected for diversity in baseline T ∗ : mistral:7b (T ∗ = 157, “fast cluster”), llama3.2:3b (T ∗ = 151, “fastest”), and gemma4:latest (T ∗ = 264, “slowest drifter”). Each is run at temperatures T ∈ {0.2, 0.4, 0.6, 0.8}, three runs per cell, 500 drift steps, identical burn-in and θ to §8. The insensitivity criterion is that the per-model range maxT T ∗ (T ) − minT T ∗ (T ) across the four temperatures is at most 10 steps. Result. Table 7 reports the per-cell T ∗ across the four temperatures and the resulting per-model range. The result is more nuanced than a single insensitivity claim: two of three models satisfy the criterion with substantial margin, and the third violates it. Reading. For the two fast-drifting models, llama3.2:3b and mistral:7b, T ∗ is strongly temperature-insensitive: the range across T ∈ {0.2, 0.4, 0.6, 0.8} is 2 and 5 steps respectively, and the within-cell standard deviations are below 3 steps for every (model, T ) pair. For these models 16
the conjecture of [8] — that T ∗ is determined by the escalation protocol embedded in the system prompt rather than by sampling stochasticity — replicates with substantial margin and generalises across families. For gemma4, the slow-drifting model in our sample, the picture is different. The per-cell mean at T = 0.8 rises to 290 ± 18.4 steps, against 239–255 at the lower temperatures, giving a per-model range of 51 steps and a within-cell standard deviation that is roughly three times larger than at T ≤ 0.6. The insensitivity criterion (range ≤ 10) is violated. Interpretation. We read this as evidence for a drift-floor effect: when a model’s T ∗ is close to the lower bound that the escalation protocol can produce, sampling temperature has little room to move the threshold. When T ∗ is well above that floor (as in gemma4, whose T ∗ is 1.7× larger than the fast-cluster), the additional steps before threshold crossing admit cumulative sampling fluctuations that compound at higher temperatures. The relevant quantity is therefore not whether temperature insensitivity holds globally but whether a model’s baseline T ∗ sits in the deterministic regime; this is itself a measurable property of the deployment and feeds back into the calibration recipe of Proposition 5.1 (a model in the non-deterministic regime requires a wider k1 σM margin to absorb temperature-induced spread). Implication for governance. Operators deploying models in the slow-drifting regime should not assume that a single-temperature characterisation of T ∗ generalises to other temperatures of the same model. Either the deployment temperature is fixed (and T ∗ measured at that temperature suffices), or the calibration is performed at the operationally relevant temperature(s). For fastdrifting models, a single-temperature characterisation appears to be sufficient.
10
Experiment E: Multi-Principal Threshold Governance
Goal. Empirically validate Proposition 4.12 (Byzantine Principal Resistance): under k-of-n threshold signing, governance capture requires the simultaneous compromise of at least k distinct principals. Setup. Three principals are registered: Alice (A), Bob (B), and Carol (C). We generate N = 1,000 governance events per scenario from fresh (Es , Dh ) pairs (unique event_id per event). Seven scenarios test the full threat surface of the k-of-n construction: ID
Configuration
Threshold
Expected result
S1 S2 S3 S4 S5 S6 S7
Alice only (k = 1, n = 1) Alice + Bob (k = 2, n = 2) Alice + Bob + Carol (k = 3, n = 3) Alice only, threshold=2 Alice + Bob, threshold=3 Alice (legit) + forged Bob sig Alice counted twice (duplicate)
1 2 3 2 3 2 2
VALID VALID VALID INSUFFICIENT_SIGNATURES INSUFFICIENT_SIGNATURES INVALID_SIGNATURE DUPLICATE_SIGNER
S4–S5 simulate under-threshold submission (attacker holds j < k keys). S6 simulates a capture 17
attempt: attacker controls Alice’s key and forges Bob’s signature with a random key not in the registry. S7 simulates key reuse (attempting to count the same key twice to satisfy the threshold). Results. Table 8 summarises the outcome. Table 8: Experiment E results. All 7 × 1,000 = 7,000 events produced the expected outcome; no scenario deviated from its expected result. ID
Scenario
S1 S2 S3 S4 S5 S6 S7
k = 1, 1 legit signer k = 2, 2 legit signers k = 3, 3 legit signers k = 2, 1 signer only k = 3, 2 signers only k = 2, 1 legit + 1 forged sig k = 2, same key counted twice
Expected
Events
Rate
VALID VALID VALID INSUFF. SIGNATURES INSUFF. SIGNATURES INVALID SIGNATURE DUPLICATE SIGNER
1 000 1 000 1 000 1 000 1 000 1 000 1 000
100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
Byzantine resistance. S6 and S7 are the critical Byzantine scenarios: in S6, an attacker who controls Alice’s key cannot obtain a verifying APB(2) without a second legitimate key — forging Bob’s signature fails at V1 (EUF-CMA of ed25519). In S7, attempting to count Alice’s key twice is caught by the duplicate-signer check before the threshold is reached. Both scenarios produce 0 false acceptances across 1,000 events, confirming Proposition 4.12: single-key capture is infeasible under k ≥ 2. Threshold monotonicity. Scenarios S1–S3 demonstrate clean threshold monotonicity: governance events with j valid signatures succeed at threshold k ≤ j and fail at k > j. The verifier correctly distinguishes “insufficient signatures” (S4–S5) from “invalid signature” (S6), enabling an operator to diagnose whether a rejection is due to under-provisioning or an active attack.
11
Experiment F: Infrastructure Fault Injection
Goal. Validate robustness of the APB verification protocol against five representative infrastructure fault classes that arise in realistic deployments: clock drift (F1), registry key mismatch (F2), concurrent writes (F3), log tampering (F4), and duplicate APB submission (F5). Each class targets a distinct predicate from the V1–V5 verification suite (§5) or the tamper-evident log (§5). Setup. We use a 3-principal registry (Alice, Bob, Carol) with ed25519 key pairs. Each fault class runs N = 1,000 events except F4, which runs R = 100 repetitions per tamper strategy with N = 10 log entries each (500 tampering trials in total). The V4 acceptance window is T ∗ = 300 s. All experiments are fully deterministic given the PRNG seed; results are reproducible via experiments/exp_fault_injection.py.
18
F1 — Clock Drift (V4 boundary precision) We inject artificial clock offsets δ ∈ {−600, −310, −301, −299, −150, −1, 0, +1, +150, +299, +301, +310, +600} seconds into the evidence timestamp te , holding the verifier clock fixed at now. The V4 predicate accepts iff |δ| ≤ T ∗ . Table 9: F1 Clock-drift results. Acceptance is exactly |δ| ≤ 300 s; all 1 000 events per offset behave uniformly. δ (s)
Expected
Accepted / 1 000
−600 −310 −301 −299 −150 0 +150 +299 +301 +310 +600
REJECT REJECT REJECT ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT REJECT REJECT REJECT
0 0 0 1 000 1 000 1 000 1 000 1 000 0 0 0
Correct ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
All 13 offset points are classified correctly (Table 9). The boundary is sharp at ±1 s relative to T ∗ : offset −299 s is accepted and −301 s is rejected in 100% of trials, confirming deterministic V4 enforcement. F2 — Registry Key Mismatch (V1 under key corruption) We register Alice with a wrong public key (a freshly generated key unrelated to her signing key) and submit 1,000 legitimately signed APBs. The verifier must detect the mismatch via V1 and return INVALID_SIGNATURE rather than VALID or PRINCIPAL_NOT_FOUND. Result: 0 false acceptances; 1,000/1,000 events return INVALID_SIGNATURE (false-acceptance rate = 0%). This models supply-chain key substitution or registry database corruption: even if the attacker’s substituted key is plausible, a signature produced under the true private key fails V1 unconditionally due to EUF-CMA security of ed25519 (§4.2). F3 — Concurrent Writes (V5 thread safety) We spawn 16 threads, each submitting 50 APBs (with distinct event_id UUIDs) to a shared APBLog and a shared seen_event_ids nonce store protected by a threading.Lock. Total: 800 events. Result: All 800 events are accepted exactly once; 0 duplicate acceptances; 0 thread errors; log integrity check passes (800/800 entries verified). The locking discipline serialises V5 nonce-store updates, preventing time-of-check/time-of-use (TOCTOU) races that could allow a duplicate event_id to be accepted by two threads concurrently.
19
F4 — Log Tampering (HMAC chain integrity) We apply five tamper strategies to the HMAC-chained JSONL log across R = 100 repetitions each (Table 10). Table 10: F4 Log-tampering detection rates (R = 100 per strategy, N = 10 entries per log, 500 total tamper trials). All five strategies are detected in 100% of trials. Strategy
Description
Detection rate
Field modification Entry deletion Entry reordering HMAC forgery prev-HMAC splice
Change D_hat in a middle entry Remove the middle entry from the chain Swap the first two entries Replace entry_hmac with random hex Forge entry 0 and update entry 1’s prev_hmac
100% 100% 100% 100% 100%
The prev-HMAC splice (last row) is the most sophisticated attack: the adversary forges the HMAC of entry 0 and propagates the forged value into entry 1’s prev_hmac to maintain apparent chain continuity. This is detected because entry_hmac is computed as HMAC-SHA256(K, seq∥ apb_json∥prev_hmac): an attacker who does not know K cannot produce a valid entry_hmac for the forged entry, so verify_integrity rejects at entry 0 regardless of the splice. F5 — Duplicate APB Submission (V5 necessity) We submit the same APB N = 1,000 times, first without the V5 nonce store (seen_event_ids = None), then with it (seen_event_ids as a live set). Table 11: F5 Duplicate-submission results. Without V5 every replay is accepted; with V5 only the first submission succeeds. Configuration Without V5 (V4 only) With V5
Accepted
Duplicates caught
False acceptances
1 000 1
0 999
999 0
Without V5, every replay within the 300 s window is accepted: V 4 is a freshness check, not a uniqueness check. A legitimately signed APB can be replayed an arbitrary number of times if the replays arrive within the acceptance window. With V5 the event_id UUID is recorded in the nonce store on first acceptance; all 999 subsequent submissions return DUPLICATE_EVENT_ID. Fault injection summary. Table 12 aggregates the five fault classes. The fault injection results demonstrate that each verification predicate independently enforces its intended security property, and that the predicates are compositionally sound: no fault class circumvents another predicate by exploiting the order of checks.
20
Table 12: Experiment F summary. All five fault classes are handled correctly by the implementation; false-acceptance rate is 0% for F2–F5, and V4 boundary precision is exact for F1. Fault
Targeted predicate
False-accept rate
Result
F1 Clock drift F2 Key mismatch F3 Concurrent writes F4 Log tampering F5 Duplicate APB
V4 temporal freshness V1 signature validity V5 + log thread safety HMAC chain integrity V5 semantic uniqueness
0% outside window 0% 0% — 0% (with V5)
All 13 offsets correct 100% INVALID_SIGNATURE 800/800 verified 100% detected (5/5 strategies) 999/999 caught
12
Discussion
Models that do not drift. The case of gpt-oss:20b in §8 merits explicit treatment. Under our 500-step protocol the model’s drift estimator remains well below threshold; we cannot, from this data alone, distinguish three explanations: (i) the model is architecturally robust to the specific escalation protocol embedded in the system prompt and would not drift at any reasonable horizon, (ii) the model has a genuinely larger T ∗ that exceeds our window, (iii) the model’s tool-selection distribution under our LiveLLM prompt is structurally different from the other five (e.g. a strong default toward low-risk actions that does not respond to context-pressure scaling). For deployment, this distinction matters: under (i) the model would not need an APB-emitting governance layer at all under this protocol, while under (ii) or (iii) the operator would extend the window or adapt the prompt. In either case, the implication for governance design is the same: P and G are configured once; ∆T is configured per deployment from a measured T ∗ , with the explicit understanding that T ∗ may be infinite or undefined for some models. Boundaries of the result. The APB establishes accountability, not access control. A compromised principal can sign a malicious decision and the APB will record it. The mitigations are configurable around the APB, not within it: k-of-n multi-signature for sensitive decisions, key rotation under RECALIBRATE governance events, and out-of-band review of recorded APBs against expected decision patterns. The proofs of T8.2–T8.4 rest on the security assumptions of ed25519 over curve25519 and on the RFC 8785 canonicalization properties. A break of those assumptions would invalidate the cryptographic guarantees but not the structural claims (T8.1 in particular is a partition argument that does not depend on the signature scheme). It is worth noting explicitly that T8.2 and T8.3 are reductions to known cryptographic properties — the existential unforgeability of ed25519 under chosen-message attack (EUF-CMA) and the injectivity of RFC 8785 canonicalization — rather than novel mathematical results. Their value lies in showing that these wellestablished properties compose cleanly with the APB structure to produce the non-repudiability and anonymous-re-authorization impossibility guarantees needed by the governance layer. Composability with access control. The APB protocol is deliberately orthogonal to access control: it records that a named principal made a decision, not whether that principal was entitled to do so. This separation is a feature, not a limitation — it allows the APB to be composed with any access-control layer without redesigning either. Three composable extensions are worth noting for deployments that require stronger guarantees:
21
k-of-n threshold signing. For decisions of high consequence (e.g. RECALIBRATE events), operators can require that k distinct members of P each produce a valid σh over the same (Es , Dh ) before the governance layer accepts the APB. Under k-of-n, governance capture requires the simultaneous compromise of at least k principals; with k = ⌈n/2⌉ + 1 this becomes a majority quorum with Byzantine tolerance. Role-based authority scoping. The scope field of Dh is a free-form string in the current implementation; a deployment MAY define a structured vocabulary and enforce that principals with a given RBAC role can only sign APBs with scopes from their allowed set. The verifier’s V2/V3 predicates can be extended to check role membership without changing the cryptographic core. Capability tokens and policy engines. For deployments already running a policy engine (OPA, Cedar, or similar), the APB’s eid can serve as an immutable token whose issuance is gated by the policy layer. The APB then becomes the non-repudiable audit record of a token-issuance event rather than a standalone access decision. These extensions are deferred to subsequent work (P9 onwards in this series); the present paper establishes the primitive on which they compose. Integration paths. Two integration directions are natural extensions and deferred to subsequent work. MCP/A2A integration: the governance stack of [8] operates on tool-call traces from a LangGraph state graph; the Model Context Protocol and Agent-to-Agent communication standards define interception points at which the APB-emitting layer could be applied transparently to agent code — this is the focus of the next paper in this series. Distributed APB log: replacing the JSONL+HMAC chain with a Merkle tree (and, for cross-organisational deployments, anchoring to a public transparency log) gives stronger tamper evidence under multi-writer scenarios. Exploratory nature of Experiment D. The temperature-sweep results of §9 should be read as exploratory observations, not as statistically validated claims. With three runs per temperaturemodel cell, the results are insufficient to estimate within-cell variance reliably; they motivate hypotheses about the drift-floor effect and the temperature-T ∗ interaction, but a confirmatory study would require at least N ≥ 10 runs per cell with power analysis. We move these results to the “Observations” register rather than the “Validation” register of the paper’s contribution. Choice of decision-policy thresholds. Experiment A’s policy comparison shows that ProtocolBounded Governance Completeness is invariant under threshold choice. We do not, in this paper, prescribe a particular (θd , θr ). Their setting is a deployment decision tied to the operator’s tolerance b at the moments for halts that escalate to DENY versus RESUME, and to the empirical distribution of D of governance event in the operator’s workload.
13
Conclusion
We have introduced the Accountability Proof Block as the formal mechanism by which an LLM agent’s persistent halts resolve into identity-bound, cryptographically verifiable governance decisions. The construction is supported by four theorems — protocol-bounded governance complete-
22
ness, non-repudiability, impossibility of anonymous re-authorisation, and finite-time evidence construction — a Byzantine principal resistance proposition for k-of-n threshold signing, and a realcryptography reference implementation using the RFC 8785 JSON Canonicalization Scheme and a five-predicate verifier that provides both temporal freshness and semantic uniqueness guarantees. Empirical validation across 3,812 halt events, 1,800 adversarial attempts, 7,000 multi-principal threshold events, 18 cross-model runs, and 36 temperature-sweep runs shows that the construction behaves as the theory predicts and that the model-specific drift threshold T ∗ is stable, measurable, and architecture-driven rather than scale-driven, with the empirical caveat that temperatureinsensitivity itself is conditional on a model sitting in a fast-drifting regime (a result we flag as exploratory pending larger-sample confirmation). The result is a small, configurable, provablybounded mechanism by which a system that has reached the limit of its own authority can hand the resolution back to a named, accountable human — without trusting the system itself to make that handover honestly — and that composes cleanly with threshold signing, RBAC, and policy engines for deployments that require stronger access-control guarantees. The contribution of P8 is not that humans remain in the loop. It is that when autonomous authority ends, the system can prove who took control, under what evidence, and under which cryptographic guarantees.
References [1] Python Cryptographic Authority. cryptography: Python cryptographic recipes and primitives. https://github.com/pyca/cryptography, 2024. Version 42+. [2] Yuntao Bai et al. Constitutional AI: Harmlessness from AI feedback. arXiv:2212.08073, 2022.
arXiv preprint
[3] Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. High-speed high-security signatures. Journal of Cryptographic Engineering, 2(2):77–89, 2012. ed25519 specification. [4] Dan Boneh and Victor Shoup. A Graduate Course in Applied Cryptography. Self-published, 2014. URL https://crypto.stanford.edu/~dabo/cryptobook/. [5] Dan Boneh, Manu Drijvers, and Gregory Neven. Compact multi-signatures for smaller blockchains. In ASIACRYPT 2018, pages 435–464, 2018. [6] Marcelo Fernandez. Atomic decision boundaries in delegated agent systems. arXiv:2604.17511, 2026. Paper 0 of the Agent Governance Series. https://doi.org/10.5281/zenodo.19670649. [7] Marcelo Fernandez. Agent control protocol (ACP): A formal framework for stateful admission control in autonomous agent systems. arXiv:2603.18829, 2026. Paper 1 of the Agent Governance Series. https://doi.org/10.5281/zenodo.19672575. [8] Marcelo Fernandez. Closing the execution gap in LLM agent systems: Empirical evidence for compliant drift, partial observability, and integrated runtime governance. arXiv:TBD, 2026. Paper 7 of the Agent Governance Series. https://doi.org/10.5281/zenodo.19929771.
23
[9] Marcelo Fernandez. Irreducible governance structure: Fair allocation, composition, and enforcement in multi-agent systems. arXiv:TBD, 2026. Paper 3/4 of the Agent Governance Series. https://doi.org/10.5281/zenodo.19708496. [10] Marcelo Fernandez. From admission to invariants: Measuring deviation in delegated agent systems. arXiv:2604.17517, 2026. Paper 2 of the Agent Governance Series. https://doi.org/ 10.5281/zenodo.19672589. [11] Marcelo Fernandez. Operationalizing reconstructive authority: Runtime construction, dependency resolution, and execution gating. arXiv:TBD, 2026. Paper 6 of the Agent Governance Series. https://doi.org/10.5281/zenodo.19699460. [12] Marcelo Fernandez. Reconstructive authority model (RAM): Execution validity under partial state observability. arXiv:2604.22898, 2026. Paper 5 of the Agent Governance Series. https: //doi.org/10.5281/zenodo.19669430. [13] Rosario Gennaro and Steven Goldfeder. Fast multiparty threshold ECDSA with fast trustless setup. In ACM CCS 2018, pages 1179–1194, 2018. [14] Ben Laurie, Adam Langley, and Emilia Käsper. Certificate transparency. RFC 6962, 2013. [15] Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Gebru. Model cards for model reporting. In Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT*), pages 220–229, 2019. [16] OpenAI. GPT-4 system card. https://openai.com/index/gpt-4-system-card/, 2024. Accessed 2026-05-08. [17] Anders Rundgren, Bret Jordan, and Samuel Erdtman. JSON canonicalization scheme (JCS). RFC 8785, 2020. URL https://www.rfc-editor.org/rfc/rfc8785. IETF Informational RFC. [18] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Yellow Paper, 2014. EIP-150 Revision.
24
Related documents
- Identity-Bound Governance Under Execution Uncertainty: An Accountability Proof Block for LLM Agent Persistent Halts, with Cryptographic Implementation and Cross-Model Calibration#1155722
- From static oversight to distributed corrigibility#696675
- Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents#361419
- LLM Agents Can Easily Tamper With Their Own Traces#1078337
- Tracing Authority: Testing Responsibility Diffusion Integrity in Algorithmic Decision Pipelines#79524
Retrieved via Conceptio: every document is proof-bundled with source, license, and retrieval metadata.
Read the Docs → · View CLI source on GitHub · Conceptio Open Knowledge Archive