ZeroGate: Trust-Preserving Fast Paths for Governed AI Agent Runtimes

Executive Summary and Reading Guide

• ZeroGate checks a short-lived, exact-action, single-use ActionPass against the reconstructed outgoing request before recording admission and consuming its nonce.A local transaction couples nonce consumption, applicable quota updates, and the admission receipt.Source: Executive Summary and Reading Guide · p. 2
• A pass is useful only when the final action is known early enough and its approval remains valid; changed payloads require new approval.Preparation may add visible delay when a task needs immediate execution.Source: Executive Summary and Reading Guide · p. 2, §1 · p. 7
• Prepared execution has a shorter final authorization boundary, but its mean complete lifecycle is longer because preparation and batch wait remain.The study distinguishes boundary latency from lifecycle latency, which includes preparation, waiting, and the external operation.Source: Executive Summary and Reading Guide · p. 3

1 Introduction

• A familiar tool permission does not approve every request sent through it, and cached approval cannot replace checking the action and relevant facts at admission.Recipient, budget, expiry, or request-body changes can make an earlier approval inapplicable.Source: Executive Summary and Reading Guide · p. 2, §1 · p. 7
• Decision preservation is conditional on sound approval, represented and current policy dependencies, faithful observations, and atomic consumption.A matching local digest alone may be stale, and a durable receipt does not prove that an external effect occurred.Source: §1 · p. 7
• The contribution is an engineering composition and measurement study, not a claim that local authorization or request binding is new.The report compares identical authorization work placed at different times and distinguishes boundary from complete-lifecycle latency.Source: §1 · pp. 7–8

2.1 Contributions of the transit sources

• The transit analogy motivates separating preparation from a brief local interaction, but transfers neither protocol equivalence nor performance or safety guarantees.FeliCa and Suica features inform the design discussion; they are not agent-runtime evidence.Source: §2.1 · pp. 8–9, Figure 1 · p. 9

2.2 From inspiration to engineering obligations

• The design obligations are to prepare only known work, retain required evidence at admission, and define interruption at the actual transaction boundary.Nonce consumption, applicable quota usage, and the admission receipt share one local transaction; external execution follows separately.Source: §2.2 · pp. 9–10

3 System Composition

• CAVA represents the concrete action, PCAA frames authority, and ActionPass carries signed approval; ZeroGate checks it against the outgoing request before dispatch.These are interface responsibilities, not evidence that every component was exercised together.Source: §3 · p. 10, Figure 2 · p. 11

3.1 Requested, granted, and residual authority

• At admission, eligible actions are restricted to the granted scope and the exact action bound into the pass; successful consumption leaves no residual action.Eligibility remains relative to available evidence and does not guarantee against unobserved external change.Source: §3.1 · p. 11

3.2 Concrete interface contracts

• The adapter reconstructs a normalized action from the outgoing request, while the issuer binds authority and evidence conditions into a signed pass.The reference issuer is a deterministic fixture, not the complete PCAA route–review–proof workflow; normalization is not a semantic oracle.Source: §3.2 · p. 12

3.3 Illustrative cross-runtime translations

• Tool-call and SDK projections of the same write may have different fingerprints, so each needs approval for its own concrete representation.A changed object name or body requires a new exact-action decision.Source: §3.3 · p. 12
• The composition assigns distinct responsibilities to skill authors, authorizers, adapters, the gate, and evidence systems, making implementation boundaries inspectable.These contracts support acceptance criteria without requiring a shared transport or storage implementation.Source: §3.2 · p. 11, §3.3 · p. 13

Capabilities and contextual attenuation

• Exact-request restriction is established; ZeroGate instead uses a trusted issuer, a concrete single-use pass, adapter reconstruction, and local transactional consumption.Unlike broadly delegated reusable credentials, it pays minting and persistence costs for each distinct approved action and does not implement a general attenuation language.Source: §4 · p. 13

