PaperlayerView exact revision on arXiv

Source-linked AI summary

Ethical Hyper-Velocity (EHV): A Hardware-Rooted Zero-Trust Runtime Enforcement Architecture for Agentic AI Systems

Riddhi Mohan Sharma

arXiv:2605.17909v2cs.AIcs.LO

TL;DR

Retrospective auditing and manual compliance gates cannot match autonomous agents’ execution velocity in regulated domains. EHV integrates hardware-rooted runtime enforcement with synchronized policy state and attestation, and bounded verification found non-compliant actions unreachable across 324 distinct states.

  • Problem

    Retrospective auditing and manual compliance gates create a governance bottleneck as autonomous agents proliferate in regulated domains.

  • Method

    EHV integrates Causal Graph CRDT policy compilation, epoch-based attestation caching, Grammar-Constrained Decoding enforcement, and workload identity.

  • Results

    324 distinct states were checked, with zero temporal property violations and non-compliant actions unreachable in the bounded model.

  • Takeaways & Limitations

    EHV targets governance latency reduction for high-stakes regulated agentic systems by making enforcement a hardware-rooted system invariant.

  • Takeaways & Limitations

    The evaluation uses a bounded depth-8 model, and empirical latency validation on production SEV-SNP hardware remains required.

Abstract

from arXiv · show

As autonomous agentic systems scale across regulated critical infrastructures, the lack of mechanistic, hardware-rooted enforcement for high-frequency policy updates presents a fundamental safety gap. We present Ethical Hyper-Velocity (EHV), a governance-aware runtime enforcement architecture for agentic systems that combines Grammar-Constrained Decoding (GCD) for inline policy-constrained token generation, Causal Graph CRDT-based policy synchronization with vector-clock ordering, hardware-attested execution in Trusted Execution Environments (TEEs), and OSCAL-formatted machine-readable audit logging. Unlike retrospective auditing frameworks (ISO/IEC 42001, NIST AI RMF) that introduce 14-30 day policy latencies, EHV relocates the Policy Enforcement Point (PEP) into the inference pipeline via a Governance-Aware Just-In-Time (JIT) Compiler. Under explicitly stated assumptions, the architecture reduces enforcement latency, improves traceability, and supports formal verification of safety invariants in a bounded model. We demonstrate via TLA+ model checking that non-compliant agentic actions were unreachable in the verified bounded operating state space (1,738 states generated, 324 distinct, depth 8, zero violations). Under these conditions, O(1) runtime enforcement reduces the traditional trade-off between deployment velocity and governance integrity, targeting Governance Latency from O(days) toward O(1). EHV's differentiating contribution is the integration of GCD, Causal CRDT, TEE attestation caching, and bounded formal verification into a single, hardware-rooted enforcement architecture -- a combination not achieved by any contemporaneous system. The architecture is demonstrated through a pediatric oncology dosage use case, with applicability to regulated critical infrastructures including healthcare, financial compliance, and critical infrastructure control.

I. INTRODUCTION … H. Emerging Agentic Runtime Security Systems (2025–2026)

