Fail-closed permit-before-compute admission control for accelerators and hypervisors using freshness-bounded signed heads and policy allow masks, with optional meter-enforced budgets
Disclosed is a fail-closed permit-before-compute rail for accelerators and hypervisors. Prior to a compute-admission action enabling accelerator work to become executable, a driver, firmware, or hypervisor gate denies by default unless a short-lived, audience-bound Compute Execution Permit (CEP) validates to a head vector of signed heads from append-only verifiable structures, including a policy head and at least one of license/entitlements, unlearning status, export class, data residency, or energy/carbon budgets. Validation enforces head freshness under a freshness policy and, on head advance, append-only evolution (consistency). The CEP cryptographically commits to head identifiers, an allow mask, a budget slice, expiry, and anti-replay data; trusted meters may enforce energy/carbon budgets at admission. On admission, a Compute Receipt (CRc) may commit to a permit identifier, site/region, energy used, tflops_used, decision code, timestamps, and head identifiers, and a digest may be anchored in an append-only Evidence Registry. Optional embodiments include delegation, leases, and privacy-preserving predicates.
1 . A system, comprising one or more processors and memory storing instructions that, when executed by the one or more processors, cause the system, prior to admitting an accelerator workload, to:
(a) obtain, from one or more append-only verifiable structures, a head vector comprising signed heads for (i) policy and at least one of: (ii) license or entitlements, (iii) unlearning status, (iv) export class, (v) data residency, or (vi) energy and/or carbon budgets;
(b) for each signed head in the head vector, verify freshness relative to a freshness policy and, responsive to a head advance, verify append-only evolution (consistency) relative to a previously observed head for a corresponding append-only verifiable structure that produced the signed head;
(c) cause evaluation of a policy program to compute, or obtain output of a policy program comprising, an allow mask and a budget slice for a requested accelerator workload and a requested model based at least in part on the head vector;
(d) issue, or accept from an external issuer, a short-lived, audience-bound Compute Execution Permit (CEP) that cryptographically commits to identifiers of the signed heads used, the allow mask, the budget slice, an expiry, and an anti-replay tuple; and
(e) cause a verifier integrated in at least one of: (i) a kernel-mode driver path prior to doorbell or queue submission, (ii) device firmware microcode, or (iii) a hypervisor or SR-IOV virtual-function device model, to deny, by default, a compute-admission action that would enable accelerator work to become executable, the compute-admission action comprising at least one of enqueue, kernel launch, DMA enablement, memory-mapping enablement, or mediated device or virtual-function enablement, unless the CEP validates under current signed heads and trusted budget meters, including (i) validating the committed head identifiers against the current signed heads, (ii) validating the allow mask under configured policy predicates for an admission context, and (iii) validating the budget slice against the trusted budget meters, including verifying a cryptographic authenticity value binding at least the committed head identifiers, the allow mask, the budget slice, the expiry, and the anti-replay tuple, with any failed predicate in a bounded pre-effect decision slice short-circuiting to denial and preventing the compute-admission action.
2 . The system of claim 1 , further comprising an accelerator gate apparatus including an accelerator function exposing a doorbell or queue-submission interface or a functionally equivalent pre-effect admission interface and the verifier, wherein the verifier denies the compute-admission action absent a presented CEP that validates against current signed heads and trusted budget meters, and wherein the accelerator gate apparatus is configured such that each of a plurality of software and virtualization paths capable of causing accelerator work to become executable is intercepted at, or routed through, the verifier boundary to prevent bypass of CEP validation via alternate submission routes.
3 . The system of claim 1 , wherein the verifier is enforced in a hypervisor or SR-IOV context and performs CEP validation per virtual function or per mediated device function.
4 . The system of claim 1 , wherein the verifier is implemented in firmware microcode or a TEE-bound driver path and rejects CEPs whose attestation artifacts presented with, or referenced by, the CEP fail validity or recency checks, and wherein the verifier outputs a decision_code selected from ATTESTATION_FAILED, STATUS_STALE, or EVIDENCE_EXPIRED.
5 . The system of claim 1 , wherein trusted budget meters comprise at least one of: NVML power and energy telemetry, CUPTI floating-point and Tensor operation counters, AMD SMI telemetry, Intel Level-Zero Sysman telemetry, or functionally equivalent meters.
6 . The system of claim 1 , wherein the verifier prefers device-truth meters and, when falling back to at least one of BMC, Redfish, or power-distribution-unit meters, records a meter_confidence indicator of LOW, and maps negative remaining kilowatt-hour or TFLOP budget at gate time to ENERGY_BUDGET_EXCEEDED or CARBON_BUDGET_EXCEEDED regardless of scheduler admission state.
7 . The system of claim 1 , wherein at least one of export-class, data-residency, or unlearning predicates is satisfied using privacy-preserving proofs and the CEP commits to a proof transcript digest.
8 . The system of claim 1 , wherein, upon a PASS outcome or a termination event, the system emits a Compute Receipt (CRc) that commits to at least: a CEP identifier, energy_used in kilowatt-hours, tflops_used, a site or region identifier, one or more head identifiers, a decision_code, and timestamps, and anchors or registers a digest of the CRc into an append-only Evidence Registry that provides inclusion and append-only evolution (consistency) proofs, and wherein the CRc further comprises at least one of kgCO2e, an energy_source_mix, and a meter_confidence indicator.
9 . The system of claim 1 , wherein the CEP is a streaming lease requiring refresh within a sliding window, failure of which causes the verifier to output HOLD and, upon lapse of a grace interval or expiry of the CEP, to output DENY.
10 . The system of claim 1 , wherein the system supports delegation by issuing a Capacity Permit (CapP) that authorizes tenants to mint sub-CEPs within a bounded scope and time-to-live.
11 . The system of claim 10 , wherein the Capacity Permit includes a k-of-n signer policy for sub-CEP minting and attempts to exceed delegated scope cause the verifier to output POLICY_DENIED.
12 . The system of claim 1 , wherein the verifier enforces a status-stapling recency bound not exceeding the freshness policy for each head referenced by the CEP, and stale status causes the verifier to output STATUS_STALE or EVIDENCE_EXPIRED.
13 . The system of claim 1 , wherein, upon receipt of a Revocation Receipt for any head used to issue the CEP, the system invalidates the CEP at the gate, halts running queues via a kill-switch, and emits a termination Compute Receipt that is anchored together with a continuity record linking the revocation and halt event to one or more prior CEPs and CRcs.
14 . The system of claim 1 , wherein, in an offline or air-gapped deployment, the system is configured to accept, only within a bounded staleness window defined by the freshness policy, an EvidenceBundle carrying previously issued head identifiers and proof references, and to map admission outcomes to HOLD with decision_code of PROOF_REQUIRED when the bounded staleness window is exceeded until fresh signed heads are obtained.
15 . The system of claim 1 , wherein the one or more append-only verifiable structures comprise at least two independent append-only verifiable structures maintained under distinct trust anchors, a quorum policy requires a k-of-m set of heads or watcher corroborations before admitting the workload, and disagreement maps to HOLD with a signed continuity record until a cryptographic consistency proof links the heads.
16 . The system of claim 1 , wherein the Evidence Registry publishes signed heads subject to a maximum-merge-delay freshness bound and supports inclusion and append-only evolution (consistency) proofs for digests of CEPs and CRcs, and wherein the system validates, before treating a permit or receipt digest as registered, that the digest is included under a current signed head satisfying freshness and append-only evolution (consistency) requirements.
17 . The system of claim 1 , wherein the CEP includes the anti-replay tuple, is single-use and time-to-live limited, and reuse or concurrent reuse of the CEP causes the verifier to detect a replay and to output REPLAY_DETECTED and a HOLD outcome, and, upon lapse of a grace interval or per policy, to output DENY or EMERGENCY_STOP.
18 . The system of claim 1 , wherein (i) the CEP cryptographically binds to at least one of a device fingerprint, a virtual-function identifier, a workload identifier, or a model identifier, (ii) the cryptographic authenticity value further binds an audience identifier corresponding to the audience to which the CEP is bound, and (iii) the driver, firmware, or hypervisor refuses the compute-admission action if the binding mismatches.
19 . The system of claim 1 , wherein the verifier binds an admission decision to a queue_token that is valid only prior to the compute-admission action and that cryptographically commits to a subset comprising an audience identifier corresponding to the audience to which the CEP is bound, the committed head identifiers, the allow mask, the budget slice, and the expiry, wherein the queue token is invalid after doorbell or queue submission (or a functionally equivalent pre-effect admission action), and any mismatch between the committed subset and at least one of (i) a presented CEP or (ii) an admission context causes denial of the compute-admission action.
20 . The system of claim 1 , wherein the verifier performs admission checks within a bounded pre-effect decision slice, and an order, grouping, and placement of the admission checks is non-dispositive such that the checks may be reordered, parallelized, and/or split across verifier components including across at least two of: the kernel-mode driver path, device firmware microcode, and the hypervisor or SR-IOV virtual-function device model, while remaining fail-closed on any deficit.
21 . A computer-implemented method, comprising:
(a) obtaining, from one or more append-only verifiable structures, a head vector comprising signed heads for (i) policy and at least one of: (ii) license or entitlements, (iii) unlearning status, (iv) export class, (v) data residency, or (vi) energy and/or carbon budgets;
(b) verifying freshness of each signed head relative to a freshness policy and, responsive to a head advance, verifying append-only evolution (consistency) relative to a previously observed head for a corresponding append-only verifiable structure that produced the signed head;
(c) causing evaluation of a policy program to compute, or obtaining output of a policy program comprising, an allow mask and a budget slice for a requested accelerator workload and a requested model based at least in part on the head vector;
(d) issuing, or accepting from an external issuer, a short-lived, audience-bound CEP that cryptographically commits to identifiers of the signed heads used, the allow mask, the budget slice, an expiry, and an anti-replay tuple; and
(e) enforcing, at an accelerator driver, device firmware, or hypervisor, a bounded pre-effect admission decision that denies, by default, a compute-admission action that would enable accelerator work to become executable, the compute-admission action comprising at least one of enqueue, kernel launch, DMA enablement, memory-mapping enablement, or mediated device or virtual-function enablement, unless the CEP validates under current signed heads and trusted budget meters, including (i) validating the committed head identifiers against the current signed heads, (ii) validating the allow mask under configured policy predicates for an admission context, and (iii) validating the budget slice against the trusted budget meters, including verifying a cryptographic authenticity value binding at least the committed head identifiers, the allow mask, the budget slice, the expiry, and the anti-replay tuple, with any failed predicate in a bounded pre-effect decision slice short-circuiting to denial and preventing the compute-admission action.
22 . The method of claim 21 , further comprising, upon a PASS outcome or a termination event, emitting a CRc and anchoring or registering a digest of the CRc into an append-only Evidence Registry implemented as an append-only verifiable structure.
23 . The method of claim 21 , further comprising permitting offline or air-gapped operation only within a bounded staleness window defined by the freshness policy and otherwise outputting HOLD with decision_code of PROOF_REQUIRED until fresh signed heads are obtained.
24 . The method of claim 21 , further comprising rejecting CEPs when status staples fail a recency bound not exceeding the freshness policy, and outputting STATUS_STALE or EVIDENCE_EXPIRED.
25 . The method of claim 21 , further comprising detecting reuse or concurrent reuse of a single-use CEP and outputting REPLAY_DETECTED and a HOLD outcome, and, upon lapse of a grace interval or per policy, outputting DENY or EMERGENCY_STOP.
26 . The method of claim 21 , further comprising enforcing algorithm agility for CEP verification such that, after a declared pq_cutover_date, presentation of a CEP signed under a non-approved signature suite causes output of a HOLD outcome with a remediation hint to refresh algorithm suites, without altering fail-closed admission semantics.
27 . A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method of claim 21 .
28 . The non-transitory computer-readable medium of claim 27 , wherein the instructions further cause enforcement of CEP validation per SR-IOV virtual function or per mediated device function.
29 . The non-transitory computer-readable medium of claim 27 , wherein the instructions further cause, upon a PASS outcome or a termination event, emission of CRcs that commit to at least: a CEP identifier, energy_used in kilowatt-hours, tflops_used, a site or region identifier, a decision_code, and one or more head identifiers, and optionally anchoring a digest of at least one of the CRcs in an Evidence Registry that supports inclusion proofs and append-only evolution (consistency) proofs.
30 . The non-transitory computer-readable medium of claim 27 , wherein the instructions further cause use of at least two independent append-only verifiable structures under distinct trust anchors with a k-of-m quorum requirement and, upon disagreement, a HOLD outcome with a signed continuity record until a cryptographic consistency proof links the heads.