Trust, Accountability and Control: Post-Quantum Authentication and Evidence-Driven Authorization for Artificial Intelligence Agents

Abstract

Artificial intelligence (AI) agents need authenticated identities, bounded action scopes and evidence before receiving adaptive authority. We present a post-quantum trust, accountability and control (TAC) protocol composing signed requests, independently signed observations, scoped admission and transactional evidence consumption. A Tamarin abstraction checks six universal receipt properties and two existential witnesses; three mutants expose omitted mechanisms. Replay preserves 38,400 recorded controller positions. Execution study E6 covers 48 matched configurations and eight ablations: the bound dispatcher produces no unpermitted effect in 22 mediated configurations, while both privileged bypasses succeed. Twelve-visit study E7 compares adaptive authority with competent static enforcement in 28 matched episodes, alongside 24 isolated execution ablations and two history-mutant diagnostics. Both policies resist tested command substitutions; adaptive warm-up withholds 24 of 48 compliant proposals. False authorized reports violate the illustrative task predicate under both. Two diagnostics show signed-prefix reconstruction detecting injected duplicate reinforcement before effects, and a separate arithmetic oracle checks retained trajectories. Paired-path medians are 3.41 ms for the module-lattice-based digital signature algorithm ML-DSA-44 and 2.19 ms for Ed25519 on the recorded x86 configuration; separate primitive experiments examine build sensitivity. Deterministic results establish conditional composition boundaries with progress costs. Truthful observation, complete mediation, provisioning and durable storage remain assumptions.

1. Introduction

Artificial intelligence (AI) agents increasingly translate generated plans into operations on resources. In a multi-agent workflow, proposing an operation, assessing its compliance and executing it may be the responsibility of different principals. The controller must then establish where each request comes from, check that the observations used to assess it come from an entitled source and decide which action the accumulated evidence currently permits. Handled separately, these checks leave a gap between message authentication and operational authorization: an authenticated agent can request an operation outside its assigned scope, an observer can report on a subject it is not entitled to assess, and a previously valid report can be replayed to influence future permissions.

Trust, accountability and control (TAC) addresses the decision side of this problem. Trust represents positive and negative evidence as an opinion under uncertainty; Accountability assigns negative evidence to the roles associated with a violation; Control compares the requested autonomy with an evidence-derived ceiling and applies compliance, property-veto and residual-risk checks. Together, the three layers form a feedback loop in which observations at one visit shape the authority available at later visits. Authentication therefore belongs to the evidence and action boundary: substituted or repeatedly consumed inputs can distort the loop without any change to the controller equations.

The National Institute of Standards and Technology (NIST) module-lattice-based digital signature algorithm (ML-DSA) supplies a signature primitive [1]; it does not define agent operation grants, observer roles or durable authority updates. Post-quantum signatures already protect deep-learning artifacts [2] and federated-learning communications [3], so their introduction into AI is not itself a contribution. We study their composition with scoped action admission, independently authenticated observations and evidence-driven authorization.

Practical agentic systems show why this composition matters. AICEBERG translates user intentions into instrument commands through a large language model (LLM) and the Model Context Protocol (MCP), and an independent safety component checks each command before execution [4]. Progent constrains tool privileges, and CaMeL separates untrusted data from authorized control flow [5,6]. These designs draw a clear line between generating an action and authorizing it. In the TAC composition studied here, permission depends on a persistent history of role-specific observations. If authentication does not preserve the event identities, assessment scopes and update order of that history, the cryptographic layer can alter the very policy it is meant to protect.

We investigate four research questions:

• RQ1—Protocol composition. How can post-quantum authentication of agent requests and observer reports be composed with scoped admission and the TAC gate so that identity, action context and evidence provenance have distinct and enforceable meanings?
• RQ2—State and semantic preservation. Under which assumptions is each authenticated message consumed locally at most once, and when does the controller preserve its configured ledger and decisions under reordering, duplication, restart or missing evidence?
• RQ3—Implementation costs. What computation and representation costs arise on the receipt path and on the complete signed request–observation path, and how do signature parameters, backend build and durable storage affect their interpretation?
• RQ4—Decision and deployment limits. Which limits remain after authentication, in particular with dishonest authorized observers, divergent evidence availability, adaptive warm-up and action changes after verification?

The contributions are as follows: C1, an implemented protocol separating agent and observer grants and binding distinct signed messages to an expected proposal; C2, persistent admission and evidence consumption, supported by conditional arguments and a symbolic receipt model; C3, recorded-stream replay, boundary/failure cases, communicating components and build-sensitive cryptographic/application measurements; and C4, a bounded executor and evidence archive connecting authenticated proposals and committed authority to actual effects. A multi-visit comparison with competent static enforcement isolates execution mechanisms and quantifies role-specific selectivity and progress costs while retaining the limit of false authorized assessments.

Seven experiments, E1–E7, structure the evaluation: E1 replays a recorded controller stream (E1b checks source-proposal linkage); E2 tests receipt acceptance and failures; E3 measures receipt-path costs; E4 exchanges receipts between processes (E4b adds cross-host transfer); E5 tests integrated agent requests and their complete-path costs; E6 studies execution binding and archived evidence; and E7 follows competent static/adaptive enforcement over multiple visits through effects. Their inferential units and scope are specified in the methods.

The implemented boundary uses centrally provisioned keys and bounded plans, independently verifiable messages and one local durable ledger per consumer, without blockchain or consensus. Signatures protect declared application messages; they do not establish observer truth, resource confinement or agreement across consumers.

The remainder of the article positions the composition against access-control, agent-security, provenance and post-quantum AI research; specifies the architecture together with its message and state rules; reports the experimental results; and answers the research questions, including their remaining boundaries.

2. Related Work and Research Position

2.1. Authentication, Scoped Authority and Usage Control

Access-control research has long separated a principal’s identity from the policy that governs its operations. Attribute-based access control evaluates attributes of subjects, objects, operations and environments [7], and zero-trust architecture separates policy decisions from their enforcement [8]. The usage-control model UCON_ABC (authorizations, obligations and conditions) models ongoing usage decisions over mutable attributes [9]. TAC therefore does not introduce contextual or evolving authorization as such; the question addressed here is narrower and concerns the authenticated inputs and discrete visit updates of an evidence-driven controller.

OAuth rich authorization requests carry structured, fine-grained authorization details [10]. Demonstrating Proof of Possession (DPoP) binds OAuth tokens to their sender through proofs of key possession and request context, although DPoP alone does not authenticate the client [11]. Authentication and Authorization for Constrained Environments using OAuth (ACE-OAuth) adapts these functions to constrained environments [12], and macaroons attenuate delegated authority through contextual caveats [13]. In contrast, our prototype pins agent identity and operation/resource scope in a local grant, admits one signed proposal per episode slot and lets TAC decide separately whether that proposal may execute. It issues no transferable bearer credential and does not interoperate with OAuth or macaroons.

The MCP authorization specification governs access to protected Hypertext Transfer Protocol (HTTP) resources through an OAuth-based framework [14]. Resource access, however, says nothing about the semantics of an agent’s proposed action or about the reliability of the observations that later update its permissions. Verifiable credentials distinguish issuer, holder and verifier roles [15]; our static grants are a simpler local provisioning mechanism, without credential presentation or a decentralized identity service. These comparisons place the prototype’s trust boundary precisely: verification is local, but trust is established centrally.

2.2. Agentic Execution and AICEBERG

AICEBERG offers a particularly relevant architectural comparison [4]. Its LLM–MCP workflow, using Standard Commands for Programmable Instruments (SCPI), keeps instrument execution apart from its safety resources, which include command whitelisting, default-deny behavior, syntax and parameter validation, instrument checks, and command/result logging. The reported evaluation uses a physical spectrum analyzer, a 100-command suite and 11 injection attempts, a degree of physical integration beyond our synthetic execution fixtures. Both designs share the principle of independent checking before execution. The described AICEBERG protocol does not specify post-quantum authentication of agent keys, role-scoped observer reports or a persistent adaptive-evidence frontier; this observation concerns the published protocol, not every protection a deployment might add.

TAC separates permission to request an operation under a static grant from permission to execute at an evidence-derived autonomy level. The observer authenticates its assessment but does not set the resulting ceiling or negative increment. AICEBERG informs this mediation boundary; its hardware experiments are not reproduced or used for matched latency/safety rankings.