EHV addresses the governance bottleneck in autonomous systems by moving policy enforcement from retrospective procedures into a hardware-rooted, formally constrained inference architecture. Its novelty lies in co-designing token-level grammar enforcement, causal policy synchronization, TEE attestation caching, and bounded formal verification into one runtime loop.

  • I. INTRODUCTION: EHV targets the governance bottleneck by enforcing policies in real time through a hardware-rooted architecture that compiles governance into the inference stack.Existing oversight cannot match autonomous-agent execution velocity, while EHV supports safety invariants during high-frequency policy updates and distributed operation.
  • A. Contributions: The paper formalizes Governance Latency as GL = te −td, extends zero trust from identity to action, models governance threats, and maps controls to major regulatory frameworks.The contributions include a 168M-action unsafe-action exposure calculation for healthcare and alignment with NIST AI RMF, EU AI Act Article 12, NIST SP 800-207, and FDA PCCP requirements.
  • A. AI Governance Frameworks; B. Zero Trust Architecture: NIST AI RMF, ISO/IEC 42001, and the EU AI Act structure lifecycle, management, or logging obligations but do not provide execution-layer enforcement, while ZTA verifies identity rather than policy-compliant action.ISO/IEC 42001 inherits a PDCA audit cycle with GL ≥14 days, and a valid Physician Twin credential can still authorize an action violating a recently updated policy.
  • C. Formal Methods in Safety-Critical Systems; D. Trusted Execution Environments: EHV applies formal methods to governance enforcement, while TEEs provide hardware-rooted isolation whose attestation overhead is reduced through epoch-based caching.TLA+ and TLC support distributed-systems verification, whereas existing AI safety and Constitutional AI approaches do not provide mechanistic runtime enforcement; cached attestation costs O(1) per inference within an epoch.
  • E. CRDTs for Distributed State; F. Runtime Guardrail Systems: EHV uses CRDT monotonic convergence to propagate policies across partitioned networks and combines this synchronization with hardware enforcement beyond software-layer runtime guardrails.Causal Graph CRDTs with vector clocks replace Last-Write-Wins timestamps, while systems such as NeMo Guardrails and Guardrails AI lack EHV’s formal verification and TEE-backed enforcement.
  • G. Grammar-Constrained Decoding Foundations: Grammar-Constrained Decoding masks disallowed tokens by intersecting generation prefixes with permitted automaton transitions, and EHV repurposes this mechanism to encode permissible agentic actions.The approach is implemented in XGrammar [18], Outlines [19], LMQL, and vLLM’s LogitsProcessor API, but EHV applies it specifically as policy enforcement.
  • H. Emerging Agentic Runtime Security Systems (2025–2026): Emerging systems provide partial runtime governance: MI9 [25] lacks TEE backing, AgentSpec [26] and Aegis [27] lack formal verification and hardware attestation, SAFi lacks formal verification, and AgenTEE lacks EHV’s integrated mechanisms.AutoTEE [30] could complement EHV by automating agent-function porting into TEEs.
  • H. Emerging Agentic Runtime Security Systems (2025–2026): EHV’s differentiator is a single architecture combining GCD, Causal CRDTs, TEE attestation caching, and bounded TLA+/TLC verification in a closed enforcement loop.The components are established individually; their co-design addresses policy freshness, token constraints, compromised hosts, and runtime enforcement together.

I. NIST CAISI and Agentic Identity Standards · III. PROBLEM FORMULATION: GOVERNANCE LATENCY · IV. SYSTEM ARCHITECTURE

EHV addresses agentic identity interoperability and governance latency by enforcing policy at the protocol and inference boundaries. Its architecture combines four hardware-rooted pillars while targeting bounded, fail-closed enforcement under explicit operational conditions.

  • I. NIST CAISI and Agentic Identity Standards: NIST CAISI’s February 2026 AI Agent Standards Initiative addresses interoperability, authentication, authorization, and identity management for AI agents.Its companion NCCoE concept paper proposes adapting OAuth 2.0/2.1, OIDC, and SPIFFE/SPIRE for non-human agent workloads.
  • I. NIST CAISI and Agentic Identity Standards: MCP, donated to the Linux Foundation’s Agentic AI Foundation in December 2025, provides an open agent-to-tool protocol compatible with EHV’s structured action authorization.EHV can enforce governance at the MCP protocol boundary.
  • III. PROBLEM FORMULATION: GOVERNANCE LATENCY: Governance Latency is defined as the interval between a policy decision event at time t_d and its enforcement at time t_e.Traditional frameworks are described as spanning 14–30 days because of manual review cycles.
  • III. PROBLEM FORMULATION: GOVERNANCE LATENCY: 168M actions could execute under a stale policy state during a 14-day Governance Latency interval in the illustrative healthcare scenario.The scenario assumes I = 5,000 Physician Twin instances and R = 100 recommendations/hour; EHV aims to reduce Governance Latency toward a constant bounded by TEE attestation overhead.
  • III. PROBLEM FORMULATION: GOVERNANCE LATENCY: The < 1ms target is an architectural objective based on estimated TEE LogitsProcessor overhead, not a production-hardware validation result.Empirical validation on AMD SEV-SNP hardware is identified as future work.
  • III. PROBLEM FORMULATION: GOVERNANCE LATENCY: EHV is positioned as a CP system that prioritizes policy consistency and CRDT convergence over availability during partitions.If a partition exceeds the epoch boundary |E_k|, the system transitions to a fail-closed halt state rather than executing under stale or unverified policy.
  • IV. SYSTEM ARCHITECTURE: EHV’s architecture comprises four pillars: a Causal Graph CRDT Policy Compiler, epoch-based attestation caching, a Grammar-Constrained Decoding PEP, and SPIFFE/SPIRE workload identity.These components jointly define the system architecture for policy synchronization, attestation, inline enforcement, and agent identity.