Proof-carrying authorization and local policy engines

• Avoiding a remote policy call is not unique to passes; embedded policy engines can evaluate at the boundary when facts are locally available.The relevant comparison is where policy work, evidence acquisition, and state coordination occur; the embedded fixture baseline is not an OPA or Cedar benchmark.Source: §4 · p. 13

Leases, revocation, and freshness

• A pass expiry or epoch check alone does not establish freshness: an isolated verifier must accept possible staleness, reject while disconnected, or rely on a justified lease or communication bound.Offline immediate revocation is not claimed.Source: §4 · pp. 13–14

Durability, duplicate suppression, and external effects

• Atomic nonce consumption and receipt recording prevent a second local admission, but cannot atomically commit an external Azure operation.The receipt is an admission record, not automatically a durable delivery queue; external workflows may still need retry and receiver-side idempotence.Source: §4 · p. 14

Positioning

• ZeroGate specializes established techniques around a canonical agent-action boundary, without claiming to be first or to dominate existing authorization systems.Its distinctive focus is the connection among an earlier exact-action decision, its supporting dependencies, one local consumption domain, and measured dispatch versus lifecycle cost.Source: §4 · p. 14

5.1 Objects, actors, and phases

• The issuer approves and signs, the adapter observes the boundary action, the gate checks and updates local consumption, and the effect service attempts the external request.In the reference study, the adapter and gate run in the trusted client; Figure 3 depicts logical responsibilities, not separate failure domains or mandatory separate hosts.Source: §5.1 · p. 14, Figure 3 · p. 15
• The studied cloud pass binds a specific Azure Blob write, including object identity, payload SHA-256 commitment, and byte length, with a unit budget and no reuse across writes.The deterministic fixture policy checks fixed holder and workspace, allowed destination and operation, and payload bounds; it is not a human review process.Source: §5.1 · p. 14

5.2 Observation and identity boundaries

• The adapter recomputes the final payload hash and length and reconstructs the action; the action and payload must remain immutable through dispatch to avoid a later substitution.Holder and session equality checks are adapter assertions, not presenter authentication; the issuer signature authenticates the pass issuer, not holder key possession.Source: §5.2 · p. 15
• The effect service checks a caller-supplied receipt binding, not independent proof of gate persistence, so this is a trusted-runner boundary rather than a secure public endpoint for arbitrary actors.A bearer-credential holder could synthesize the checked fields; complete mediation remains an obligation of the trusted runner and deployment.Source: §5.2 · p. 15

5.3 Freshness and consumption domains

• The gate reads policy, state, and revocation snapshots inside admission, but the service and gate snapshots can diverge because no automatic coherence or revocation distribution protocol is implemented.The initial state digest reflects backend configuration, not current Azure contents or arbitrary resource authorization state.Source: §5.3 · pp. 15–16
• Replay protection is limited to one persistent gate database: separate databases, including regional copies, are separate consumption domains.SQLite WAL requires cooperating processes on the same host and allows one writer at a time; no global replay property follows from this implementation.Source: §5.3 · p. 16

Decision and dependencies

• The comparison uses an independently defined synchronous decision over the action, policy-relevant world state, and local consumption state, with approval and remaining admission conditions represented separately.K captures the approval fact; V covers remaining conditions such as identity, validity, unusedness, budget, and receipt obligations.Source: §6 · p. 16

Assumptions

• Preservation requires complete policy dependencies and a meaningful factorization: omitted relevant changes invalidate the claim, and a policy digest alone does not establish it.The checked dependency value must be authoritative and current or backed by a justified stability promise; unchanged stale local data is insufficient.Source: §6 · pp. 16–17
• The remaining conditions include authentic signed binding, faithful reconstruction and mediation, trusted clocks and observation sources, and failure-closed handling of missing evidence.A valid signature alone does not establish issuer policy correctness.Source: §6 · p. 17
• Atomic durable admission requires unusedness and budget checks, consumption, and the bound receipt to form one linearizable transaction whose committed state survives recovery.Successful admission is released only after commit, assuming the host does not roll back or edit state outside the protocol.Source: §6 · p. 17