Progent enforces symbolic privilege policies on tool calls [5], and CaMeL controls information flow through capability-aware execution [6]. AgentDojo evaluates stateful tasks under prompt injection [16]. Recent work on agent permissions connects user-facing permission interfaces to their enforcement [17], and a position paper on holistic agent security distinguishes authorization from broader alignment and isolation requirements [18]. Authenticated admission and a durable ledger do not solve those broader problems: a prompt-injected agent or observer can still sign harmful or false content while its key remains authorized. Our controlled cases therefore test the declared protocol boundary, not resistance to arbitrary prompt injection.

2.3. Post-Quantum Cryptography in AI and Constrained Systems

Castiglione et al. compare post-quantum cryptography (PQC) signature schemes for deep-learning models and their updates, including federated configurations [2]. Signatures there protect the origin and integrity of learned artifacts, assuming authenticated key exchange. Here, the signed object is an action request or a role-specific assessment that can change authority state, which calls for different application bindings and consumption semantics.

PQ-FLCom provides a close post-quantum comparison for AI communication [3]. Its Flower-based hierarchy ranges from an unsigned baseline to ML-DSA-87 authentication, alone or combined with the module-lattice-based key-encapsulation mechanism ML-KEM-512 and Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) for confidentiality. Its network adversary alters updates after signing without holding valid client keys, and the evaluation measures model convergence under simulated in-transit manipulation; round identifiers or nonces are discussed as a replay countermeasure. Our evaluation targets a different object: scoped action admission, observer eligibility, exact proposal binding and durable evidence updates. Because workloads and backends differ, PQ-FLCom’s overhead percentages do not transfer to our SQLite-backed path.

The ESP32 study by Castiglione et al. implements optimized Dilithium-5 signing with hardware-assisted polynomial arithmetic and assesses its feasibility on constrained devices [19]. We consider only its embedded signature component, since the accompanying blockchain mechanism lies outside our architecture; its pre-standard Dilithium-5 timings are neither evidence of interoperability with final ML-DSA-87 nor predictions for our host. The present study measures elapsed and process central processing unit (CPU) time, without power or energy measurements.

ML-DSA provides authentication, whereas ML-KEM provides key establishment [1,20]. We focus on signatures because the protocol must bind named principals and their observations to authorization events; adding a key-encapsulation mechanism (KEM) without a complete confidential-channel design would not strengthen that binding. Migration measurements by Rios and Montenegro [21] and studies of post-quantum Transport Layer Security (TLS) by Kampanakis and Childs-Klein [22] show that primitive, transport and application costs must be interpreted separately. Our controlled comparison of OpenSSL builds addresses this point within one implementation family.

2.4. Provenance, Attestation and the Remaining Composition Gap

In-toto binds signed supply-chain metadata to authorized functionaries and a prescribed layout [23]. Remote ATtestation procedureS (RATS) separates attestation evidence, its appraisal and relying-party decisions [24]. Supply Chain Integrity, Transparency and Trust (SCITT) and certificate transparency (CT) provide registration, inclusion and transparency mechanisms [25,26], and Dead Simple Signing Envelope (DSSE) makes typed signing unambiguous [27]. Each informs part of our boundary, yet a locally signed observation is neither a hardware attestation nor a transparency inclusion proof. Our ledger guarantees local uniqueness and durable controller transitions, not a common log view.

Complete mediation and observable policy violations remain the foundational assumptions of enforceable security policies [28]. Subjective logic supplies the mapping from evidence to opinions [29], and structural responsibility motivates the attribution of negative evidence [30]. Tamarin supports symbolic analysis of stateful protocols [31]. The composition question examined here is this: which authenticated request and observation may enter which durable slot, and how that input changes the authority available to a future action. Table 1 summarizes the resulting distinctions. “Not specified” refers to the published mechanism and does not imply that a deployment lacks other protections; the comparison is architectural, not a matched empirical benchmark, and claims no priority over all agent architectures or cryptographic authorization systems.

Table 1. Security boundaries of related mechanisms. Abbreviations: LLM, large language model; MCP, Model Context Protocol; SCPI, Standard Commands for Programmable Instruments; PQ, post-quantum; PQC, post-quantum cryptography; DPoP, Demonstrating Proof of Possession; TAC, trust, accountability and control; ML-DSA, module-lattice-based digital signature algorithm; RATS, Remote ATtestation procedureS; SCITT, Supply Chain Integrity, Transparency and Trust; CT, certificate transparency.

Mechanism	Authentication or Protected Input	Authorization/State	Relevant Distinction
AICEBERG [4]	LLM–MCP–SCPI command pipeline	Independent command/parameter safety; physical execution	PQ principal bindings and adaptive evidence frontier not specified
Progent/CaMeL [5,6]	Tool-call privilege/data-flow boundaries	Symbolic policy/capability enforcement	Evidence-driven ceiling and PQ receipt consumption are separate concerns
OAuth/DPoP [10,11]	Fine-grained requests; token possession proofs	Scoped protected-resource access	No claim of TAC or OAuth interoperability
PQC model signing [2]	Learned models and model updates	Integrity/origin before model use	Action/assessment scopes and TAC updates differ
PQ-FLCom [3]	ML-DSA-authenticated updates; optional encrypted exchange	Verification before aggregation; replay extension discussed	Scoped agent actions and persistent role evidence differ
In-toto/RATS [23,24]	Artifact provenance/appraisal evidence	Layout or relying-party policy	Local TAC updates; no hardware attestation
SCITT/CT [25,26]	Registered statements and log entries	Inclusion and transparency mechanisms	Our database does not provide globally consistent views
This study	Agent requests and independently signed observations	Scoped admission + pre-visit TAC gate + durable frontier	Evaluated PQ composition with centralized provisioning

3. Materials and Methods

3.1. System and Threat Model

The system comprises agents that propose actions, observers that assess them, consumers that host a TAC controller and an executor. Agents and observers are authorized through separately provisioned grants. In the integrated path, a consumer first admits an authenticated, in-scope agent request; the observer then reports compliance-related fields about that exact proposal. The consumer authenticates the resulting receipt, checks the observer’s grant, binds the receipt to the expected proposal and policy and commits it to the episode ledger. The executor is assumed to honor the controller’s decision, an assumption that signatures cannot enforce.

A deployment authority provisions each consumer with public keys and grants. A grant ties a key identifier to one issuer, algorithm and key epoch; lists the subjects, roles, audiences and evidence types it covers; and carries an enabled flag. The E1–E5 prototype uses a static trust store, so a consumer never needs to contact an issuer online; E6 adds locally installed signed snapshots without an online issuer call. Verification and state are thus distributed, while provisioning remains centralized. The live Transmission Control Protocol (TCP) experiment runs on a single host, and a complementary signed-batch transfer places producers on an ARM machine and consumers on an x86 server; both remain within one administrative domain.

Each trusted episode plan specifies its subject, domain, audience, policy digest, payload-binding mode, expected role/visit bindings, number of visits (at most 64) and controller configuration; plans are frozen during the experiments. In a deployment, each expected proposal must reach the consumer through a trusted local ingress before any observation about it can be accepted. The implementation provides no discovery or open registration service for future proposals, which remains an integration task. Pinning the expected digest prevents a producer from substituting a different action under a valid signature.

The network adversary may observe, inject, alter, duplicate, delay, suppress and reorder messages. It does not hold honest signing keys and cannot replace the consumer’s trust store or policy, alter its database or roll durable storage back to an earlier snapshot. Key compromise, dishonest authorized producers, a compromised controller and an unfaithful executor are treated as separate cases outside the inherited authenticity guarantee. The protocol does not provide traffic confidentiality, privacy of evidence content, trusted time, global revocation or availability.

3.2. Conceptual Architecture and Principal Notation

Figure 1 connects the cryptographic boundary to the three TAC layers. We write $A_i$ for an agent, $O_j$ for an observer and $C_c$ for a consumer hosting a TAC controller. The four roles are $\mathcal{R}=\{\mathrm{monitoring},\mathrm{scoring},\mathrm{access},\mathrm{response}\}$. Identifiers and signing keys are provisioned identities, whereas the ledger quantities $r_i,s_i$ are behavioral evidence: growing behavioral trust neither creates a cryptographic identity nor widens an agent’s static operation grant.

Figure 1. Post-quantum trust, accountability and control (TAC) architecture. Solid arrows denote runtime dependencies; dashed arrows denote trusted provisioning. Control uses prior state and current observations; accountability then updates the next state. The output is a controller decision; bounded effects are evaluated separately in E6/E7.