A. Pillar 1: Causal Graph CRDT Policy Compiler · B. Pillar 2: Epoch-based Attestation Caching · C. Pillar 3: Grammar-Constrained Decoding PEP

EHV combines causally ordered CRDT policy compilation, epoch-based TEE attestation caching, and GCD at the token-generation layer. Together, these mechanisms provide hardware-rooted syntactic enforcement while bounding policy-update consistency and exposing explicit scalability and semantic-compliance limits.

  • A. Pillar 1: Causal Graph CRDT Policy Compiler: Vector-clock ordering lets Causal Graph CRDT policy replicas converge on the latest safety constraints without coordination overhead or physical clock synchronization.Production policy mutations form a cryptographically signed DAG, removing physical clock dependencies and preventing malicious backdated injection.
  • A. Pillar 1: Causal Graph CRDT Policy Compiler: Policy Merkle roots Hp = SHA-256(SG) provide O(1) integrity verification and bind each epoch’s constraint set to the GBOM.The root commits the global ethical state used by enforcement.
  • B. Pillar 2: Epoch-based Attestation Caching: 200ms+ remote-attestation round trips are amortized by validating each policy hash Hp once per epoch rather than on every enforcement check.Healthcare deployments configure the epoch duration |Ek| = 60s to balance freshness against attestation cost.
  • C. Pillar 3: Grammar-Constrained Decoding PEP: GCD replaces v1 ASEL postgeneration filtering as the primary Policy Enforcement Point at the inference pipeline’s token-generation layer.The governance policy is compiled into a DFA representing permissible action sequences.
  • C. Pillar 3: Grammar-Constrained Decoding PEP: No token outside the DFA’s allowed transition set can be sampled, making syntactic policy enforcement architectural rather than probabilistic.At each generation step, disallowed-token logits are set to −∞ before softmax sampling.
  • C. Pillar 3: Grammar-Constrained Decoding PEP: Double-buffered DFA recompilation and prefix-alignment validation apply converged policy updates without stalling active inference or creating mid-sequence undefined states.If the current DFA state is absent from the incoming automaton, swapping is deferred until a transaction boundary and a local execution epoch freeze is maintained.
  • C. Pillar 3: Grammar-Constrained Decoding PEP: DFA complexity can grow with policy intersections, so EHV assumes bounded domain-specific schemas and recommends hierarchical grammar decomposition beyond the supported state range.Healthcare clinical action vocabularies typically yield DFAs with 10^2–10^4 states, while the performance cliff under expanding profiles remains to be characterized.
  • C. Pillar 3: Grammar-Constrained Decoding PEP: GCD guarantees syntactic compliance only; semantically harmful actions that fit the grammar may execute and receive a clean compliance record in the GBOM audit trail.The hardware-rooted boundary secures pipeline mechanics, not semantic payloads.

D. Action Schema Extraction Layer (Compatibility Mode) · E. Pillar 4: SPIFFE/SPIRE Workload Identity