Proposition and scope

• Under A1–A6, successful admission implies that the independently specified synchronous policy would execute the same eligible action at the admission instant.This is a safety implication, not a converse; the synchronous policy may allow actions the gate conservatively refuses.Source: §6 · pp. 17–18
• Within one consumption domain, at most one admission succeeds for a pass key, with a durably bound receipt recorded before trusted dispatch.Nonce and applicable quota consumption, receipt recording, and durable commit precede release to the dispatcher; this does not determine the external call’s outcome.Source: §6 · pp. 17–18

Implementation boundary

• The implementation guarantees consistency only relative to its persisted snapshot; semantic fixtures supply observations but do not establish an external coherence protocol.Lifting snapshot-relative checks to current synchronous authorization requires the missing freshness premise.Source: §6 · p. 18

Temporal and deployment limits

• The guarantee fails when relevant state is stale or omitted, the adapter sends a different body, a caller fabricates receipt fields, or regions consume from separate nonce stores.Authorization can also change after admission and before execution; validity at the external effect requires an appropriate additional mechanism.Source: §6 · p. 18

7.1 Signed exact-action approval

• Ed25519 signs a domain-separated pass hash, while verification recomputes the hash, checks the configured issuer key binding, and verifies the detached signature.The implementation’s serialization contract is not presented as a cross-language canonical-JSON standard or a new cryptographic construction.Source: §7.1 · p. 19

7.2 The admission transaction

• A BEGIN IMMEDIATE transaction reads persisted state, verifies the pass and policy conditions, updates applicable usage, consumes the nonce, inserts a bound receipt, and commits before successful admission returns.Caller-supplied replay, quota, and snapshot assertions are replaced with database values.Source: §7.2 · p. 19
• A failed transaction releases no execute result, although an ambiguous commit may have consumed the nonce; the adapter fails closed and recovery must consult durable state.Validity is sampled after the write lock is acquired, so a pass expiring while the gate waits is denied without consuming authority.Source: §7.2 · p. 20

7.3 Effect execution and crash semantics

• Azure writes use conditional object creation and content checks, but gate state, service records, and Azure are not covered by one transaction, so retries are receiver-specific rather than generally exactly-once.A failure after the Azure write but before the service records it can require reconciliation by reading and checking the existing object.Source: §7.3 · p. 20
• After a crash between admission and dispatch, retained intent and an explicit recovery policy are needed; the reference gate has no autonomous outbox, and recovery does not renew the pass.The demonstrated controlled recovery occurs within the original five-minute validity window; post-expiry recovery requires an unevaluated renewal and reconciliation protocol.Source: §7.3 · p. 20

8 A Governed Write, from Intent to Evidence

• A 128-byte synthetic write in a controlled Azure deployment links a signed pass, local receipt, and retrieved object, while making no claim about customer workloads.The integration map describes logical responsibilities, not four independently secured services.Source: §8 · pp. 20–21, Table 3 · p. 21

8.1 Fix the object before asking for authority

• The request binds destination and payload separately, so changing content after preparation requires a new approval even when the tool and destination remain unchanged.The adapter obtains holder and session context from the trusted runtime; copying those fields does not independently authenticate the caller.Source: §8.1 · p. 21

8.2 Review the final proposal and carry the signed result

• The issuer’s pass permits one write of the exact canonical action, and the action fingerprint, pass hash, and detached signature bind distinct parts of the approval.Figure 4 shows data dependencies through local admission and a separate service and storage path for the external outcome; its arrows are not a timing or distributed-atomicity claim.Source: §8.2 · pp. 21–22, Figure 4 · p. 22

8.3 Reconstruct, revalidate and durably admit