The governed subject S names the team or workflow. For each episode e and visit v, a trusted plan maps every role to its expected agent and exact proposal; $h_{\pi }$ denotes a policy digest and $h_p=\mathrm{SHA}384\left(p\right)$ the Secure Hash Algorithm (SHA)-384 digest of payload p. The agent grant $G_A$ restricts subject, role, audience, operation, resource and maximum requested autonomy, while the observer grant $G_O$ restricts which subjects and roles an observer may assess. One organization may provision both kinds of grant, but an observer key cannot sign valid agent requests, and an agent key cannot sign valid observations.

The illustration distinguishes software principals from one consumer’s durable evidence slots and transitions. Arrows denote dependencies: trust reads the pre-visit state, control combines admitted requests with current observations, and accountability updates the next state once decisions are taken. Provisioning is centralized and verification local; Figure 2 gives the temporal order.

Figure 2. Request, observation and complete-visit sequence. The original measured path ends at the committed decision; E6 adds the bounded dispatch checks and synthetic effect.

3.3. Signed Agent Requests and Scoped Admission

Each request $Q_{e,v,i}$ has exactly 17 fields: agent and key identifier, algorithm and key epoch, subject, episode, visit, role, audience, policy digest, operation, resource, payload digest, requested autonomy ${\ell }_q\in \{0,1,2,3\}$, schema, domain and a deterministic event identifier. The agent signs

$$m_Q=\mathtt{TAC}-\mathtt{Request}-\mathtt{v}\mathtt{1}\Vert 0\Vert canon\left(Q_{e,v,i}\right),{\sigma }_Q={Sign}_{s{k}_{A_i}}\left(m_Q\right).$$

(1)

With ML-DSA, TAC-Request-v1 is also passed as the application programming interface (API) context; Ed25519 signs the prefixed message through its standard interface. Requests and observations use different prefixes in both schemes. Requests follow the same restricted American Standard Code for Information Interchange (ASCII) encoding and bounds as receipts (Section 3.4), and their envelope contains exactly the request and its signature.

Admission checks the agent grant, the signature, the trusted role/visit context and the exact proposal bytes. The requested operation and resource must lie within $G_A$, the requested autonomy must not exceed the granted maximum, and the signer must be the agent the plan expects for that slot. Trusted provisioning maps operation, resource and autonomy to the exact payload; E1–E5 do not parse arbitrary tool arguments. E6 supplies a fixed typed addition/assignment schema for its synthetic sink; a real tool adapter must still maintain this semantic mapping.

An admitted request occupies one persistent slot $(e,v,i)$, regardless of signature randomness or key epoch. Resubmitting it returns duplicate, and no other authenticated request can overwrite the slot. Admission is committed atomically in SQLite, so a failed transaction leaves no slot behind. Admission grants neither behavioral evidence nor permission to execute: it separates scope authorization to request from the subsequent TAC authorization to execute.

A signed observation $R_{e,v,i}$ is accepted only if the corresponding request slot already exists. At that point the consumer rechecks that the agent grant is still enabled and compares the observation’s payload digest and requested autonomy with those of the admitted request, so an observer cannot lower ${\ell }_q$ to make an excessive request pass the TAC gate. The observer’s own signature and scope are checked independently. An observation that arrives before its request is rejected and may be resent after admission, while observations for later visits are buffered. Disabling a key locally affects only subsequent acceptance and leaves committed history intact.

For a complete visit, the controller authorizes execution if and only if

$$\begin{array}{cc}\hfill {execute}_{e,v,i}⟺& \underset{\mathrm{principal}\mathrm{and}\mathrm{request}\mathrm{scope}}{\underbrace{admitted(Q_{e,v,i},G_A)}}\hfill \\ \hfill & \wedge \underset{\mathrm{assessment}\mathrm{provenance}\mathrm{and}\mathrm{binding}}{\underbrace{accepted(R_{e,v,i},G_O,Q_{e,v,i})}}\hfill \\ \hfill & \wedge \underset{\mathrm{behavioral}\mathrm{authority}\mathrm{and}\mathrm{current}\mathrm{checks}}{\underbrace{TACgate(L_v,{\ell }_q,R_{e,v,i})=\mathrm{execute}}}.\hfill \end{array}$$

(2)

The predicate is evaluated locally against the pre-visit ledger $L_v$, and the gate outcome is recorded in the same transaction that applies the visit; no transferable execution token is issued, and the executor interface assumes complete mediation. Figure 2 shows the message order. The request–observation exchange repeats for every role, and complete visits are applied in ascending order. Making the proposal available to the observer is handled by trusted fixture coordination rather than by an additional authenticated handshake. External effects lie outside the local at-most-once guarantee of the database.

3.4. Receipt Encoding and Acceptance

A signed receipt contains the schema and domain; issuer and key identifier; algorithm and key epoch; subject and decision class; evidence type and verifier version; episode, logical event identifier, visit and role; audience and policy digest; payload-binding mode and digest; and an observation. The observation has four fields: three Booleans (compliant, property veto, risk below threshold) and the requested autonomy, an integer in $\{0,1,2,3\}$. The issuer cannot set an authority level or an amount of negative evidence; both are computed by the controller.

Receipts use canonical ASCII JavaScript Object Notation (JSON) restricted to this schema, with sorted keys, fixed separators and no insignificant whitespace. Unknown fields, duplicate keys, floating-point and non-finite values, non-canonical encodings and incorrect types are rejected. Signed strings are printable ASCII of 1 to 256 characters; visits and key epochs are integers from 0 to 63; digests are 96-character lower-case hexadecimal SHA-384 values. The envelope contains exactly the receipt and its hexadecimal signature and may not exceed 20,000 bytes. This is a restricted profile, not a general JSON canonicalization scheme.

Payload bytes travel separately. The consumer hashes the payload it actually holds and compares the digest both with the signed value and with the expected proposal digest in the trusted plan. Because the hash covers the exact bytes, numeric fields in a recorded payload require no floating-point interpretation at the receipt level. Collision and second-preimage resistance of the digest, as well as payload availability, are further assumptions.

The signed message is the ASCII prefix TAC-Evidence-v1, a zero byte and the canonical receipt; with ML-DSA, the same string is also passed as the API context, whereas Ed25519 signs the prefixed message through its standard interface. No external message representative or prehash variant is used. Since the trusted grant pins the algorithm, an attacker cannot force a downgrade by editing an unsigned routing hint. Keys come from the backend’s cryptographic random generator, and ML-DSA signing uses the standard randomized interface.

Acceptance proceeds through bounded parsing, key lookup, signature verification, issuer authorization, episode and context checks and payload binding, all before persistence. A valid signature is therefore necessary but not sufficient: a known key may lack authorization for the subject, role or audience, a disabled key is rejected, and a signed event for another episode, policy, verifier version or action is refused. Invalid messages leave the ledger unchanged and are not counted as agent misconduct; transport anomalies can be logged separately from behavioral evidence.

3.5. Local Consumption and the Visit Frontier

Each observation has the logical identity $(\mathrm{episode},\mathrm{visit},\mathrm{role})$, and its signed event identifier is fixed to the corresponding string. Episodes are scoped to one consumer’s durable store and trusted plan. Algorithm, key epoch and signature bytes are excluded from this identity, so re-signing an observation, even after a key change, cannot reset its consumed status.

Verification runs outside the database transaction; the consumer then opens an immediate SQLite transaction in which unique constraints protect both the logical slot and the episode/event identifier. An identical repeated submission returns duplicate, and a different authenticated receipt for an occupied slot returns conflicting duplicate without overwriting the first. Insertion, application of complete visits, ledger changes, transition records and frontier advancement are committed together, with write-ahead logging and synchronous FULL. Concurrent writers are serialized by the database. Durability relies on documented storage behavior and does not cover arbitrary rollback or hostile modification.

Each episode starts at frontier zero, and valid events beyond the frontier are buffered. The consumer computes and commits an update only when all four expected roles of the current visit are present and then applies any further complete visits in ascending order. Within a visit, roles form a fixed set, so network arrival order does not affect the update. Partial delivery is never read as compliance, and there is no wall-clock timeout: a trusted close operation seals the episode, keeping committed history and leaving incomplete visits unapplied. This fail-safe choice can block progress, a problem the protocol does not solve.

3.6. Trust, Accountability and Control Semantics

For role i, let $r_i,s_i\ge 0$ be positive and negative evidence. With prior weight $W=2$ and base rate $a=1/2$, the opinion is

$$(b_i,d_i,u_i)={\displaystyle \frac{(r_i,s_i,W)}{r_i+s_i+W}},b_i+d_i+u_i=1.$$

(3)