The compatibility-mode ASEL converts unstructured outputs into typed action tuples for PEP evaluation, but its fidelity is unverified and safety depends on correct extraction. EHV also binds agent workload identity, scoped action credentials, and TEE attestation to support fine-grained per-action authorization.

  • D. Action Schema Extraction Layer (Compatibility Mode): ASEL is retained for backward compatibility with v1.0 deployments lacking GCD support and is outside the primary enforcement critical path in v2.The compatibility layer supports deployments that cannot use Grammar-Constrained Decoding.
  • D. Action Schema Extraction Layer (Compatibility Mode): ASEL parses unstructured model output into typed tuples of action_type, parameters, and context for structured PEP evaluation.For example, “administer 1.5 mg/m2 Vincristine IV” maps to (DOSAGE, {drug : Vincristine, dose : 1.5, unit : mg/m2}, IV).
  • D. Action Schema Extraction Layer (Compatibility Mode): The JIT PEP restricts remote attestation to epoch boundaries and fails closed when a network partition exceeds the epoch duration.This lifecycle condition limits attestation frequency while preserving fail-closed behavior during prolonged partitioning.
  • D. Action Schema Extraction Layer (Compatibility Mode): ASEL fidelity is domain-specific and unverified, so the safety invariant Ig holds only conditional on correct extraction.Migration to full GCD enforcement in Pillar 3 removes this unverified dependency.
  • E. Pillar 4: SPIFFE/SPIRE Workload Identity: SPIFFE/SPIRE issues ephemeral, session-bound X.509 SVID credentials to authenticate each agent workload before authorization.Each agent instance is treated as a Non-Human Identity requiring authentication before action authorization.
  • E. Pillar 4: SPIFFE/SPIRE Workload Identity: The identity model binds workload provenance, epoch-scoped action credentials, and TEE measurement to prevent credential replay by compromised host processes.RFC 8693 Token Exchange supplies short-lived OAuth 2.0 tokens authorizing specific action classes per epoch, while enclave measurement is bound to the action token.
  • E. Pillar 4: SPIFFE/SPIRE Workload Identity: This separation of workload identity and policy authorization lifecycles enables fine-grained per-action governance, consistent with the NIST NCCoE concept paper.The design distinguishes persistent workload identity from action-specific authorization.

F. Separation of Duties and Fault Isolation … C. Model Checking Results

EHV isolates policy authoring, enforcement, and audit verification across trust boundaries, while formal verification specifies safety, liveness, and prefix-alignment properties. Bounded TLC checking found zero temporal violations and unreachable non-compliant actions under the tested configuration.

  • F. Separation of Duties and Fault Isolation: The Policy Administration Point remains external to the TEE, while the in-TEE PDP/PEP verifies signatures, merges CRDT updates, and enforces the compiled DFA without authoring policies.Signing keys remain in external HSMs or key-management services, and the PEP cannot modify or override policies.
  • F. Separation of Duties and Fault Isolation: The external Audit Verification Point independently consumes signed GBOM records, so a PEP breach fails closed rather than enabling policy injection or audit suppression.Compliance verification, audit aggregation, and regulatory reporting are performed by external systems.
  • F. Separation of Duties and Fault Isolation: Consolidating signature verification, CRDT merging, vector-clock maintenance, DFA compilation, and logit masking inside the TEE expands the intra-TEE Trusted Computing Base.The architecture therefore concentrates these functions within the JIT PEP process.
  • V. FORMAL VERIFICATION (TLA+): The TLA+ model tracks PolicySet, AgentAction, NetworkState, EnforcementStatus, and DfaState to represent policy, actions, connectivity, enforcement outcomes, and token-prefix alignment.NetworkState distinguishes CONNECTED from PARTITIONED, while EnforcementStatus permits PERMIT, DENY, or ESCALATE.
  • A. Safety Invariant: The safety invariant states that no invalid action can reach PERMIT regardless of the system’s execution path.This property governs action authorization under the modeled execution behavior.
  • B. Liveness Property: Every policy update eventually propagates to all nodes through CRDT convergence.This is the model’s liveness property for policy synchronization.
  • C. Model Checking Results: 1,738 states generated across depth 8 produced 0 temporal property violations, with non-compliant actions unreachable among 324 distinct states in the bounded model.The configuration used |MaxPolicyVersion| = 5, |Actions| = 3, and checked 5 branches.
  • C. Model Checking Results: TLC verified that concurrent background compilation and token-level DFA swaps update the active pointer only when prefix-aligned, preventing undefined states and out-of-bounds transitions.The PrefixAligned invariant was checked across all interleavings of compilation and active-token swaps.

D. Scope and Small-Model Considerations … B. Threat Categories