• Before dispatch, the adapter reconstructs the action from the final body, rechecks the signed pass and local conditions, and durably commits nonce consumption with a receipt.In the example, receipt 1761 binds the action and pass to issuer, workspace, nonce, unit, snapshot, and decision before the execute result returns.Source: §8.3 · p. 22

8.4 Execute, then establish what actually happened

• The service conditionally creates the Azure object and verifies stored content, but the receipt does not by itself prove its own durability or who sent a request against a malicious runner.The effect endpoint labels receipt evidence caller_supplied_binding_only; independently authenticated admission would need an additional receiver-enforced mechanism.Source: §8.4 · p. 23

8.5 Read the two clocks, not just the fast one

• The dispatch boundary and lifecycle use different clocks: lifecycle includes preparation and intervening wait, and the selected Table 4 record is not a percentile or service guarantee.The experiment does not measure the user’s request-to-execution clock; a short final boundary alone is not a measured tap-and-go result.Source: §8.5 · pp. 23–24, Table 4 · p. 23

8.6 Handle interruption without inventing a second authority

• After a post-commit, pre-dispatch crash, the controller recovers retained intent and delivers the already admitted operation; the controlled recovery relies on the storage service’s idempotency/content contract.Recovery completes within the original five-minute pass window; post-expiry recovery needs an explicit renewal and reconciliation design not established by the experiment.Source: §8.6 · p. 24, Figure 5 · p. 24
• A policy-refresh case sends the old pass to review and uses a separately signed replacement pass to obtain execute, without dispatching a cloud effect.Operationally, waiting for authority, admitted-but-uncertain delivery, and rejection call for distinct interventions.Source: §8.6 · pp. 24–25

9 Evaluation Method

• The evaluation treats semantic fixtures, cloud timings, and controlled fault histories as complementary evidence that cannot substitute for one another.Semantic receipt flags are not disk writes, cloud timings are not policy ground truth, and crash scenarios do not prove all failure histories.Source: §9 · p. 25

9.1 Cloud design and comparison

• The cloud study targeted 4,800 logical Azure Blob writes across two modes and three concurrency levels, using the same issuer, gate, storage service, and exact-action passes.Preparation and batch dwell are charged to each prepared action’s lifecycle; the closed-loop comparison is not a fully randomized crossover or a comparison of identical paired requests.Source: §9.1 · pp. 25–26

9.2 Timing definitions

• Worker-admission-to-dispatch timing excludes worker-acquisition waiting, while lifecycle timing starts at preparation and includes subsequent batch and worker waiting.Latency tables condition on successful attempts; failures remain recorded rather than being assigned zero latency.Source: §9.2 · p. 26

9.3 Semantic corpus and methods

• The semantic corpus renders 73 authored scenarios across four domains, producing 292 combinations and 1,460 inputs per method, but its fixtures and expected labels come from the authors.The handconstructed domain objects do not execute real effects, and the benchmark does not isolate production throughput or individual check costs.Source: §9.3 · pp. 27–28

9.4 Outcomes, denominators, and uncertainty

• Semantic reporting groups deny and review as not-allow, retains errors in denominators, and uses intervals that describe these repeated experiments rather than population guarantees.The core’s zero false allows among 1,360 expected-not-allow inputs has a descriptive 95% Wilson interval of [0, 0.282%].Source: §9.4 · pp. 28–29

9.5 Controlled fault campaign

• The fault campaign records ten controlled histories, including separate-process nonce and quota races, crash recovery, and a discarded acknowledgement followed by retry.Unit tests cover additional rollback and persistence obligations, but neither campaign is exhaustive fault-model checking or a power-loss study.Source: §9.5 · p. 29

Cloud timing results

• Prepared execution has lower worker-admission-to-dispatch p95 at every concurrency level, but longer mean complete lifecycle; this is a cost-placement tradeoff, not net acceleration.Table 6 reports the mode and concurrency comparisons; Figure 8 decomposes mean lifecycle, including preparation and batch dwell.Source: Table 6 · p. 30, §10 · p. 30, Figure 8 · p. 31