The configured authority rule chooses the largest $\ell \in \{0,1,2,3\}$ satisfying $b_i\ge {\beta }_{\ell }$ and $u_i\le {\nu }_{\ell }$, with

$$\beta =(0,1/5,9/20,7/10),\nu =(1,4/5,1/2,1/4).$$

(4)

At a completed visit, $x_i$ records whether role i violated the frozen norms, $k={\sum }_i{x}_i$ and $F=\mathbf{1}[k>0]$. The tested TAC update is

$$r_i^{\prime }=r_i+(1-x_i),s_i^{\prime }=s_i+\left\{\begin{array}{cc}{x}_i/k,\hfill & k>0,\hfill \\ 0,\hfill & k=0.\hfill \end{array}\right.$$

(5)

Accountability thus places negative evidence on the roles that violated the norms. To verify that preservation does not depend on a single update rule, the consumer also supports three alternative configurations: static guardrails (B1), without adaptive evidence; outcome-updated control (B2), which adds F to every role; and a mass-normalized team rule, which adds $F/4$ to every role.

All four role decisions use the pre-visit ledger. A request above the ceiling is blocked, as is a proposal with a recorded norm violation or property veto; excessive residual risk leads to deferral, and the gate executes otherwise. A compliant proposal that is blocked still earns positive evidence, since proposed compliance and successful execution are different quantities. The ledger is updated once per visit, not at every receipt arrival.

Equations (3)–(5) imply a warm-up period. From an empty ledger with one compliant observation per visit, level ℓ first becomes admissible after

$$n_{\ell }=\max \left\{⌈{\displaystyle \frac{{\beta }_{\ell }W}{1-{\beta }_{\ell }}}⌉,⌈{\displaystyle \frac{W}{{\nu }_{\ell }}}-W⌉\right\}$$

(6)

visits, that is, after one, two and six visits for levels one, two and three. Authentication cannot shorten this period: a newly provisioned key creates a principal, not behavioral evidence.

3.7. Conditional Properties

Proposition 1 (Scoped request–observation composition).

Fix trusted agent/observer grants and an unchanged episode plan. If admitted requests are bound to their exact proposal bytes and accepted observations require the corresponding admitted request, every committed integrated visit has a scoped authenticated request and a matching scoped authenticated observation for each role, assuming signature unforgeability, digest binding and intact local storage.

Proof. 

Admission checks the pinned agent key, grant and expected role/visit context before inserting the unique request slot. Receipt acceptance checks the observer key and grant, requires that slot, rechecks the applicable agent grant and compares payload binding and requested autonomy. Complete-visit application requires all four accepted receipt slots. Consequently each applied role is linked to an admitted request and matching assessment. Unforgeability and intact trusted configuration make the identified origins conditional on honest keys. The argument does not establish that the assessment is true or the executor honors the result.    □

Proposition 2 (Local consumption).

Within an unchanged trusted episode plan and one durable consumer store, a logical role/visit event contributes to at most one committed visit update, assuming transaction isolation, unique-constraint enforcement and no rollback of committed storage.

Proof. 

An accepted event occupies one unique slot. A concurrent or subsequent attempt cannot create a second slot for the same logical identity. A visit is applied only at the current frontier, whose advance is committed with the consumed slots and ledger changes. If the transaction fails, none of those changes commit. If it commits, a later attempt observes either the occupied slot or the advanced frontier. Thus, it cannot apply that visit again. This argument concerns controller storage, not external action delivery.    □

Proposition 3 (Preservation).

Fix the initial ledger, trusted policy, configured update rule and complete ordered sequence of four-role observations and proposal contexts. If each observation is correctly authenticated and accepted once into its intended slot, the receipt consumer has the same ledger and gate transitions at each completed frontier as the unsigned controller on that sequence.

Proof. 

The initial ledgers coincide. Assume they coincide before visit v. Context binding fixes the same intended proposal, and the completed four-role set supplies the same observations. Both paths use the same pre-visit ledger and deterministic gate, then the same update function. Their transition records and next ledgers coincide. Induction gives the claim for every completed visit. Reordered delivery can only affect when a complete frontier becomes available under this implementation; it does not change the fixed role set or ascending visit sequence. Missing events may stop the induction at an earlier frontier.    □

Authenticity is inherited from the unforgeability of the chosen signature, under honest keys and trusted provisioning, and payload integrity also depends on the digest binding; these are assumptions, not conclusions drawn from the absence of test failures. The propositions are mathematical arguments about the declared state machine rather than a machine-checked proof of the implementation. Moreover, preservation on a fixed trace does not imply behavioral equivalence when a reactive agent adapts its future proposals to earlier outcomes or timing.

3.8. Symbolic Receipt Model

We model the receipt subprotocol in Tamarin, abstracting one four-role visit per episode with unboundedly many fresh episodes and keys, an adversarial network, perfect symbolic signatures and hashes, and linear facts for local consumption state. Trusted plans pin consumer, episode, subject, policy and payload digest, and grants pin the issuer key. Issuers may sign arbitrary reports, and a reveal rule models key compromise. Accepting a role consumes its unique slot, and applying a visit consumes the four accepted-role facts together with the frontier token. The model thus separates authenticated origin from truthful content.

Tamarin 1.12.0 with Maude 3.5.1 verifies six universal trace properties: authenticated origin unless the key was revealed earlier; existence of a prior scoped grant; binding to the trusted context and payload; at-most-once acceptance per role; acceptance of all four roles before a visit is applied; and at-most-once application of each visit. Two existential lemmas show that a complete visit is reachable and that an authorized false observation can be accepted, ruling out vacuous success. Thus, the model has eight lemmas in total: six universal properties and two existential witnesses, in addition to the three mutant analyses. Three mutants, lacking the signature check, the payload binding or the replay slot, falsify the corresponding property. All analyses complete without well-formedness warnings.

Table 2 maps the evidence and its boundaries. The model is a checked abstraction of the protocol, not a verification of the Python implementation or of concrete ML-DSA. It omits byte parsing, multi-visit arithmetic, crashes, disk rollback, provisioning changes and the agent-request admission step, which is therefore covered by the E5 tests rather than by a machine-checked proof. Supplementary Methods, Section S4, gives the signed tuple, modeled state and all lemmas and mutants.

Table 2. Verification coverage and the consequences of omitted components. The six universal properties and two existential witnesses concern the receipt abstraction, not the complete workflow.

Property Group	Evidence	Boundary or Consequence
Receipt origin, scope and context	Three universal Tamarin properties	Symbolic signatures/hashes; trusted plans and grants
Receipt/visit uniqueness and completeness	Three universal Tamarin properties	Linear state; no disk rollback or concrete crash semantics
Reachability and authorized false reports	Two existential Tamarin witnesses	Origin does not establish truthful assessment
Agent admission and request–receipt linkage	Conditional composition; E5 cases	Admission code and concrete parsing are not symbolically proved
Dispatch binding, current grant and sink retry	Proposition 4; E6 effects and mutants	Trusted mediation, local snapshot lock and transactional synthetic sink
Global delivery, compromised execution and truthful monitoring	Explicit assumptions and counterexamples	No consensus, operating-system (OS) isolation or semantic-truth guarantee

3.9. Implementation and Experiment Protocol

The prototype is written in Python 3.12 (3.12.14 on the local measurement host and 3.12.3 on the E6 Linux host) and uses cryptography 50.0.1 with its OpenSSL 4.0.2 backend through the documented message-signing interfaces [32]. ML-DSA-44 is the primary configuration, and ML-DSA-65 and ML-DSA-87 serve as cost comparisons; they correspond to NIST security categories 2, 3 and 5. Ed25519 is included as the classical baseline, without implying equivalent quantum security. Key and signature lengths are measured in the implementation. ML-DSA private keys are exported as 32-byte seeds rather than expanded Federal Information Processing Standards (FIPS) secret keys, and ephemeral test keys are not retained.

The backend supplies the signature primitive; no FIPS validation, side-channel resistance or independent implementation audit is claimed. A Request for Comments (RFC) 8032 Ed25519 vector [33] and cross-version OpenSSL signing/verification [34] check interfaces within one implementation family, not independent primitive validation. Supplementary Methods, Section S3, records further software-profile details.

The experimental protocol and batch counts were fixed before their respective main collections, and Table 3 lists E1–E7 with their inferential units. Repeated operations are nested within process batches and replayed visits and roles within recorded episodes. Protocol measurements exclude LLM inference and graphics processing unit (GPU) computation. OpenAI Codex assisted implementation and scripts for experiment automation, verification and plotting, and manuscript drafting and diagrams. Figure 1 combines ImageGen icons with controlled vector labels/arrows; the sequence is vector-based. Quantitative plots use Matplotlib 3.11.2 and the data from their specified experiments, with labels sized for the final display width. Plot labels ML-44, ML-65 and ML-87 abbreviate the corresponding ML-DSA parameter sets.

Table 3. Experimental design and inferential units.

ID	Operation	Unit and Coverage	Interpretation Boundary
E1	Signed replay of recorded controller stream	38,400 positions per path: 300 episodes, 8 visits, 4 roles, 4 controller configurations	Fixed-input replay; signatures generated in each signed path
E1b	Remote source/payload linkage	9600 source proposal positions; 2 signatures and 4 configurations	Complementary diagnostic binding panel; source projection and original logs supplied
E2	Acceptance and failure fixtures	115 controlled cases, including RFC vector	Implementation conformance within declared cases
E3	Stage and durable-path costs	3 pilot and 12 main fresh-process batches; 200 operations per stage; 50 key generations	Operations nested in batches; one CPU host
E4	TCP components	Two producers, two consumers; complete/partial schedules	Synthetic loopback integration; no consensus
E4b	Cross-host transfer	Two ARM producers, two x86 consumers; same four panels	Staged Secure Shell (SSH) batch; no wide area network (WAN) latency or independent administration
E5	Integrated agent protocol	176 specified cases on local and remote hosts; 6 remote batches, 1200 pairs per algorithm	Synthetic signed requests and reports; inference and executor effects excluded
E6	Execution binding and archived evidence	48 unbound/bound configurations, 8 mutants and 32 separate archive/deployment controls	Deterministic synthetic effects; trusted mediation; no attack-rate estimate
E7	History through resource effects	28 matched episodes, 24 isolated execution ablations and 2 history-mutant diagnostics; 12 visits per episode	Competent static baseline; separate arithmetic oracle; no general utility claim

E1 replays a fixed corpus of 300 LLM-agent episodes, 8 visits and 4 roles under the four controller configurations of Section 3.6: 9600 positions per configuration and 38,400 per path. It compares evidence before/after updates, increments, opinions, ceilings, decisions and reasons using exact rational arithmetic, with tolerance ${10}^{-12}$ only for recorded floating-point values. This measures fixed-input preservation, not agent performance. The remote E1b panel links proposals and transitions to complete source checkpoints, signing their exact payload bindings under both algorithms and all four configurations with a diagnostic envelope distinct from the production receipt.

E2 covers altered metadata and payloads; invalid or truncated signatures; wrong, unknown and unauthorized keys; algorithm confusion; context substitution; parsing limits; re-signing; conflicting and concurrent duplicates; key disabling and rotation; restart; transaction exceptions and a hard process exit after a ledger write, as well as out-of-order delivery, missing evidence and explicit closure. A false observation with a valid authorized signature serves as a negative control: it should be accepted, which exposes the semantic limit rather than a failure of authentication. Supplementary Methods, Section S5, groups all E2 and E5 cases by property.

E3 alternates five configurations on an Apple M1 Max host (Apple Inc., Cupertino, CA, USA; macOS 27.0.1, ten logical CPUs). Each independent process generates fresh keys and stores, warms up each stage with 20 operations and records elapsed and process CPU time. Public-key construction is timed separately, and primitive verification uses a cached public key. The deployed wheel reports an OpenSSL compiler string without an optimization flag, and this build is kept for the protocol measurements. Stage payloads consist of one recorded controller record and synthetic inputs of 256, 4096 and 16,384 bytes. The full path processes a matched synthetic 50-visit stream with identical SQLite durability for every configuration and, for signed paths, includes signing, authentication and persistence but not key generation. The unsigned path calls a private adapter for verified records that the network service does not expose. Lookup, duplicate handling and the TAC update are timed in isolation and are not additive components of the full-path latency.

E4 runs two producer processes, with different keys and disjoint role grants, and two consumer processes that hold only public keys and separate databases. They exchange length-framed TCP messages over loopback, with producer visits sent in reverse order. Each complete schedule delivers 8 visits and 32 distinct receipts per consumer, together with duplicate and changed-payload probes; in the partial schedule, one response receipt of visit one is withheld from consumer two only. A parent process orchestrates the four components. The channel between processes is real, whereas the loss is injected and all processes share one host.

E5 adds four separately keyed role agents and an independent observer to the synthetic stream. For Ed25519 and the three ML-DSA parameter sets, 176 specified cases test scope and context substitution, role and key separation, canonical parsing, request rollback, concurrent duplicates, restart, local disabling and preservation under reversed delivery. Costs are measured on the remote x86 host in six sequential fresh processes, each recording 200 pairs per algorithm after 20 warm-up pairs in a separate store, with algorithm order rotated and reversed. A timed pair comprises signing an agent request and an observer receipt, verifying both, admitting the request and consuming the receipt through two separate SQLite FULL commits; provisioning, process start, transport, inference and external execution are excluded. Raw samples were retrieved over the authorized SSH session, checked against the remote archive hash and re-aggregated independently.

3.10. Binding Decisions to Effects and Preserving Evidence

E6 tests whether an authenticated request and committed decision constrain a later resource effect. An attacker may replace the dispatch job, operation, resource or argument bytes or mutate the caller’s buffer at a check/use hook. The adapter, its private state, controller database, provisioning roots and sink remain trusted. A separate privileged control writes directly to the resource, outside complete mediation. The synthetic sink has two integer resources, initially ten; the intended command adds seven to the access resource. An effect is permitted only if it matches the admitted command and identity, has a committed execute decision and current enabled grant and is not repeated. This predicate does not establish semantic safety.

The unbound dispatcher (U) deliberately trusts a mutable job and omits sink deduplication; it is a failure comparator, not an executor attributed to E1–E5. The bound dispatcher (B) instead checks the original signed evidence, committed decision, current scope and SHA-384 command binding, then executes the same private parsed command. Its sink commits command, effect and consumed identity in one SQLite FULL transaction. The identity excludes signature bytes and key epoch. Signed grant installation and dispatch share a process-local lock; registry versions are not durable across restart, which requires a trusted latest snapshot. Neither global revocation nor OS isolation is implemented.

Proposition 4 (Bounded mediated effects).

Assume complete mediation through B, trusted adapter/controller/provisioning state, retention of the latest local grant snapshot, digest binding and durable isolated sink transactions. Every effect through B uses its archived admitted command, has a committed execute decision and applicable dispatch grant and occurs at most once per execution identity in that sink.

Proof. 

Archive, decision and grant checks precede use of the fixed parsed command; the registry lock prevents a managed snapshot change during dispatch. A unique identity commits with the effect, so retries cannot add another effect. This conditional implementation argument is not a Tamarin proof or an exactly-once guarantee for external devices.    □

The matched one-visit panel uses autonomy zero and fresh stores: 12 schedules under U/B and 2 algorithms yield 48 configurations, with 8 mutants and 32 separate archive/deployment controls. M1 jointly omits binding and immutable use; M2 omits current-grant checking. E7 isolates the first two measures. Fixtures and hashes were frozen before main collection, following separate development runs. Reused fixtures across isolated stores are not independent attack trials.

Original envelopes, payloads and signed provisioning are archived under separately supplied root pins. The offline verifier reuses authentication and controller functions to reconstruct the visit. Dispatch waits for durable archive publication and agreement with live state; database and filesystem do not share an atomic transaction. Archival establishes provenance, not truthful assessment, global completeness or external effect attestation. Supplementary Methods, Sections S1 and S3, give the schema, publication/recovery procedure, controls and reproduction commands.

3.11. Authenticated History Through Resource Effects

E7 compares static guardrails (S) with adaptive TAC (T) through actual effects over twelve visits. Both use the same authenticated admission, completion frontier, current grants, command binding, immutable use and transactional deduplication. S is a local mechanism baseline, not an implementation of Progent or CaMeL. All four roles request autonomy three and normally propose adding seven to their own resource, initially ten. An illustrative task predicate independently limits additions to ten; its truth is distinguished from signed compliance and controller permission. Evidence concerns assessed proposals, including blocked ones, rather than successful executed work.

Seven histories cover conformity; a truthfully reported access violation at visit three; a false authorized report for add 99 at visit nine; risk deferral and property veto; delayed receipt recovery; reverse delivery; and exact/re-signed duplicates. Crossing both policies and algorithms gives 28 main episodes. A further 24 episodes isolate omission of binding (MB) or immutable use (MI) under pre-check and post-check mutation at visit seven. Two diagnostic T episodes inject erroneous reinforcement of repeated evidence while keeping archive reconstruction enabled. Text visits are numbered from one; stored visits from zero. All episodes use fresh stores and fixed inputs, not reactive agents or independent attack trials.

Signed-prefix reconstruction uses the protocol controller. A separate rational-arithmetic implementation checks six trajectory fields against retained SQLite records; fixture definitions and cryptographic authentication remain shared. Every successful effect is retried with an equivalent fresh buffer. Source/input freezes precede main collection, and independent task-predicate checks concern only the stated illustrative limit. Supplementary Methods, Sections S2 and S3, specify schedules, archive reconstruction, diagnostics and reproduction. E7 adds no latency campaign or general task-utility comparison.

4. Results

4.1. Authenticated Agent Admission and Action Binding

All 176 integrated E5 cases met their expected outcomes on both the local and the remote host; they are the same 44 cases per algorithm run twice, not 352 independent attacks. An observer report that precedes its agent request is rejected. Re-signed substitutions of agent, role, operation, resource, episode, policy, audience and other context fields fail the corresponding checks, and an observer key cannot impersonate the expected agent. Admitting a request leaves the TAC ledger unchanged.

An interrupted admission rolls back completely. When the same request is submitted 24 times concurrently, 1 submission is admitted and 23 are reported as duplicates, and neither re-signing, restart nor key rotation clears the slot. Disabling an agent’s key after admission prevents subsequent observations from entering through that scope, and an observer report with a lower requested autonomy than the admitted request is rejected instead of silently relaxing the authorization condition. Under reversed delivery, the consumer reproduces the reference controller’s state and decisions. In the eight-visit fixture in which every agent complies and requests level three, 24 requests are blocked during the first six visits and 8 execute in the last two: cryptographic admission does not bypass adaptive warm-up. These cases exercise the full composition, whereas the Tamarin model covers only the receipt subprotocol.

4.2. Preservation and Controlled Security Cases

E1 produced 38,400 matching controller positions in each of the unsigned, Ed25519 and ML-DSA-44 paths, with no field mismatch in any of the four configurations, and the transition digest is identical across paths. As Proposition 3 predicts, authentication leaves the controller semantics unchanged on this stream.

The remote panel checked 9600 source proposal positions and verified 76,800 signed payload/record links (2 algorithms, 4 configurations, 9600 positions). The hash of the compact corpus matches the locally replayed one, and the source checkpoints are unchanged after the panel. The verified links cover the recorded gate decision and reason, compliance observation, requested autonomy, risk-threshold predicate and post-visit evidence. The accompanying archive supplies the original binding rows, input manifest, recorded corpus and the exact source-record projection used by the portable runner. The projection retains proposal/candidate objects and every field read by the panel; its manifest links them to the original checkpoints. A read-only remote audit rechecked all 1200 checkpoint hashes and reproduced the 300-record projection exactly.

All 115 E2 cases met their expected outcomes; the count includes the Ed25519 test vector and scheme-specific cases and does not represent 115 independent attacks. No invalid receipt modified the ledger. Of 24 concurrent submissions of one receipt, 1 was stored and 23 were reported as duplicates; after a hard process exit before commit, a retry produced exactly one update; and neither re-signing nor restart reset the logical identity. A validly signed false observation was accepted and buffered as intended, confirming that provenance does not establish truth.

Cross-version interoperability tests passed in both directions for Ed25519 and all three ML-DSA parameter sets. Since library and command-line tool share the OpenSSL code base, these tests imply neither certification, nor exhaustive vector coverage, nor side-channel analysis.

4.3. Cryptographic and Durable-Path Costs

Table 4 reports full-path latency (CV denotes coefficient of variation), Table 5 representation and store sizes, and Figure 3 batch medians, pooled quantiles and encoded receipt sizes. Each E3 configuration comprises 12 fresh-process batches and 2400 nested receipts, measured with the deployed cryptography 50.0.1/OpenSSL 4.0.2 wheel. Signed paths include signing and verification but not key generation.

Table 4. Durable receipt-path latency.

Configuration	p50 (μs)	p95 (μs)	p99 (μs)	Median CV	Receipts/s
unsigned	352.0	807.6	1718.1	0.203	2483.8
Ed25519	796.2	1258.6	1689.9	0.098	1160.2
ML-DSA-44	3959.0	9488.8	12517.7	0.077	210.8
ML-DSA-65	5950.4	15989.8	23199.7	0.061	138.6
ML-DSA-87	7164.6	17742.2	24848.4	0.029	116.9

Table 5. Key, signature, envelope and store sizes.

Configuration	Public Key (B)	Signature (B)	Envelope (B)	Store (B)
unsigned	0	0	749	331776
Ed25519	32	64	892	331776
ML-DSA-44	1312	2420	5606	331776
ML-DSA-65	1952	3309	7384	331776
ML-DSA-87	2592	4627	10020	331776

Figure 3. Receipt-path latency and envelope size. (a) Latency; (b) encoded size.

In the figure, gray points are batch medians and larger markers pooled operation quantiles, not confidence bounds, on a logarithmic time axis. Wire sizes exclude the separately carried payload and the TCP frame; every checkpointed store holds 200 receipt slots and 200 transition records. The unsigned body carries no signature but persists in the same way.

Quantiles pool nested samples descriptively, whereas the coefficient of variation in the table is computed across batch medians, so that repeated calls within one process are not treated as independent replications. Batches ran one at a time on an interactive host, with load recorded but no CPU isolation. Process start, provisioning, source retrieval, transport, network round trips, LLM inference and executor effects lie outside the measured path, and the timings are specific to this build. The unsigned path uses the same persistence configuration and omits authentication; its latency difference does not isolate individual costs.

The ML-DSA envelopes are larger than the signatures because the reference encoding is hexadecimal; a binary transport would reduce this overhead without changing the signed bytes, but was not measured. The full path also includes parsing and transaction work, so isolated primitive timings should not be read as application throughput. In the absence of an application deadline, these measurements support comparison and capacity planning on this host, not claims of negligible overhead or real-time suitability.

Figure 4 examines why ML-DSA verification appears slower than Ed25519 verification in this wheel. Through Python, with cached public keys and identical 1040-byte messages, median verification takes 199.4 μs for Ed25519 and 583.5 μs for ML-DSA-44, while public-key construction costs only 2.3 and 7.7 μs, with similar elapsed and CPU times. We therefore built a native reference in which the C caller, OpenSSL 4.0.2 source, message, context and key lifecycle are fixed and only the library optimization level changes between -O0 and -O3. Across three fresh processes per build (900 calls per plotted median), median verification drops from 202.0 to 83.0 μs for Ed25519, from 581.0 to 71.0 μs for ML-DSA-44, and from 843.0/1245.0 to 110.5/171.0 μs for ML-DSA-65/87. The unoptimized build closely reproduces the wheel’s profile, whereas the optimized build reverses the order of Ed25519 and ML-DSA-44 verification. This controlled native comparison demonstrates build sensitivity; it does not establish the wheel’s undocumented compiler options or isolate every cause of wheel/native differences.

Figure 4. OpenSSL 4.0.2 build dependence. (a) Cached-key verification; (b) signing.

The E3 campaign nevertheless keeps the deployed wheel, so that its results describe the implemented Python/SQLite 3.45.1 path rather than optimized native costs. Command-line speed tests with OpenSSL 3.6.3 and with the optimized 4.0.2 build confirm the faster reference, although they report aggregate rates under different API lifecycles. Signing tails remain wide in both native builds; given ML-DSA’s rejection sampling, a high p95/p50 ratio is not by itself evidence of a timing defect [1]. Optimized OpenSSL/Open Quantum Safe (OQS) measurements in the literature [21] use other platforms and providers, so our controls demonstrate a possible ranking reversal without replicating those figures.

4.4. Complete Agent Request–Observation Costs

Table 6 summarizes paired-path timings and envelope sizes. Each algorithm has six fresh-process batches and 1200 nested signed pairs, each comprising two signatures, two verifications and two FULL commits. Quantiles pool operations, the range spans the six batch medians, and envelope sizes exclude payloads and framing.

Table 6. Signed request–observation latency and envelope size.

Algorithm	p50 (ms)	p95 (ms)	Batch-Median Range (ms)	Pair Wire (B)
Ed25519	2.192	3.032	2.154–2.249	1625
ML-DSA-44	3.406	4.955	3.375–3.467	11053
ML-DSA-65	4.243	6.641	4.174–4.349	14609
ML-DSA-87	4.827	7.158	4.723–4.914	19881

Figure 5 shows the complete E5 path on an Intel Xeon w9-3595X host (Intel Corporation, Santa Clara, CA, USA) with 120 logical CPUs, Linux 6.8.12, Python 3.12.3 and cryptography 50.0.1/OpenSSL 4.0.2. Its retained batch metadata omit compiler flags; the current remote build string cannot establish the historical build setting. Gray points mark batch medians and colored markers pooled p50/p95, and stacked bars split the envelope size between request and observation. The six batches ran sequentially without CPU affinity or frequency control, and only a post-campaign load snapshot was recorded. Host and workload differ from E3, and historical E5 compiler flags are unavailable; the two campaigns cannot be compared causally.

Figure 5. Signed request–observation costs. (a) Paired-path latency; (b) envelope sizes.

The pooled p50/p95 of a signed pair is 2.192/3.032 ms with Ed25519 and 3.406/4.955 ms with ML-DSA-44; ML-DSA-65 and ML-DSA-87 reach medians of 4.243 and 4.827 ms. The six batch medians of ML-DSA-44 range from 3.375 to 3.467 ms. Its two envelopes total 11,053 bytes, compared with 1625 bytes for Ed25519, excluding payloads and framing. Relative to Ed25519, ML-DSA-44 thus has a median about 1.2 ms higher per signed pair on this host. The full-path difference does not isolate signature, parsing or commit costs. These figures describe a synthetic admission/assessment pair, not end-to-end task latency, and establish neither production throughput, nor deadline guarantees, nor the superiority of one signature family on other hardware.

4.5. Separate Producers and Consumers

Figure 6 reports receipt counts and applied frontiers for E4, where Ed and ML denote Ed25519 and ML-DSA-44. All four configurations ended in the expected states. With complete delivery, both consumers reached frontier eight with identical ledgers and decisions and 32 distinct stored receipts. In the partial schedule, consumer one reached frontier eight, whereas consumer two stopped at frontier one: it held 31 receipts but could not apply the incomplete visit and did not infer compliance from the missing one. All 16 changed-payload probes, 4 per configuration, were rejected without ledger changes, and duplicate probes did not increase the receipt count.

Figure 6. Receipt delivery and consumption. (a) Stored receipts; (b) applied frontier.

The divergence stems from different local evidence sets, not from a signature failure. Signatures let each consumer verify issuers locally, but they neither synchronize delivery nor produce agreement on a complete history. Receive order varied across runs, yet the ascending frontier yielded identical states whenever both consumers eventually held the same complete role sets.

E4b repeats the exchange across hardware. Two ARM producer processes sign the synthetic batch, which is transferred over an existing authenticated SSH session to two x86 consumer processes with independent stores; producer private keys never leave the ARM host. All four Ed25519/ML-DSA-44 panels, complete and partial, pass: complete consumers agree at frontier eight with 32 receipts, and partial delivery leaves consumer two at frontier one with 31 receipts. Each consumer rejects two changed-payload probes and recognizes two duplicates, and the received bundle hash matches the transmitted one. The accompanying archive includes all eight original receiver event logs and their original summary; these permit direct reaggregation rather than reliance on the earlier transcribed readout. E4b thus tests cross-host acceptance under staged transfer, not live WAN behavior, latency or independent administration.

4.6. Decision Limits That Authentication Does Not Remove

Three results show what authenticated evidence cannot change. The E2 negative control and the corresponding Tamarin witness show that a false report validly signed by an authorized observer is accepted. E4 shows that consumers with different evidence sets reach different frontiers without any signature failure. Finally, E5 shows that authentication interacts with, but does not replace, the adaptive warm-up of Equation (6).

Figure 7 expands the E5 warm-up case into per-visit decisions computed directly by the consumer’s controller (Equations (3)–(5)); it isolates controller semantics and is not a further signed-message experiment. Panel (a) shows the pre-visit ceiling of the access agent and panel (b) the cumulative execution decisions in the four-role, eight-visit fixture, in which every agent requests level three at every visit. Under static guardrails, all 32 compliant requests execute. Under TAC, the ceiling first reaches level three at visit seven, so 24 authenticated, compliant requests are blocked and 8 execute, the count verified by the E5 conformance case on both hosts. A newly provisioned agent with a valid key therefore starts without behavioral authority.

Figure 7. Adaptive authority and execution decisions. (a) Access-agent ceiling; (b) cumulative decisions.

The same fixture makes the semantic limit concrete. Suppose the access agent proposes a norm-violating action at visit three. With an honest report, accountability assigns it negative evidence: its ceiling drops to one, never reaches level three within the episode, and the controller authorizes six actions in total. If an authorized observer instead signs a false compliance report, the consumer receives a valid, correctly bound and once-consumed receipt; the controller then follows the all-compliant trajectory, and the agent obtains two additional level-three execution decisions. Since the controller cannot tell this input from a genuinely compliant history, the signature can only attribute the report to its observer, which supports later accountability but cannot prevent the gain in authority.

These results establish local provenance, context binding and once-consumed ordered evidence under the stated assumptions. E7 measures adaptive selectivity and progress cost, without establishing general superiority; observer truth remains outside authentication.

4.7. From Authenticated Requests to Executed Effects

E6 meets the specified outcomes in 48 U/B configurations, 8 mutants and 32 separate archive/deployment controls. Offline checks authenticate original envelopes and reconstruct effects from controller/sink databases. Table 7 reports identical application outcomes for both algorithms without implying equal cryptographic strength.

Table 7. E6 effects per signature algorithm: U is the unbound comparator and B the bound dispatcher. Each row represents one U and one B configuration; there are 24 main configurations per algorithm. Values describe the target resource unless the other resource is named. Initial values are both 10; one permitted addition yields 17. Counts concern actual committed sink effects.

ID	Intervention After Admission	U Result	B Result
01	Honest dispatch	17; one effect	17; one effect
02	Replace argument 7 by 99	109; one effect	Refused; no effect
03	Replace addition by assignment	7; one effect	Refused; no effect
04	Replace resource	Other becomes 17	Refused; no effect
05	Duplicate argument field	109; one effect	Refused; no effect
06	Overwrite blocked decision	17 despite block	Refused; no effect
07	Borrow another role’s decision	17 despite block	Refused; no effect
08	Repeat execution identity	24; two effects	17; retry duplicate
09	Revoke grant before dispatch	17 despite revocation	Refused; no effect
10	Mutate buffer at check/use hook	109; one effect	17 from frozen command
11	Process exit after commit; retry	24; two effects	17; retry duplicate
12	Privileged direct sink bypass	999; bypass effect	999; bypass effect

Across both algorithms, U produces unpermitted effects in 20 of 22 mediated configurations; B produces none, and both honest B controls progress. B executes the original seven after the buffer mutation and commits one effect under replay or post-commit process exit/retry. Both privileged bypasses succeed. These fixed-case counts are not general attack rates.

M1 jointly omits binding and immutable use and produces all four substituted effects; M2 permits both revoked effects while honest controls progress. The archive controls reject altered/missing evidence and forged decisions. Pending publication prevents dispatch until recovery; late-role delivery restores a complete visit. Buffered evidence may enter a later decision after revocation, but current-grant checking refuses the effect. An authorized false assessment remains provenance-valid. Supplementary Methods, Section S1, details the controls; E3/E5 costs exclude this archive and dispatcher.

4.8. History Preservation, Selectivity and Execution Ablations

Table 8 reports the main outcomes. The 28 main episodes, 24 execution ablations and 2 history diagnostics meet their specified outcomes. Verification accepts 568 prefixes and rejects 24 with injected history corruption, reaggregating 1850 effects. Outside the diagnostics, recorded trajectory fields match the separate arithmetic implementation. Both algorithms give the same application outcomes.

Table 8. E7 main outcomes per algorithm: S denotes static guardrails and T adaptive TAC. Each policy/history pair is one twelve-visit, four-role episode. Effects are committed resource additions, not just execute decisions. Task violations concern the independently stated addition limit; they do not classify all TAC-blocked actions as unsafe.

History	S Effects	T Effects	S Task Violations	T Task Violations
Conformity	48	24	0	0
Early access violation, truthful report	47	22	0	0
Late authorized false report	48	24	1	1
Risk deferral and property veto	46	22	0	0
Delayed receipt and recovery	48	24	0	0
Reverse visit delivery	48	24	0	0
Exact and re-signed duplicate delivery	48	24	0	0

S completes 48 conforming additions; T completes 24 during visits 7–12, withholding 24 compliant proposals during warm-up. A truthful access violation at visit three delays that role’s first effect to visit nine; other roles still first execute at visit seven (Figure 8). This measures selectivity and progress cost, not general safety/utility superiority. Both policies respect defer/veto inputs and execute the late add 99 under a false authorized report.

Figure 8. E7 actual effects under conformity and a truthfully reported early access violation. (Left): access-role pre-visit ceiling under T; S permits level three throughout. (Right): cumulative committed additions across all four resources. Steps are reconstructed from retained controller and sink snapshots, with visits numbered from one. The curves coincide across the two algorithms.

Delayed, reverse and duplicate delivery recover the conforming trajectory and effect counts; missing-receipt attempts remain effect-free. All successful-effect retries return duplicate without another mutation. This establishes the specified finite recovery behavior, not timely delivery or consensus.

Table 9 separates binding from immutable use. Both protected policies resist the tested substitutions; each omission exposes only its corresponding mutation location. These are shared execution requirements, not an advantage unique to TAC.

Table 9. Isolated E7 execution ablations. Each cell reports the targeted access effect; every row is tested under S and T with both algorithms (24 episodes). Other common enforcement checks remain enabled.

Intervention	B: Protected	MB: No Binding	MI: Mutable Use
Replace 7 by 99 before check	Refused	Add 99	Refused
Mutate 7 to 99 after check	Add original 7	Add original 7	Add 99

In the two diagnostics, injected duplicate reinforcement makes the live gate permit level three at visit two. Prefix reconstruction detects the ledger mismatch and prevents every effect. This tests one consumer defect with the archive checker intact, not simultaneous corruption of consumer, adapter and verifier. E7 links conditional history preservation to actual effects without establishing general task-performance superiority.

5. Discussion

5.1. Answers to the Research Questions

RQ1: authentication composes with admission and behavioral authorization. Agent grants bound requests; observer grants and signatures establish assessment eligibility and context; TAC applies prior evidence and current checks. E5 tests these distinct boundaries. E6 binds committed permission to an actual effect under trusted mediation. E7 follows twelve-visit histories to effects under shared static/adaptive execution protection, with role-specific selectivity, progress costs and a duplicate-history diagnostic. The contribution is this evaluated composition; command binding, complete mediation, idempotency and signatures are established techniques.

RQ2: preservation requires the same complete, bound inputs and intact durable state. Replay reproduces 38,400 controller positions per path in four configurations; signed request fixtures provide further implementation evidence. Transactional uniqueness and the ascending frontier prevent repeated local contributions under the storage assumptions. Tamarin checks six universal receipt properties, with three mutants, but does not verify admission code or reactive-agent behavior. E4 shows how missing evidence can halt one consumer without corrupting another.

RQ3: costs describe specific workloads and builds. E3 measures the deployed macOS wheel and separately compares native primitive callers against controlled OpenSSL -O0/-O3 builds. That native comparison does not reoptimize or rerun the complete protocol path. E5 independently measures the request–observation path on x86: its historical metadata identify Python, cryptography and OpenSSL but do not record compiler flags, so no optimization setting is assigned retrospectively. The paired medians differ by 1.214 ms and the two encoded envelopes by 9428 bytes for ML-DSA-44 versus Ed25519.

For practical interpretation, an assumed rate of 100 pairs per second would carry approximately 1.105 MB/s of ML-DSA-44 envelopes versus 0.163 MB/s of Ed25519 envelopes, before payloads and framing; at ten pairs per second, these figures are ten times smaller. These are arithmetic traffic scenarios, not measured sustainable throughput or deadline guarantees. The database and transport workload, confidentiality and retention policy determine the acceptable budget. E6’s additional archive and dispatch checks were not timed in E3/E5 and must not be absorbed into those historical numbers.

RQ4: authenticated decisions inherit the limits of their evidence and controller. A false report from an authorized observer is accepted, because a signature establishes provenance, not truth; in the E5 fixture, such a report lets an agent that proposed a violating action reach a level that an honest report would have withheld. Authentication also leaves adaptive warm-up intact, with 24 of 32 compliant, correctly signed requests blocked before the ceiling reaches the requested level. Signatures make every report attributable to its observer and thus support accountability of observers, but the value of adaptive authority and the reliability of monitors remain properties of the controller and its inputs.

5.2. Operational Safeguards and Evidence Lifecycle

Observers. Narrow subject/role grants, administrative separation from assessed agents, inconsistency monitoring and scope suspension can reduce exposure. Retained evidence supports investigation but not truthful assessment or personal attribution after key compromise. Corroboration, quorums and human escalation are deployment options, not implemented guarantees.

Delivery. Missing-slot tracking and retry preserve logical identities; the frontier waits for all roles, and trusted closure leaves incomplete visits unapplied. Timeouts and reconciliation across independent consumers require additional mechanisms. Local signatures and archives provide neither consensus nor availability.

Grants. Buffered evidence is not revalidated at visit application. An observation accepted before revocation can therefore enter a decision, while B’s current-grant check refuses its effect. Versions and locks are process-local; restart requires a trusted latest snapshot. Deployments must define the effective authorization stage. Closing an affected episode and provisioning another preserves the frozen-plan boundary; erasing consumed identities does not.

Retention. Original envelopes, payloads and provisioning context need access and retention policies, including confidentiality in storage/transfer. The archive does not encrypt evidence or resist administrator deletion. Its costs are separate from receipt-database measurements. Supplementary Methods, Section S6, expands these operational distinctions.

5.3. Relationship to an Agentic Execution Architecture

A prospective radio integration would bind each agent request to a named instrument operation and exact structured arguments under a restricted grant. AICEBERG’s independent safety component could assess whitelist, parameter limits and device status; TAC would combine that bound report with the pre-visit ledger. E6 implements only a typed SQLite adapter, with no MCP adapter, SCPI executor or physical instrument. Validation of a command, permission to request it, evidence-derived authority and faithful execution remain separate responsibilities. Neither AICEBERG’s physical results nor PQ-FLCom’s convergence results provide numerical benchmarks here; comparison requires common tasks, monitors, failures and effects.

5.4. Limitations and Deployment Boundaries

Verification and stores are local, but grants and episode plans are provisioned centrally, and the prototype provides no consensus, transparency service, discovery, global revocation or trusted time. Disabling a key locally governs future acceptance without rewriting committed observations or informing other consumers. Episode identifiers must remain unique for as long as their consumed state exists, since deleting or rolling back a store invalidates replay protection; the single-visit symbolic model does not cover these provisioning and storage changes. The ARM-to-x86 transfer adds a second host within the same administrative domain but provides no estimate of WAN latency or fault distributions.

The original at-most-once guarantee covers the evidence ledger. E6 adds transactionally deduplicated effects only for its own SQLite sink; recovery for arbitrary external services still requires executor-specific idempotency or coordination. The original receipt table lacks observer signatures and payloads, although request signatures are retained in the separate request table. E6 preserves its own new original envelopes and payloads, without reconstructing discarded historical signatures or retroactively completing E1–E5 archives. Its archival costs are excluded from E3/E5 measurements. The private unsigned adapter and the crash hooks are trusted experimental interfaces; network ingress exposes only authenticated acceptance.

The current design is bounded to 64 visits per episode, envelopes of 20,000 bytes and proposals bound in advance. Proposal ingress, plan admission, denial-of-service controls and confidential transport require further integration, and the TCP service is an experimental harness. Privacy, deployment across independent organizations, resistance to state rollback and human oversight were not evaluated.

The resulting authorization is locally verifiable under centrally provisioned trust. Independent administration would additionally require governance of trust stores, proposal ingress, evidence quality and plan/grant changes; signatures alone do not supply those mechanisms.

6. Conclusions

The protocol composes authenticated agent requests and observer reports with scoped admission, persistent evidence consumption and adaptive authorization under provisioned trust. Replay, controlled failures, conditional arguments and eight symbolic receipt lemmas support distinct boundaries. E6 links committed decisions to synthetic effects through command binding, immutable use, current-grant checks and sink deduplication. Privileged bypass and false authorized reports remain effective. E7 follows twelve-visit histories through competent static/adaptive enforcement, separates execution ablations and detects duplicate reinforcement before effects. Warm-up withholds compliant proposals and has a progress cost. These results support bounded composition, not a new primitive, full-workflow proof or general safety/utility advantage. Historical timings retain their workload/build scope; native primitive optimization is distinct from protocol timing. Truthful observation, complete mediation, provisioning and durable storage remain deployment responsibilities.