EHV’s bounded verification supports its enforcement logic only under limited modeling scope, while its threat model depends on explicit hardware, cryptographic, timing, and grammar assumptions. The architecture addresses policy, TEE, synchronization, and output threats through layered controls, but semantic misuse and production overhead remain residual concerns.

  • D. Scope and Small-Model Considerations: The bounded model verifies enforcement logic for a single agent, excluding concurrent multi-agent actions, realistic vector-clock CRDT conflicts, and unbounded policy-version sequences.The small-scope hypothesis motivates the bounded analysis; extending safety claims to unbounded state spaces via TLAPS is identified as primary future work and requires substantial formal-methods expertise.
  • B. Threat Categories: The threat model covers policy poisoning, TEE side channels, stale epochs, prolonged network partitions, adversarial output encoding, and clock-skew or NTP poisoning.These categories define the governance-compiled agentic system’s attack surface.
  • A. Trust Assumptions: EHV assumes uncompromised Intel TDX or AMD SEV-SNP hardware, signed policy updates, attested TEE-resident PEP binaries, eventual partition recovery, and policy-faithful grammars.Grammar correctness remains a trust dependency rather than a formal guarantee.
  • B. Threat Categories: StackWarp can break SEV-SNP guest integrity, so AMD deployments require current firmware patches in addition to LFENCE and SMT-disable mitigations.The note identifies firmware maintenance as a non-optional security control.
  • B. Threat Categories: EHV uses authenticated signed DAG mutations, issuer allowlists, replay protection, epoch controls, forced re-attestation, CRDT convergence, fail-closed halting, and operator escalation against governance threats.Vector-clock ordering and signed causal DAGs remove dependence on physical clocks; configurable |E_k| and bounded epoch TTL limit stale-epoch exposure.
  • B. Threat Categories: GCD constrains syntactic grammar compliance, typed action envelopes, signed approvals, escalation RBAC, and GBOM logging, but syntactically valid harmful payloads remain possible.High-stakes actions therefore require human clinical oversight through the ESCALATE path and semantic intent analysis.
  • B. Threat Categories: The GCD mask adds ∼0.033ms per step against a 10–30ms GPU forward pass, while asynchronous mask pre-fetching hides PCIe and LFENCE costs; production overhead still requires measurement.The claimed sub-millisecond enforcement depends on avoiding pipeline stalls, and combined TEE-mitigation plus DMA synchronization overhead remains an empirical question.

C. Failure Mode: Non-TEE Environments · D. Epoch Staleness Window (ESW) Analysis · E. Fail-Closed Partition Semantics

EHV’s guarantees weaken without TEE support, where enforcement falls back to out-of-band auditing, while epoch-based updates create bounded staleness. Fail-closed partition handling prevents execution under stale policy but exposes explicit availability risks, and emergency resets reduce staleness while introducing reset-channel attack surfaces.

  • C. Failure Mode: Non-TEE Environments: EHV’s sub-millisecond enforcement target degrades without Confidential Computing support, requiring out-of-band audit with GL > 0 under NIST SP 800-53 SI-17 fail-safe provisions.This is identified as the primary architectural friction point for legacy infrastructure deployments.
  • D. Epoch Staleness Window (ESW) Analysis: A critical policy update arriving within epoch Ek is not enforced until the next epoch boundary, creating an epoch staleness window.The maximum staleness window is defined by the epoch boundary rather than immediate enforcement.
  • D. Epoch Staleness Window (ESW) Analysis: Compared with legacy Nunsafe = 168,000,000 under 14-day GL, EHV reduces unsafe exposure by 5 orders of magnitude.The comparison is given for healthcare parameters λ = 500,000 actions/hour aggregate and |Ek| = 60s.
  • D. Epoch Staleness Window (ESW) Analysis: For ultra-critical updates, EMERGENCY_EPOCH_RESET enables forced mid-epoch re-attestation, reducing ESW to network propagation latency (< 1s).The emergency channel requires cryptographic authentication with PAP-level signing authority and rate-limiting to mitigate reset abuse.
  • D. Epoch Staleness Window (ESW) Analysis: Spurious emergency resets can create denial of service through continuous re-attestation overhead, while blocked reset signals preserve the staleness window.These failure modes make the reset channel an explicit attack surface.
  • E. Fail-Closed Partition Semantics: When a network partition persists beyond |Ek| and attestation is unreachable, EHV enforces strict fail-closed semantics.The partition condition triggers the JIT PEP’s safe-halt behavior.
  • E. Fail-Closed Partition Semantics: The JIT PEP enters a Safe Halt State and blocks all outgoing tool and action executions until attestation is restored, preventing execution under indefinitely stale policy.This safety guarantee creates an availability vulnerability: sustained partitions can force affected agents into continuous halts, explicitly prioritizing safety over availability in critical deployments.