Cloud verification

• All 4,800 successful cloud objects were validated by separate direct Azure retrieval, with downloaded bodies, SHA-256 values, lengths, and ETags matching recorded requests and effects.This author-operated check corroborates stored content, not admission durability.Source: §10 · pp. 29–30

Semantic results

• The core matched authored binary expectations on every evaluated semantic input, supporting conformance to the exercised fixture contract rather than validation of its completeness.Table 8 reports outcomes against authored expectations, not independent human labels or cross-runtime generalization.Source: §10 · p. 32, Table 8 · p. 32

Fault results

• Table 9 distinguishes durable admission and receipt recovery from delivery; a crash can consume authority without an effect, and successful retries do not establish exactly-once execution.The reported cases are controlled fault histories, not arbitrary API guarantees.Source: §10 · p. 32, Table 9 · p. 32

11 Scale, Preparation, and Deployment Decisions

• Prepared execution shortened the measured dispatch boundary but increased mean complete lifecycle latency at every tested concurrency, so the results establish a placement tradeoff, not fleet capacity.The section’s routing, classification, and preparation mechanisms are proposals, not implemented or measured extensions.Source: §11 · pp. 32–33

11.1 Classifying an action stream without transferring authority

• Each distinct effect requires its own exact action binding and consumption identity; unresolved downstream bytes must be known before the final pass is issued.Context may explain a decision without crossing an execution boundary, and dependency does not delegate authority.Source: §11.1 · p. 33

11.2 Finite capacity after safety eligibility

• Queue eligibility remains provisional: after scheduling, the gate must revalidate and durably admit the action before execution.Capacity, fairness, overflow, and cancellation policies shape routing, but deadline ordering cannot become automatic approval.Source: §11.2 · p. 34, Figure 10 · p. 35

11.3 Active support from observable state

• Preparation is most plausible when final bytes are stable early and the action is likely to be used; branching, cancellation, or policy churn can add expiry and replacement work.Bounded horizons and cancellation on relevant changes help limit wasted preparation; they do not justify extending validity without a security basis.Source: §11.3 · p. 36

11.4 From observation to complete mediation

• Enforcement requires mediating every in-scope route before the effect; the current research interface does not establish this against a hostile bearer holder.The trusted runner controls the privileged token, and the effect service does not independently prove gate persistence.Source: §11.4 · p. 37

11.5 Responsibility and comparative deployment choices

• Deployment choices should weigh integration and evidence benefits against duplicated controls and operational cost, with explicit owners for policy, issuance, mediation, durability, destination behavior, and recovery.The study does not benchmark commercial platforms, and portability across runtimes requires adapter-specific validation.Source: §11.5 · p. 38

11.6 Buyer acceptance and go/no-go evidence

• Buyer acceptance should separately test coverage and unauthorized effects, queue-inclusive user waiting, bounded recovery, and preparation economics before expansion.A shorter dispatch boundary alone is not evidence of customer savings; compare costs per verified completed action and retain rejected and abandoned work in the accounting.Source: §11.6 · pp. 38–39

Freshness and policy state

• The gate does not keep its local snapshot synchronized with every policy authority or resource, so a matching configuration hash alone cannot establish current authorization.Freshness depends on the expiry, update, or lease policy a deployment actually enforces.Source: §12 · p. 39

Local state and scale

• SQLite provides a local transaction boundary, not global replay protection; independent regional copies cannot enforce cross-region single use.A busy writer may delay admission or cause fail-closed availability loss, and the study does not establish unbounded scale or service-level guarantees.Source: §12 · p. 40

External effects

• Admission records authorization, not delivery or completion; crashes and ambiguous outcomes require explicit delivery, idempotency, and reconciliation protocols.The artifact does not provide a generic distributed transaction or exactly-once external executor.Source: §12 · p. 40