VII. CASE STUDY: PEDIATRIC ONCOLOGY DOSAGE … C. Regulatory Alignment

The pediatric oncology case contrasts a 14-day legacy dosage-policy update with EHV’s sub-second propagation and syntactic exclusion of non-compliant Vincristine outputs. The discussion extends this enforcement model to velocity-integrity co-production, cryptographic governance provenance, and regulatory evidence generation without replacing organizational or legal controls.

  • VII. CASE STUDY: PEDIATRIC ONCOLOGY DOSAGE: The pediatric oncology case operationalizes EHV as a hardware-rooted response to an FDA-mandated Vincristine reduction from 1.5 mg/m2 to 0.75 mg/m2.The dosage change is prompted by a new neurotoxicity signal.
  • A. Legacy System (GL = 14 days): 50,400 potentially toxic dosage recommendations could be produced before enforcement under a 14-day legacy governance latency, even at a 0.03% violation rate.The scenario assumes 5,000 Physician Twin instances processing 100 recommendations per hour during manual review, committee approval, EHR updating, and retraining.
  • B. EHV System (GL < 1ms, target): <1 second policy propagation and a 0.75 mg/m2 maximum compiled into GCD exclude higher Vincristine outputs before sampling, regardless of the LLM’s training distribution.The guarantee is syntactic and applies within the compiled grammar’s scope; exceeding tokens receive zero probability after the logit is set to −∞.
  • A. The Velocity-Ethics Co-Production Principle: EHV reverses the usual velocity-integrity trade-off by verifying compliance at inference time, eliminating post-deployment audit backlog and positively correlating deployment velocity V with governance integrity I.The stated formalization is VEHV = V0 · f(I), with f(I) ≥1 when pre-execution verification reduces retrospective compliance gates.
  • B. Governance Bill of Materials (GBOM) for M&A Due Diligence: GBOM binds each autonomous decision to its policy Merkle root Hp, TEE attestation epoch, GCD DFA state, and enforcement outcome in OSCAL Assessment Results v1.1.2, [32].This cryptographic audit trail supports post-hoc compliance-provenance verification and governance due diligence for AI stacks.
  • C. Regulatory Alignment: Table II maps EHV controls to regulatory and standards requirements, including accountability, monitoring, separation of duties, logging, and updateable constraint-set controls.The mapping generates compliance evidence but does not replace organizational controls, legal review, or conformity assessment required for legal compliance.

D. Deployment Topology and Operational Considerations · E. TEE Portability

EHV targets high-stakes regulated deployments where unsafe autonomous actions justify Confidential Computing costs, rather than consumer-facing advisory systems. Its software is portable across TEE vendors but still requires a Confidential Computing substrate for hardware-rooted enforcement.

  • D. Deployment Topology and Operational Considerations: EHV targets healthcare, financial compliance, and critical-infrastructure agents because a single unsafe autonomous action can outweigh Confidential Computing’s infrastructure premium.The architecture is not positioned as general-purpose middleware for consumer-facing chatbots or advisory systems.
  • D. Deployment Topology and Operational Considerations: Confidential Computing is available on AWS c6a.metal, GCP C3D, and Azure DCasv5, with a 10–20% premium over equivalent standard instances.The listed cloud configurations use SEV-SNP, with Azure additionally supporting TDX.
  • D. Deployment Topology and Operational Considerations: SPIRE federation supports regional TEE clusters with automatic credential rotation, using a server mesh alongside the CRDT policy store to reduce global synchronization complexity.This deployment pattern separates regional identity operations from policy synchronization while maintaining automated credential management.
  • E. TEE Portability: EHV abstracts TEE support through encrypted memory isolation and remote attestation interfaces, independently of any specific TEE vendor.The software architecture includes the GCD engine, CRDT policy store, SPIFFE identity layer, and GBOM logging.
  • E. TEE Portability: EHV can migrate among AMD SEV-SNP, Intel TDX, ARM CCA, and NVIDIA H100 Confidential Computing without changing policy compilation, enforcement logic, or audit format.This portability applies to the TEE backend while preserving the rest of the enforcement and logging architecture.
  • E. TEE Portability: EHV is TEE-vendor-portable but not TEE-optional: it requires a Confidential Computing substrate and falls back to out-of-band auditing on non-TEE deployments.Commodity-host deployments therefore do not provide the architecture’s stated hardware-rooted runtime enforcement model.

F. Comparison: Prompt-Layer Policy-as-Code … AI TOOL DISCLOSURE

EHV contrasts prompt-layer Policy-as-Code with pre-execution GCD+TEE enforcement for regulated actions, then states its hardware-rooted contribution, verification result, limitations, validation plan, and AI-tool disclosure.

  • F. Comparison: Prompt-Layer Policy-as-Code: For regulated domains, EHV’s pre-execution GCD+TEE guarantee is presented as justifying infrastructure costs, whereas PaC is suited to low-stakes advisory systems with post-hoc accountability.The comparison addresses prompt-engineered Declarative Policy-as-Code with transparency ledgers versus EHV architectures.
  • G. Limitations and Future Empirical Work: The architecture requires TEE hardware for full enforcement, domain-specific epoch tuning, correct grammar specifications, and bounded rather than unbounded formal verification.Non-TEE deployments degrade to out-of-band auditing, while grammar completeness verification and unbounded-state extension remain future work.
  • IX. EMPIRICAL VALIDATION PLAN: The planned validation targets AMD SEV-SNP confidential VMs and tests permitted, denied, escalated, mid-epoch-update, and fail-closed behaviors.The plan compares per-token latency across baseline, GCD, and GCD+attestation conditions while measuring enclave overhead, policy propagation, and fail-closed transition time.
  • IX. EMPIRICAL VALIDATION PLAN: Expected overhead is 2–10% for general workloads, <20% for LLM inference, and < 1 ms per inference for cached remote attestation.These are expectations based on published SEV-SNP literature, not measured results from the planned benchmarks.
  • X. CONCLUSION: EHV places GCD as the primary Policy Enforcement Point in token generation, backed by Causal CRDT policy state and TEE attestation caching, to reduce Governance Latency by orders of magnitude.The claim targets agentic systems operating in regulated domains.
  • X. CONCLUSION: Bounded formal verification found non-compliant actions unreachable across all explored interleavings within the verified bounded state space.The conclusion frames governance integrity and deployment speed as coproductive when enforcement is architectural rather than procedural.
  • X. CONCLUSION: EHV integrates GCD, Causal CRDT synchronization, TEE attestation caching, and bounded formal verification into one hardware-rooted architecture for regulated agentic systems.The paper identifies this four-way integration as its differentiating contribution and states that no contemporaneous system achieves it.
  • AI TOOL DISCLOSURE: Claude and Gemini assisted with prose refinement, LaTeX formatting, and literature-survey work, while the author reports originating the technical claims, specifications, architecture, and implementation.The author also reports independently verifying the TLA+ specification with TLC.

APPENDIX … C. Integration Rules •

The appendix specifies a hardware-rooted GCD integration in which CFG policies become constant-time token constraints, are applied before sampling, and produce attested, governance-linked action records. The rules connect DFA state, policy provenance, encrypted execution, typed outputs, and OSCAL assessment evidence.

  • A. DFA Compilation: CFG policies are compiled into DFAs using standard subset construction, with CSR representation enabling O(1) transition lookup per token.The DFA operates over the token vocabulary and supports constant-time policy-transition checks during generation.
  • B. Logits Masking Pseudocode: The logits-masking procedure returns DENY for disallowed generation paths and derives allowed tokens from the current DFA state.The pseudocode iterates over the vocabulary after checking policy admissibility.
  • C. Integration Rules •: Masking MUST occur before softmax at every generation step to enforce the policy during token generation.This ordering places policy enforcement inside the inference pipeline rather than after sampling.
  • C. Integration Rules •: Each generated token logs the DFA state and policy Merkle root to the Governance Bill of Materials.These fields bind token-level enforcement activity to policy provenance.
  • C. Integration Rules •: Action outputs are wrapped in typed envelopes before downstream tool execution, while the GCD engine runs in encrypted guest memory and the DFA state is sealed by the TEE.The integration rules combine typed execution boundaries with confidential, attested enforcement state.
Loading 2605.17909v2…