Evaluation and verification scope

• Evaluation uses authored semantic cases and one configured cloud deployment, while verification does not introduce an independent policy annotator or externally replicated current artifact.Cloud mode order was alternating rather than fully randomized, and the semantic workload replays source-defined cases.Source: §12 · p. 40

Artifact contents

• The arXiv source package includes an ancillary archive with runnable code, frozen raw records, manifests, verification reports, exact source, and run instructions.The package also includes the manuscript, bibliography, generated result include, and empirical figures.Source: §13 · p. 40

Recorded evidence

• The semantic producer records seeds, environment, checksums, source hashes, method definitions, counts, and summaries, while the cloud and fault producers retain attempt-level evidence.New output directories are required so reruns do not overwrite evidence.Source: §13 · pp. 40–41

Verification and reproduction requirements

• The artifact verifiers reconstruct summaries and reconcile retained SQLite tables, but checksums stored alongside data do not prevent coordinated replacement or attest historical fsync durability.Reproduction requires Node.js and operator-provisioned services; the cloud study additionally needs Azure permissions and managed identity configuration.Source: §13 · p. 41

Conclusion

• ZeroGate’s contribution is an explicit revalidation contract and durable reference boundary, with an auditable comparison of where authorization cost is paid rather than a universal performance or exactly-once claim.The preservation argument depends on complete dependencies, current evidence, faithful mediation, and atomic consumption.Source: §14 · p. 41
• Organizations should align authorization with when action inputs become known while retaining a reliable final check, and advance deployment only when their own coverage, evidence quality, and complete user experience improve.The proposed scale mechanisms remain separate from the measured reference system.Source: §14 · p. 41

• The field groupings explain the implemented profile; they are not a replacement schema or interoperability standard.Source: A Field Guide to the Evidence · p. 42
• The complete record includes null fields and configuration labels as issued.Source: A Field Guide to the Evidence · p. 42
• Preserve the record’s bytes for recomputation, even when a label is less descriptive than the implementation discussed in the text.Source: A Field Guide to the Evidence · p. 42

A.1 Locate the worked observation

• The worked observation is found by identifier, and its body is 128 UTF-8 bytes with a matching payload_bytes field.The presentation generator rejects cloud files whose SHA-256 differs from the frozen record digest.Source: §A.1 · p. 42
• The action fingerprint binds the canonical action object, the payload hash binds only bytes, and the pass hash binds authority and validity conditions.An ETag is a destination-issued version identifier, not proof of authorization; Table 10 values alone are not a self-contained proof.Source: §A.1 · p. 42, Table 10 · p. 42

A.2 Read the pass as several obligations

• The upstream authorizer must keep the grant within the requested scope; the reference gate checks the resulting signed grant and exact action.The research adapter records its receipt obligation in a SQLite admission transaction, but a profile label or evidence flag is not independent persistence attestation.Source: §A.2 · p. 43
• The cloud workload uses synthetic content, so sensitive-data detection claims require a separate evaluation with their own population and labels.Source: §A.2 · pp. 43–44

A.3 Separate the records by what they witness

• The archived checks separately establish package consistency, issuer binding, replay agreement, database consistency, and byte readback, but none witnesses every historical event.Offline checks do not require a Studio login or access to the original Azure account.Source: §A.3 · p. 44
• Offline recomputation is possible from the archived material, while a fresh cloud experiment requires new infrastructure and credentials.The corrected evidence package and verification commands are identified separately from the historical public release.Source: §A.3 · p. 44

B Decision Checklist for Readers

• Assess whether exact-action approval, observation freshness, gate enforcement, durable consumption, and recovery match the deployment’s requirements.The checklist also asks whether performance comparisons count preparation, waiting, errors, destination verification, and equivalent clocks, and whether findings are measured, fixture-authored, or proposed.Source: B Decision Checklist for Readers · p. 45