{"release":"2026.08","methodologyVersion":"1.0","generatedAt":"2026-08-22","records":[{"id":"OS-00","slug":"ten-thousand-off-switches","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":true,"synopsis":"A proposed accelerator architecture distributes thousands of independently licensing security blocks through critical logic. Each block starts disabled, issues a fresh nonce, accepts only a correctly signed license, meters an allowance of operations, and halts its local function when that allowance is exhausted. The intended security gain is redundancy: an attacker must bypass enough interspersed blocks without damaging the computation, rather than defeat one central switch.","mechanism":{"goal":"Prevent unauthorized use of large fleets of AI accelerators, including after theft or diversion and in the presence of sophisticated physical attacks.","steps":["Intermix many small security blocks with essential accelerator logic, assigning each block a locally critical operation.","On power-up, each block sets its usage allowance to zero, generates a unique nonce, and advertises it through untrusted collection logic.","An off-device authorizer signs a license for that nonce; the block verifies it against hardwired public keys and increments its allowance.","The allowance falls as authorized operations occur, and the block stops its essential logic at zero."],"output":"A local hardware enable/disable decision at each gated logic block; collectively, continued chip operation only while fresh licenses are accepted."},"claimBoundary":{"establishes":["A concrete circuit-level design sketch using standard components, public-key verification, and replay-resistant nonces.","A redundancy argument and first-order transistor-area estimate for thousands of blocks.","An explicit attack inventory covering logical flaws, bypass, glitching, physical editing, supply-chain compromise, cryptography, keys, and connectivity."],"remainsExternal":["Who is entitled to authorize use, on what evidence, and with what appeal or recovery process; authorization decisions are explicitly out of scope.","Tape-out evidence for timing, routing, power, yield, testability, reliability, and false shutdown rates at the proposed density.","Proof that every useful computation path is gated and that diverse blocks do not retain a scalable common-mode bypass."]},"threatModel":{"asset":"Authorized control of 10,000-plus-chip deployments, while preserving legitimate availability and preventing the blocks from altering or exfiltrating computations.","adversary":"Primarily a well-funded non-state hardware team, illustrated as a clandestine $1 billion project; ambitiously, a nation-state with physical access and possible involvement in design or manufacturing.","capabilities":["Physical circuit editing, probing, voltage or laser glitching, side-channel work, and execution-path bypass.","Discovery of design or cryptographic flaws and compromise during chip design or fabrication.","Theft or destruction of authorization keys and disruption of license delivery."],"exclusions":["The policy and institutional process that decides whether to issue a license is explicitly outside the paper's scope.","Fine-grained workload authorization and distributed audit logging are described as future extensions, not properties of the presented mechanism."],"enforcementBoundary":"The boundary is the transistor-level interface between each security block and its assigned essential logic. Everything outside a block's nonce, verifier, allowance, and gating logic is treated as untrusted, but issuance policy remains off chip."},"trustRegister":[{"domain":"Physical integration","requirement":"Enough indispensable data and compute paths must pass through intact security blocks, with no usable ungated route.","failure":"A common bypass or incomplete coverage lets unauthorized computation proceed without defeating thousands of blocks.","sourceTreatment":"central"},{"domain":"Nonce and license logic","requirement":"Nonces remain unique and block-local verification, counters, and hardwired keys behave correctly under faults and attacks.","failure":"Replay, counter manipulation, or a common logical flaw creates reusable authorization or denial of service.","sourceTreatment":"central"},{"domain":"Authorization infrastructure","requirement":"Private keys, quorum rules, backups, and license-delivery channels remain secure and available.","failure":"Key theft authorizes unlimited use; key loss or prolonged disruption disables legitimate fleets.","sourceTreatment":"discussed"},{"domain":"Design and manufacturing integrity","requirement":"The implemented silicon matches the reviewed design and contains no scalable backdoor.","failure":"A supply-chain modification defeats or weaponizes the mechanism before deployment.","sourceTreatment":"discussed"},{"domain":"Authorization legitimacy","requirement":"The issuer makes timely, correct, and legitimate decisions about chip use.","failure":"The hardware faithfully enforces an erroneous, compromised, or politically contested decision.","sourceTreatment":"mentioned"}],"authoredCaveats":["Accelerator integration requires nontrivial work, and new hardware takes years to design, manufacture, and displace the installed base.","Exporting roughly 10 kB of nonces may itself raise exfiltration concerns, especially in air-gapped data centers.","Detailed trust still depends on design, manufacturing, and key provisioning; flaws can block legitimate use.","TRNG integrity, antifuse programming, network disruption, key theft, and key deletion each receive separate countermeasures rather than being assumed away."],"assessment":{"assuranceTransfer":"The circuit can establish that a block received a license signed by a hardwired key for its current nonce. Treating that fact as authorized chip use transfers assurance through complete path coverage, reliable physical integration, uncompromised issuer keys, and an external decision process the circuit does not evaluate.","loadBearingSequence":["A fresh nonce and valid signature establish an unexpired allowance in each block.","Every useful computation depends on many correctly functioning gated paths.","No scalable logical, physical, fabrication, or fault attack bypasses the diverse block population.","The off-device issuer remains secure, available, and institutionally entitled to decide."],"joke":"The single kill switch has been eliminated by giving every neighborhood of the chip its own licensing department."},"tests":["Tape out a representative accelerator region and measure routing, timing closure, power, yield, test coverage, and false-disable rates rather than inferring overhead from transistor count.","Give independent physical red teams many devices and test whether attack-development costs remain per-chip rather than collapsing into one reusable bypass.","Fault-inject TRNGs, counters, verification logic, power, and clocks while measuring both unauthorized work and legitimate outages.","Run fleet-scale key-loss, issuer-compromise, network-partition, recovery, and out-of-band licensing exercises."],"scores":{"adversaryRealism":{"value":5,"label":"Nation-state","rationale":"The paper explicitly includes well-funded physical attackers, supply-chain participation, cryptographic surprises, key compromise, and an ambitious nation-state case. The score reflects the threat model, not demonstrated resistance."},"trustedDependencies":{"value":5,"label":"Extensive","rationale":"Security composes across physical layout, several circuit primitives, design and fabrication integrity, key custody, communications, and an external authorizer.","domainCount":5},"policyReach":{"value":5,"label":"Chip-wide control","rationale":"The mechanism conditions the accelerator's essential operations on continuing external authorization and is intended to govern large fleets."}},"evidence":[{"locator":"Embedded Off-Switches for AI Compute, Section 2, pp. 2-3","supports":"Distributed dead-man-switch architecture, nonce-license flow, usage allowance, and critical-logic gating."},{"locator":"Section 3.1-3.3, pp. 3-4","supports":"TRNG, hardwired public keys, ECDSA implementation, placement, and the approximately 0.5 percent transistor-area estimate."},{"locator":"Section 4 and Tables 1-2, pp. 4-7","supports":"Security goals, adversaries, physical and logical attacks, supply-chain risk, authorization-key risk, and network disruption."},{"locator":"Section 4.1 footnote 3, p. 4; Section 6, p. 8","supports":"Authorization decisions are out of scope; integration, air-gap, trust, and legitimate-blocking caveats."}],"relatedIds":["OL-02","FM-04","HG-08"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"OS-00","category":"Control","title":"Ten thousand off-switches","proposition":"Distribute thousands of dead-man switches through critical accelerator logic, each requiring fresh cryptographic licenses and halting its local operations when its usage allowance reaches zero.","finding":"Replaces one remotely governed kill switch with a small on-die civilization of them, each waiting for permission to add.","assumption":"Ten thousand license-checking blocks can occupy critical paths without becoming a yield, verification, reliability, availability, key-management, or common-mode failure spectacular.","load":5,"maturity":"Proposed","source":"Embedded Off-Switches for AI Compute","publisher":"Petrie","year":"2025","url":"https://arxiv.org/pdf/2509.07637"}},{"id":"IV-10","slug":"the-honest-twin-server","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":true,"synopsis":"A sampled-output verification system targets one specific exfiltration channel: a compromised inference server hiding model data steganographically in ordinary text responses. A trusted path logs each input, output, seed, model release, and code version; an isolated verifier replays a secret random sample and scores whether tokens are plausible under valid fixed-seed nondeterminism. The result is a detector and rate limiter for covert response manipulation, not a standalone system for preventing model theft.","mechanism":{"goal":"Detect or sharply slow steganographic model-weight exfiltration through normal LLM inference responses while tolerating honest nondeterminism.","steps":["Force every outbound inference response through an API path that securely logs its paired input, output, seed, model release, and code version.","Privately select a random subset of records for audit and replay them on an isolated trusted model and codebase.","Estimate fixed-seed sampling likelihood and token rank to distinguish valid implementation variance from attacker-selected tokens.","Aggregate suspicious scores and trigger audit, gating, regeneration, or rate limits according to a deployment-specific policy."],"output":"Token- or message-level suspiciousness findings and information-theoretic bounds on the capacity of an attacker who stays beneath the chosen detector threshold."},"claimBoundary":{"establishes":["A formal security game and bounded covert-channel capacity under stated assumptions.","A replay-based detector designed around residual nondeterminism after fixing the prompt, model, stack, and sampling seed.","Empirical false-positive and exfiltratable-information trade-offs on several open-weight models and one production-style inference stack."],"remainsExternal":["Protection against physical theft, developer and backup channels, side channels, distillation, and any outbound path not captured by the trusted gateway.","Integrity of the verifier, logger, secret audit sampler, inference randomness, model artifacts, and egress architecture.","The escalation rule that converts a suspicious score into a safe operational response."]},"threatModel":{"asset":"Proprietary model weights resident on an inference server.","adversary":"A fully corrupted inference server coordinating with an outside receiver, plus external users who may control queries, sampling parameters, seeds, and query rate within the baseline game.","capabilities":["Arbitrarily alter or encode information in outbound inference messages.","Coordinate prompts, preprocessing, encoding, and decoding with an outside party.","Exploit the full response volume and the honest model's residual token variability."],"exclusions":["Unrestricted physical access and side channels such as timing, cache, power, developer laptops, backups, and direct device theft are excluded from the core game.","Every permitted output is assumed to have a valid paired input and traverse the monitored API interface.","The paper explicitly says the scheme does not prevent weight exfiltration generally; it detects steganographic messages and must sit inside a larger defense."],"enforcementBoundary":"The mechanism observes logged text responses at the API egress boundary. It does not control other data paths unless separate operational controls close them."},"trustRegister":[{"domain":"Complete logging and egress mediation","requirement":"Every transmitted response and its true input, output, seed, and artifact versions are appended correctly to tamper-evident storage.","failure":"The attacker sends through an unlogged path or gives the verifier an honest-looking record different from what left the data center.","sourceTreatment":"central"},{"domain":"Verification server","requirement":"The replay server executes faithful code, holds correct artifacts, and is independently protected from the inference-server compromise.","failure":"A shared compromise suppresses findings or turns the verifier into another exfiltration route.","sourceTreatment":"central"},{"domain":"Audit selection","requirement":"Sampling remains private, unpredictable, and non-malleable.","failure":"The attacker confines payloads to outputs it knows will not be checked.","sourceTreatment":"central"},{"domain":"Randomness and reproducibility","requirement":"Inference coins are trusted, bound to requests, not grindable, and reproducible closely enough for calibrated fixed-seed scoring.","failure":"Seed steering becomes an accepted covert channel, or implementation drift produces false alarms and blind spots.","sourceTreatment":"central"},{"domain":"Operational response","requirement":"A deployment selects aggregation thresholds and acts before accumulated leakage becomes unacceptable.","failure":"Accurate suspiciousness scores remain observations rather than effective containment.","sourceTreatment":"discussed"}],"authoredCaveats":["The scheme is not a standalone defense and only detects steganographic messages; the paper separately lists side-channel, development, backup, operational, and distillation defenses.","A compromise serious enough to control inference requires meaningful independent protection for the verification server, potentially including TEEs or air-gapping.","There is no universally correct way to pool token scores across users, requests, GPUs, or time; escalation is system-dependent.","Exact inference-stack details, sampler state, speculative decoding, and numerical nondeterminism materially affect replay requirements."],"assessment":{"assuranceTransfer":"The verifier can estimate whether a logged token sequence is plausible under a trusted replay distribution. The narrow exfiltration bound follows only after assurance is transferred through complete egress capture, honest artifacts and execution, secret sampling, non-malleable randomness, calibrated nondeterminism, and timely response.","loadBearingSequence":["All attacker-controlled outbound text is paired with the true input and committed to an immutable log.","The attacker cannot predict which records will be replayed or steer the inference randomness.","A separately trusted stack reproduces the relevant distribution closely enough to distinguish payload choices from benign variance.","Aggregation and intervention occur before the permitted covert-channel capacity becomes a consequential leak."],"joke":"The compromised inference server is supervised by an uncompromised inference server, whose principal security feature is having fewer opportunities to speak."},"tests":["Run an end-to-end red team that controls inference and attempts logger bypass, record substitution, seed grinding, retry grinding, and adaptive evasion of secret sampling.","Measure calibration drift across production kernels, quantization, batching, MoE routing, speculative decoding, upgrades, and hardware generations.","Compromise each trusted component in turn—the gateway, ledger, audit selector, verifier, artifact store, and RNG—and measure the resulting leakage bound.","Test operational pooling and response policies against slow leakage spread across users, GPUs, and long time windows."],"scores":{"adversaryRealism":{"value":3,"label":"Bounded insider","rationale":"The inference server and outbound text are fully adversarial, but the core game deliberately excludes physical, side-channel, and alternative operational exfiltration paths and trusts several adjacent systems."},"trustedDependencies":{"value":5,"label":"Extensive","rationale":"The result depends jointly on complete egress logging, immutable records, an independent replay stack, artifact fidelity, secret sampling, trusted randomness, and effective intervention.","domainCount":5},"policyReach":{"value":2,"label":"Channel-specific","rationale":"The mechanism narrowly addresses steganographic leakage through ordinary inference responses and explicitly disclaims comprehensive exfiltration prevention."}},"evidence":[{"locator":"Verifying LLM Inference to Detect Model Weight Exfiltration, version 3, Section 4 and Section 4.2, pp. 8-10","supports":"Formal game, fully corrupted inference server, side-channel and physical exclusions, trusted verifier, logger, audit sampling, and paired messages."},{"locator":"Sections 5-6, pp. 10-16","supports":"Logging, sampled replay, fixed-seed scoring, theoretical bounds, implementation, pooling, and sampling architecture."},{"locator":"Section 8, pp. 18-19","supports":"Independent-verifier challenge, air-gap option, non-standalone status, and steganographic-only boundary."},{"locator":"Appendix E, pp. 27-29; Appendices K-L, pp. 40-42","supports":"Detailed trust assumptions, trusted randomness, alternative exfiltration channels, and the larger defense portfolio."}],"relatedIds":["WV-06","RT-09"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"IV-10","category":"Workload","title":"The honest twin server","proposition":"Log every prompt, output, seed, model release, and code version, then have an isolated trusted server re-run a random sample to detect model weights hidden steganographically in responses.","finding":"Secures a compromised inference stack with an honest twin, a perfect diary, trusted randomness, and a strict rule that stolen weights may leave only through the chat window.","assumption":"Every outbound response is logged faithfully, audit selection stays secret, seeds cannot be steered, the reference stack remains reproducible, and the verifier is neither compromised nor a new exfiltration route.","load":5,"maturity":"Research agenda","source":"Verifying LLM Inference to Detect Model Weight Exfiltration","publisher":"Rinberg et al.","year":"2026","url":"https://arxiv.org/pdf/2511.02620"}},{"id":"LV-01","slug":"geography-by-ping-time","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"This survey proposes several possible location-verification ingredients rather than a finished system. In its main internet design, a uniquely keyed chip answers timed cryptographic challenges from known landmark servers; measured delays become distance estimates and several estimates become a probable region. Network-topology data or satellite services can add corroboration. The output is therefore authenticated, calibrated location evidence—not a direct sensor reading or exact proof of jurisdiction.","mechanism":{"goal":"Let a chip owner demonstrate possession and location for export-control compliance, or let secure hardware restrict operation based on an inferred location.","steps":["A chip holding a device-unique private key establishes encrypted sessions with multiple landmarks in known locations.","Landmarks issue challenges, authenticate the chip's signed responses, and measure response delay.","A calibrated model converts delays to distance estimates and combines several landmarks into a likely location region.","Traceroute, DNS, ISP topology data, repeated measurements, or satellite links may corroborate the estimate before an external policy action."],"output":"An authenticated, probabilistic estimate or bound on a chip's location, with accuracy determined by routing, calibration, landmark integrity, and key protection."},"claimBoundary":{"establishes":["A design space connecting authenticated challenge-response protocols to existing internet-geolocation methods.","A clear inventory of timing manipulation, landmark compromise, key extraction, and physical tampering attacks.","Open questions for accuracy, false positives, scalability, satellite cost, landmark security, secure memory, and air-gapped deployments."],"remainsExternal":["Empirical evidence that the proposed combination reaches policy-useful accuracy at borders and across heterogeneous global networks.","A deployable secure-key and anti-tamper implementation for an owner with physical access.","The confidence threshold, appeals process, and separate enforcement mechanism used when location evidence is uncertain."]},"threatModel":{"asset":"The integrity and availability of location evidence used for chip possession claims or export-control decisions.","adversary":"A chip owner or operator willing to manipulate networking or physically tamper with the device, potentially assisted by an ISP, plus attackers targeting landmark servers.","capabilities":["Speed or delay responses using private terrestrial links, satellite routes, congestion manipulation, or collusion with a network provider.","DDoS landmarks or compromise their clocks, timestamps, calibration, or physical security.","Extract the chip's private key and clone the responder onto a device in another location."],"exclusions":["The location section does not select one end-to-end implementation, attacker budget, accuracy target, or acceptable false-positive rate.","Policy enforcement is optional and separate: the section allows either an external authority to act or the chip to restrict itself."],"enforcementBoundary":"Challenge-response ends at a location estimate. Any operating restriction depends on a separate tamper-resistant controller or licensing mechanism and an external rule mapping uncertainty to action."},"trustRegister":[{"domain":"Chip identity and key custody","requirement":"The responding private key remains bound to the original chip and unreadable to its owner.","failure":"A cloned key lets a compliant-location proxy answer for a diverted chip.","sourceTreatment":"central"},{"domain":"Landmark infrastructure","requirement":"Enough landmarks have known locations, accurate clocks, honest calibration, and strong cyber and physical security.","failure":"Compromised or unavailable landmarks bias the inferred region or eliminate coverage.","sourceTreatment":"central"},{"domain":"Network calibration","requirement":"Observed delay remains a sufficiently stable and conservative proxy for distance across routes and congestion states.","failure":"Special routes or ordinary variability create jurisdiction-changing false negatives or operational false positives.","sourceTreatment":"central"},{"domain":"Physical tamper resistance","requirement":"The owner cannot alter the protocol, extract secrets, or bypass any linked restriction logic.","failure":"Cryptographically authentic responses no longer describe the regulated physical device.","sourceTreatment":"discussed"},{"domain":"Policy interpretation","requirement":"A regulator converts probabilistic regions and failed measurements into proportionate, reviewable decisions.","failure":"Network noise becomes shutdown authority, or conservative uncertainty makes legitimate systems unavailable.","sourceTreatment":"mentioned"}],"authoredCaveats":["Internet delay varies with routing directness, congestion, and local conditions; converting delay to distance and then to location remains technically difficult.","Faster-than-expected routes, ISP collusion, compromised landmark clocks, DDoS, and extracted chip keys are identified attacks.","Satellite approaches add antennas, service cost, secure-clock needs, and their own spoofing assumptions.","Accuracy near controlled borders, false-positive handling, million-chip scalability, secure memory, and air-gap compatibility are all left as open research questions."],"assessment":{"assuranceTransfer":"A signature establishes which key answered, and timing supplies a path-dependent delay. Treating those facts as physical geography transfers assurance through key-to-device binding, landmark integrity, conservative delay calibration, route diversity, tamper resistance, and a policy rule for uncertainty.","loadBearingSequence":["A non-exportable key binds each timed response to the regulated chip.","Several honest landmarks measure delays that an adversary cannot strategically shorten or recalibrate.","Network-dependent bounds combine into a region precise enough to distinguish the relevant jurisdictions.","A separate trusted mechanism turns that probabilistic result into a proportionate compliance action."],"joke":"The signature proves which chip answered; the route is then invited to prove where it was standing."},"tests":["Run a preregistered global field trial, especially near borders, reporting false-positive and false-negative rates across congestion, routing changes, and outages.","Give red teams dark fiber, satellite links, ISP cooperation, relays, and knowledge of landmark placement to test whether they can move the inferred jurisdiction.","Compromise subsets of landmark clocks and calibration data while DDoSing others to validate Byzantine and availability claims.","Test private-key extraction and responder cloning against the proposed secure memory and physical package, then repeat at million-device service scale."],"scores":{"adversaryRealism":{"value":4,"label":"Strong but open","rationale":"The source squarely considers malicious owners, physical tampering, key cloning, ISP collusion, landmark compromise, and DDoS, but leaves attacker budgets and a unified implementation open."},"trustedDependencies":{"value":5,"label":"Extensive","rationale":"The result composes chip keys and packaging with distributed clocks, routing and calibration models, optional topology or satellite providers, and an external enforcement rule.","domainCount":5},"policyReach":{"value":4,"label":"Jurisdictional","rationale":"The evidence can determine export-control treatment or chip availability across national boundaries, although the location mechanism itself only emits an estimate."}},"evidence":[{"locator":"Hardware-Enabled Mechanisms for Verifying Responsible AI Development, Section 2.4.2, pp. 14-15","supports":"Landmark challenge-response, signed replies, delay-distance calibration, triangulation, topology corroboration, and satellite options."},{"locator":"Section 2.4.3, p. 15","supports":"Timing manipulation, private routes, ISP collusion, landmark attacks, physical tampering, key extraction, and cloning."},{"locator":"Section 2.4.4, pp. 15-16","supports":"Open questions on accuracy, false positives, scalability, satellite feasibility, secure memory, and air gaps."},{"locator":"Sections 3.1.1 and 3.2.2, pp. 18 and 20-21","supports":"Owner-as-attacker model and the warning that existing components were designed for different threats and require rigorous testing."}],"relatedIds":["OL-02","WV-06"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"LV-01","category":"Location","title":"Geography by ping time","proposition":"Estimate where an accelerator lives by timing cryptographic challenges between the chip and trusted landmark servers.","finding":"The smuggled object is invited to participate in the investigation of where the smuggled object is.","assumption":"Relays, routing, endpoint compromise, and physical access can all be made less interesting than the speed of light.","load":5,"maturity":"Research agenda","source":"Hardware-Enabled Mechanisms for Verifying Responsible AI Development","publisher":"O’Gara et al. / TAIG","year":"2025","url":"https://openreview.net/pdf?id=JgxkV2jzzk"}},{"id":"OL-02","slug":"rent-to-run-silicon","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"A hardened on-chip security module requires a periodically renewed, chip-specific operating license. A compute vendor signs a short authorization binding an immutable device ID to permitted functions and duration; firmware interprets it and limits or disables operations after expiry. The dead-man design avoids relying on a shutdown command that an uncooperative operator could block, and licenses may travel over a network or controlled physical media.","mechanism":{"goal":"Deny or limit use of export-controlled data-center AI chips after diversion, prohibited use, or refusal to participate in required verification.","steps":["Bind a hardened security module to an immutable chip identity and manufacturer-approved firmware through secure boot.","Have the vendor or regulator issue a cryptographically signed license specifying that chip's permissions and validity window.","Deliver the license by an appropriate channel, including controlled physical media for an air-gapped site, and verify it on chip.","Track elapsed authorization by a secure timer or compute allowance and limit or disable the accelerator when renewal is absent."],"output":"A hardware-enforced decision about whether the identified chip may boot, operate, or expose specified capabilities under the most recent signed license."},"claimBoundary":{"establishes":["A policy and reference-architecture proposal built from secure boot, signed licenses, immutable identity, remote attestation, and a hardened module.","Why license expiry is harder for an operator to block than an active remote shutdown command.","A staged threat-model framework spanning minimally, covertly, and openly adversarial physical possession."],"remainsExternal":["The factual and legal process for deciding that an export condition was breached and whether access should be revoked or restored.","A demonstrated tamper-proof implementation for leading AI accelerators under a well-resourced physical attacker.","Operational guarantees for issuer outages, key compromise, mistaken revocation, ownership changes, and recovery at fleet scale."]},"threatModel":{"asset":"Remote control over whether high-performance exported chips can operate, without turning the privileged mechanism into a new security, privacy, or availability hazard.","adversary":"An operator with physical possession, ranging from a low-motivation commercial actor to a covertly cheating company and an openly adversarial state-linked actor willing to spend heavily.","capabilities":["Block communications, alter firmware or software, manipulate power and timing, and conduct invasive physical attacks.","Search for one scalable firmware or module vulnerability across many chips.","Compromise privileged components or keys to bypass restrictions or misuse the control plane."],"exclusions":["The proposal is aimed primarily at specialized data-center AI chips; consumer-GPU licensing is described as limited and speculative.","An operating license proves that an issuer authorized a chip, not that the underlying allegation, end-user identity, location, or use is correct.","The mechanism need not provide open-internet monitoring and does not itself decide policy."],"enforcementBoundary":"The security module can enforce a signed license at boot and during operation. Detection of a violation, attribution to an owner, authorization policy, and redress remain in supply-chain, regulatory, and institutional systems."},"trustRegister":[{"domain":"Security module and firmware","requirement":"The privileged module, secure boot chain, license parser, and disable path remain correct and unbypassable.","failure":"One reusable vulnerability unlocks fleets or gives an attacker a privileged control plane.","sourceTreatment":"central"},{"domain":"Identity, time, and metering","requirement":"Immutable chip identity and the license-expiry measure survive reset, clock, power, and physical manipulation.","failure":"A chip replays another license or extends its authorization indefinitely.","sourceTreatment":"central"},{"domain":"Issuer and key custody","requirement":"The signing authority remains secure, available, correctly scoped, and able to rotate or recover keys.","failure":"Key theft grants unauthorized operation; outage or error disables legitimate infrastructure.","sourceTreatment":"discussed"},{"domain":"Physical security and inspection","requirement":"Tamper evidence plus inspections deter covert actors, while stronger packaging defeats actors who cannot be deterred.","failure":"Physical possession converts the license check into an optional feature.","sourceTreatment":"central"},{"domain":"Governance and supply-chain records","requirement":"Chip ownership, end users, violations, and revocation decisions are accurate, legitimate, coordinated, and reviewable.","failure":"The mechanism enforces the wrong policy against the wrong device with silicon-level finality.","sourceTreatment":"mentioned"}],"authoredCaveats":["Commercial security technology is not generally designed for a well-resourced attacker with physical access; physical security is the principal technical challenge.","Accurate, hack-proof, tamper-proof time is described as very difficult; clock-cycle counting or fail-closed power-loss behavior are proposed alternatives.","Tamper-proof packages suitable for AI chips were not available, and their eventual feasibility is described as likely but uncertain.","The report highlights surveillance, backdoor, and third-party misuse concerns, the rapid bypass of NVIDIA's mining limiter, and the limits of comparisons with Apple's Secure Enclave."],"assessment":{"assuranceTransfer":"A valid license establishes that whoever controls the signing key authorized the identified chip under encoded terms. Concluding that operation is lawful or safe transfers assurance through tracking and detection, issuer legitimacy, key custody, firmware correctness, tamper resistance, delivery availability, and a redress process outside the chip.","loadBearingSequence":["A trustworthy authority maps external evidence and law to a chip-specific signed decision.","Keys, delivery, immutable identity, and expiry measurement preserve that decision without accidental fleet denial.","The module gates all relevant operation and survives software, firmware, power, timing, and physical attacks.","Inspection and sanctions deter covert tampering, or packaging technically defeats an undeterrable actor."],"joke":"The module can determine precisely whether permission arrived; whether permission should exist remains hosted in a larger system called government."},"tests":["Prototype the full disable path and red-team it with firmware, voltage, clock, reset, invasive physical, and supply-chain attacks under each stated threat tier.","Chaos-test licensing outages, partitions, expired and malformed licenses, key rotation, issuer compromise, mistaken revocation, and safe restoration across a large cluster.","Demonstrate that chip IDs and compute-based expiry cannot be cloned, rolled back, paused, or transferred during resale and repair.","Exercise end-to-end ownership tracking, violation adjudication, inspection, appeal, and recovery so the enforcement mechanism is tested with its actual institutional dependencies."],"scores":{"adversaryRealism":{"value":5,"label":"Physical and strategic","rationale":"The report explicitly tiers attackers through openly adversarial, well-resourced actors with physical possession and recognizes scalable software attacks, privileged-module misuse, and imperfect deterrence."},"trustedDependencies":{"value":5,"label":"Extensive","rationale":"Licensing composes module security, secure boot, identity, metering, keys, delivery, packaging, inspections, supply-chain tracking, and regulatory decision-making.","domainCount":5},"policyReach":{"value":5,"label":"Remote sovereign control","rationale":"The mechanism lets an external issuer condition basic accelerator availability on continuing authorization for export-control and potentially wider governance purposes."}},"evidence":[{"locator":"Secure, Governable Chips, 'Operating Licenses to Prevent Unauthorized Use,' pp. 10-11","supports":"Periodic chip-specific licenses, feature restrictions, dead-man expiry, export-control use cases, and offline delivery."},{"locator":"'Security Modules,' pp. 15-16","supports":"Signed license format, immutable ID, firmware enforcement, weekly or monthly expiry, timer difficulty, compute counting, and power-loss handling."},{"locator":"'Privacy, Surveillance, and Cybersecurity Implications' and 'Overview of Threat Models and Defenses,' pp. 18-21","supports":"Misuse concerns, restricted module access, physical-access threat tiers, inspections, deterrence, and need for tamper-proofing."},{"locator":"'Limitations and Conclusion,' pp. 25-26","supports":"Hard-to-assess invasive attacks, imperfect Secure Enclave analogy, uncertainty, and development timeline."}],"relatedIds":["OS-00","FM-04","LV-01"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"OL-02","category":"Control","title":"Rent-to-run silicon","proposition":"Require a periodically renewed operating license before a data-centre AI chip is allowed to function.","finding":"Turns the accelerator into enterprise software, then gives the license server a foreign-policy portfolio.","assumption":"The issuer stays reachable, legitimate, secure, aligned, and never has a very complicated Tuesday.","load":5,"maturity":"Proposed","source":"Secure, Governable Chips","publisher":"CNAS","year":"2024","url":"https://www.cnas.org/publications/reports/secure-governable-chips"}},{"id":"FS-03","slug":"the-approved-friend-group","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"Fixed Set is a proposed export-control mechanism for limiting the scale of accelerator clusters without prohibiting the export of every useful chip. A root of trust admits high-bandwidth communication only among a preauthorised pod, while communication beyond that pod is throttled. This can enforce a network topology if every consequential path is covered; it does not by itself establish what computation occurs or whether a slower, wider system remains capable enough.","mechanism":{"goal":"Keep exported accelerators useful in small systems while preventing their aggregation into a frontier-scale supercomputer.","steps":["Preauthorise a small set of chip identities and bind the set to a hardware root of trust.","Permit unrestricted high-bandwidth links only among members of that set.","Throttle every communication path outside the set to a policy-defined bandwidth ceiling.","Use integrity checks, secure firmware and possibly remote attestation so unauthorised membership or configuration changes cause refusal to operate."],"output":"A hardware-enforced claim about which devices may exchange data at high bandwidth, plus an external-bandwidth ceiling for the covered system."},"claimBoundary":{"establishes":["The covered interconnect accepted only preauthorised peer identities.","Covered external traffic remained below the configured bandwidth limit.","A detected unauthorised configuration can trigger refusal to operate."],"remainsExternal":["Whether every usable communication path, including CPUs, NICs, switches and storage paths, is actually covered.","Whether the chosen pod size and bandwidth ceiling prevent a policy-relevant training run as algorithms change.","Whether unrestricted, older or indigenous hardware supplies an adequate substitute.","Whether the authorised set and export policy are legitimate, current or correctly administered."]},"threatModel":{"asset":"The peer-membership restriction, external-bandwidth limiter, device identities and roots of trust that define the pod boundary.","adversary":"A chip owner with physical custody, ranging from a commercially motivated operator to a state actor with failure-analysis equipment and supply-chain access.","capabilities":["Firmware exploitation, key theft, protocol manipulation and resource pooling.","Side-channel analysis, fault injection and package-level tampering.","Focused-ion-beam editing, reverse engineering and attacks repeated across many chips.","Communication-efficient or decentralised training that reduces dependence on the restricted links."],"exclusions":["Cybersecurity of manufacturers, public-key infrastructure and government authorities is largely outside the working paper's HEM analysis.","Equivalent compute obtained from chips without the mechanism is acknowledged but not directly analysed.","The paper does not specify a final device architecture or a settled policy bandwidth threshold."],"enforcementBoundary":"The mechanism reaches only interfaces brought inside the preauthorised system boundary; uncovered data paths and compute outside equipped products remain beyond it."},"trustRegister":[{"domain":"Identity and roots of trust","requirement":"Every pod member must possess an unforgeable identity bound to the authorised set.","failure":"A cloned identity or compromised root admits an unauthorised accelerator at full bandwidth.","sourceTreatment":"central"},{"domain":"Interface completeness","requirement":"All high-value paths through accelerators, CPUs, NICs and switches must enforce the same boundary.","failure":"One uncovered interface becomes the inter-pod network.","sourceTreatment":"discussed"},{"domain":"Policy-to-bandwidth mapping","requirement":"The pod-size and bandwidth settings must remain restrictive for relevant training methods while preserving allowed uses.","failure":"The rule either permits the targeted workload or disables legitimate applications.","sourceTreatment":"central"},{"domain":"Hardware and firmware integrity","requirement":"Self-tests, secure firmware and physical protections must resist a custodian with access to the device.","failure":"A scalable bypass converts the fixed set back into ordinary networking.","sourceTreatment":"central"},{"domain":"Fleet coverage","requirement":"Equipped chips must constitute enough of the adversary's available compute for the restriction to matter.","failure":"The workload migrates to unrestricted or substitute hardware.","sourceTreatment":"discussed"}],"authoredCaveats":["The mechanism does not yet exist, and the paper offers a rough outline rather than a specific implementation (Chapter 7, pp. 51–53).","The correct external-bandwidth limit and maximum set size are open questions with substantial permitted-use costs (p. 54).","Communication-efficient and decentralised training directly weaken the mechanism's premise (p. 55).","Effectiveness hinges on securely restricting high-bandwidth communication to verified devices; a compromise could make the mechanism ineffective (pp. 55–56).","The authors state that they lack enough confidence to recommend HEM deployment and call for further architecture and threshold research (pp. 58–59)."],"assessment":{"assuranceTransfer":"A narrow and testable network-control property is asked to carry a broader claim about effective compute aggregation. The transfer holds only if interface coverage is complete and the policy threshold continues to track training practice.","loadBearingSequence":["Device identity remains unforgeable under owner custody.","Every useful high-bandwidth path enforces pod membership.","The external limit materially penalises future training algorithms.","Alternative hardware and longer training schedules do not erase the imposed cost."],"joke":"International order is rendered as an access-control list, with hardware replacement awaiting approval from the seating committee."},"tests":["Inventory every physical and logical data path and demonstrate that no unmetered route can join two pods.","Benchmark frontier-relevant distributed training across the proposed ceiling, including communication compression and infrequent synchronisation.","Attempt identity cloning, firmware rollback, fault injection and a repeatable per-chip bypass under the stated adversary tiers.","Replace failed chips and change topology without creating an unaudited reauthorisation path.","Quantify false restriction and performance costs for hosted inference, scientific computing and other allowed workloads."],"scores":{"adversaryRealism":{"value":5,"label":"Explicitly adversarial","rationale":"The source models commercial, state-supported and state attackers with physical custody, and assumes sufficiently resourced protection can ultimately be circumvented."},"trustedDependencies":{"value":5,"label":"System-wide","rationale":"The claim depends on identity, firmware, every relevant interconnect, parameter-setting, physical security and fleet coverage composing correctly.","domainCount":5},"policyReach":{"value":4,"label":"Export-scale","rationale":"It would constrain cluster architecture after sale across consumer and data-centre products, while stopping short of inspecting workload content."}},"evidence":[{"locator":"Hardware-Enabled Governance Mechanisms, Chapter 7, pp. 50–54 (PDF pp. 61–65)","supports":"Fixed-set goal, preauthorised pod, roots of trust, external throttling and open parameter questions."},{"locator":"Hardware-Enabled Governance Mechanisms, Chapter 7, pp. 55–56 (PDF pp. 66–67)","supports":"Communication-efficient training, verified-device dependency and need for implementation-specific threat analysis."},{"locator":"Hardware-Enabled Governance Mechanisms, Chapter 4, pp. 22–31 (PDF pp. 33–42)","supports":"Physical and nonphysical attacks, actor tiers, scope exclusions and cost-imposition security model."},{"locator":"Hardware-Enabled Governance Mechanisms, Chapter 8, pp. 57–59 (PDF pp. 68–70)","supports":"Circumvention, adoption and substitute-hardware limits; authors' non-recommendation pending further work."}],"relatedIds":["WV-06","HG-08"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"FS-03","category":"Control","title":"The approved friend group","proposition":"Hard-code a fixed set of chips that may communicate with one another at high bandwidth.","finding":"A cluster topology, a supply chain, and international order are all frozen into one tasteful whitelist.","assumption":"Hardware failures, resale, topology changes, and creative interconnect engineers will respect the seating plan.","load":4,"maturity":"Proposed","source":"Hardware-Enabled Governance Mechanisms","publisher":"RAND Corporation","year":"2024","url":"https://www.rand.org/content/dam/rand/pubs/working_papers/WRA3000/WRA3056-1/RAND_WRA3056-1.pdf"}},{"id":"FM-04","slug":"mandatory-firmware-enlightenment","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"The proposed security module makes current, issuer-approved firmware and software a condition of accelerator operation. Secure boot and enforced updates can close known vulnerabilities and preserve a control plane after sale. They establish version approval, not code correctness, sound policy or issuer legitimacy; the same mechanism that improves patch adoption also makes update infrastructure part of the chip's availability boundary.","mechanism":{"goal":"Keep governance and security controls patchable, current and enforceable even when the hardware operator would prefer not to update.","steps":["Anchor manufacturer or controller keys in a dedicated hardened security module.","Verify firmware and software signatures and version state during secure boot and attestation.","Deliver authenticated updates when vulnerabilities or policy requirements change.","Block operation, or allow an associated licence to expire, when the approved current state is not present."],"output":"An enforcement decision that the covered chip is running an issuer-approved, sufficiently current software stack."},"claimBoundary":{"establishes":["The loaded image matches a key authorised by the configured trust root.","The version satisfies the controller's freshness policy.","Noncompliant version state can prevent the covered chip from operating."],"remainsExternal":["Whether signed and current code is free of exploitable bugs or implements the intended policy correctly.","Whether the update authority is legitimate, uncompromised and acting within an accepted mandate.","Whether update distribution and recovery remain available during outages, mistakes or political disputes.","Whether physical or supply-chain compromise has bypassed the boot and attestation path."]},"threatModel":{"asset":"The secure-boot chain, update and signing keys, freshness state, security-module code and operation gate.","adversary":"An operator ranging from a regulation-sensitive company to a covert commercial attacker or openly adversarial state-linked custodian.","capabilities":["Exploit legitimate firmware, parsers, drivers or licence-validation logic without physical access.","Attempt rollback, fault injection, key extraction or compromise of remote attestation.","Physically alter the package or security module under unsupervised custody.","Target controller systems, verifiers, manufacturing or the signing ecosystem."],"exclusions":["The report leaves detailed implementation in specific use cases and their broader impacts to future work.","Manufacturing supply-chain compromise is acknowledged but placed outside the report's scope.","Malicious or mistaken policy updates and update-service availability are not developed as adversary cases."],"enforcementBoundary":"The gate governs the equipped accelerator's boot and continued licensed use; correctness of approved code and conduct of the approval authority sit above that boundary."},"trustRegister":[{"domain":"Root and signing keys","requirement":"Approval keys and update-signing processes must remain confidential, correctly scoped and recoverable.","failure":"A stolen or misused key turns malicious code into an approved update across the fleet.","sourceTreatment":"discussed"},{"domain":"Secure boot and freshness","requirement":"The module must measure the complete boot chain and reject rollback or stale state.","failure":"An operator boots a signed but vulnerable version or bypasses the gate.","sourceTreatment":"central"},{"domain":"Firmware correctness","requirement":"The approved image must actually be secure and enforce its stated policy.","failure":"Attestation faithfully reports the current version of exploitable code.","sourceTreatment":"central"},{"domain":"Physical integrity","requirement":"The security module and its connection to chip operation must withstand the relevant custody threat.","failure":"Tampering disables enforcement while leaving useful compute intact.","sourceTreatment":"central"},{"domain":"Update governance and availability","requirement":"Approval, revocation, distribution and emergency recovery must remain legitimate and available.","failure":"An outage or erroneous policy update becomes fleet-wide denial of service.","sourceTreatment":"not located"}],"authoredCaveats":["The report is a platform sketch and leaves rigorous implementation and broader impacts of specific uses for future work (p. 9).","Secure boot can prove that firmware is legitimate without proving it is vulnerability-free; substantial code remains notoriously difficult to secure (Appendix B, p. 28).","Formal verification reduces bugs but does not make the full compiler, hardware and software stack unhackable (Appendix B, p. 28).","Current hardware may contain unpatchable weaknesses and is not fully trustworthy in covertly adversarial settings without monitoring and legal deterrence (p. 22).","Robust security modules and physical protections require years of development and testing, especially for openly adversarial custody (pp. 21–22)."],"assessment":{"assuranceTransfer":"The mechanism turns an authentic version identifier into permission to operate. That is strong update enforcement, but its governance value depends on the much larger proposition that the issuer-approved image, policy and issuer are all correct at the same time.","loadBearingSequence":["The immutable trust root authenticates the intended authority.","The measured boot chain covers every path that can control the chip.","The approved update is secure and policy-correct.","Distribution and recovery remain available before enforcement blocks operation."],"joke":"The patch Tuesday change-control board is given a direct electrical vote on whether the accelerator may wake up."},"tests":["Attempt rollback, partial update, power interruption and alternate boot paths across every firmware-bearing component.","Compromise a signing tier in a red-team exercise and measure blast radius, revocation speed and recovery without a second trusted path.","Model update-service and network outages, including safe grace periods and air-gapped deployment.","Ship a correctly signed but deliberately vulnerable policy image and verify that attestation does not overstate what approval proves.","Fault-inject or physically bypass the operation gate while preserving accelerator functionality."],"scores":{"adversaryRealism":{"value":4,"label":"Context-sensitive","rationale":"The source distinguishes minimally, covertly and openly adversarial custody and is candid about software and physical compromise, but gives less treatment to a compromised or mistaken update authority."},"trustedDependencies":{"value":5,"label":"Control-plane dense","rationale":"Keys, secure boot, firmware correctness, physical integrity and an available update-governance process all sit on the critical path.","domainCount":5},"policyReach":{"value":5,"label":"Fleet-wide","rationale":"The architecture can update policy after sale and deny operation across all equipped high-performance accelerators."}},"evidence":[{"locator":"Secure, Governable Chips, 'What Would Effective On-Chip Governance Look Like?', p. 9 (PDF p. 12)","supports":"Security-module architecture, forced freshness, blocking behaviour and adaptive policy updates."},{"locator":"Secure, Governable Chips, 'Timelines for Technical Development of Security Features', pp. 21–22 (PDF pp. 24–25)","supports":"Development stages, current-hardware limits and requirements across threat contexts."},{"locator":"Secure, Governable Chips, Appendix B, pp. 28–30 (PDF pp. 31–33)","supports":"Firmware fallibility, enforced-update rationale, physical protections, supporting ecosystem and supply-chain exclusion."},{"locator":"Secure, Governable Chips, 'Viability in Adversarial Contexts', pp. 19–20 (PDF pp. 22–23)","supports":"Three adversarial contexts, tamper evidence, tamper proofing and cost-imposition framing."}],"relatedIds":["OL-02","OS-00","RT-09"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"FM-04","category":"Control","title":"Mandatory firmware enlightenment","proposition":"A hardened module checks that firmware and policy are current, blocking operation when they are not.","finding":"A security update mechanism is promoted to constitutional law, with uptime determined by successful compliance.","assumption":"The control plane will be less exploitable, politicised, and fallible than every control plane before it.","load":5,"maturity":"Proposed","source":"Secure, Governable Chips","publisher":"CNAS","year":"2024","url":"https://www.cnas.org/publications/reports/secure-governable-chips"}},{"id":"CM-05","slug":"flops-with-a-notary-stamp","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"On-chip metering would turn accelerator operations into authenticated counts that can support reporting, licences or automatic caps. The source compares distributed security blocks, an enclosed guarantee processor and adapted performance counters, and rates all governance-grade variants as R&D. Even a perfect counter measures events under a chosen accounting rule; capability, risk, run boundaries and compute performed elsewhere remain policy and system questions.","mechanism":{"goal":"Produce trustworthy per-chip compute measurements for threshold-based reporting, verification or enforcement.","steps":["Observe selected arithmetic instructions or data transfers using embedded blocks, an auxiliary guarantee processor or adapted performance counters.","Maintain a tamper-resistant running total or decrementing usage allowance across resets and power loss.","Bind the measurement to a device identity and authenticate it for a verifier.","Aggregate covered measurements into a training-run record, or trigger licensing and halt logic at a configured threshold."],"output":"An authenticated count, allowance state or threshold event for operations visible to the covered meter."},"claimBoundary":{"establishes":["How many meter-defined events the covered accelerator observed.","Whether that local counter crossed a configured numerical threshold.","Which attested device produced a reported count, assuming the key and meter remain intact."],"remainsExternal":["Whether the events belong to one legally defined training run across chips, providers and time.","Whether counted FLOPs correspond to model capability, risk or regulatory intent.","Whether distillation, fine-tuning, inference-time scaling or algorithmic efficiency moves the activity outside the chosen boundary.","Whether undeclared or unequipped compute completed part of the workload."]},"threatModel":{"asset":"The event tap, counter state, device key, aggregation rule and any licence or halt path driven by the count.","adversary":"Commercial, well-resourced non-state and nation-state operators, including actors with physical possession and incentives to structure work around thresholds.","capabilities":["Modify firmware, reset exposed counters or exploit licence logic.","Use side channels, voltage or laser glitching, probing and focused-ion-beam editing.","Split training across providers, chips or declared runs and disguise communication patterns.","Gain algorithmic efficiency, distil a larger model or move consequential work to fine-tuning and inference."],"exclusions":["The taxonomy reports public designs rather than a functional prototype of its own.","The performance cost of mediating all I/O through the enclosed guarantee processor is unresolved.","The source treats capability- or output-based evaluation as a needed supplement, not something the meter supplies."],"enforcementBoundary":"The mechanism observes only events exposed to meters on equipped hardware; run aggregation and the legal meaning of the count are outside the counter."},"trustRegister":[{"domain":"Measurement semantics","requirement":"The selected hardware events must implement a complete, non-duplicative FLOP-accounting standard.","failure":"The meter is precise but counts the wrong policy object.","sourceTreatment":"central"},{"domain":"Counter integrity","requirement":"Counter state and event taps must resist reset, bypass, replay and physical manipulation.","failure":"Authentic reports contain attacker-controlled totals.","sourceTreatment":"central"},{"domain":"Device authentication","requirement":"Attestation keys and the reporting path must bind readings to the intended accelerator.","failure":"A verifier receives substituted or forged measurements.","sourceTreatment":"discussed"},{"domain":"Run and fleet aggregation","requirement":"Counts across chips, providers and time must be assigned to the correct regulated activity.","failure":"Structuring leaves every local report compliant while aggregate compute exceeds the threshold.","sourceTreatment":"discussed"},{"domain":"Threshold relevance","requirement":"The numerical threshold must continue to track the capability or risk that policy intends to govern.","failure":"Efficiency and lifecycle changes make the threshold obsolete or overinclusive.","sourceTreatment":"central"}],"authoredCaveats":["On-chip metering is rated 'requires R&D'; no functional prototype exists and deployment would lag development by years (§3.1, pp. 5–6).","Distributed blocks expose many physical targets, the enclosed processor creates a single point of failure, and adapted counters are weakest against adversaries (§3.1, pp. 5–6).","Algorithmic efficiency, distillation and ambiguous model boundaries can make static compute thresholds obsolete (§4.1, pp. 10–12).","Training can be structured across providers or decentralised over lower-bandwidth links to evade aggregation and reporting (§4.2, p. 12).","The proposed security standard is cost and tamper evidence rather than absolute prevention against nation-state custody (§4.3, pp. 12–13)."],"assessment":{"assuranceTransfer":"A protected counter can strengthen a factual claim about covered operations. The overreach begins when that count is treated as a self-interpreting measure of a model, a capability, a training run or compliance across an ecosystem.","loadBearingSequence":["The event definition matches the accounting standard.","Every relevant operation reaches an intact meter exactly as intended.","Authenticated local counts are completely aggregated into the regulated run.","The policy threshold remains meaningful despite technical change."],"joke":"The arithmetic has acquired a notary; the definition of the transaction remains with counsel."},"tests":["Compare meter totals against independent traces across mixed precision, sparsity, recomputation and fused kernels.","Attempt reset, rollback, replay, event-tap bypass and fault injection under each proposed architecture.","Split a training objective across chips, providers, runs, fine-tuning and distillation and test whether aggregation reconstructs it.","Measure guarantee-processor throughput and latency while mediating worst-case accelerator I/O.","Backtest candidate thresholds against models with similar capabilities but substantially different training compute."],"scores":{"adversaryRealism":{"value":5,"label":"Explicitly tiered","rationale":"The source distinguishes three attacker tiers and directly addresses physical attacks, structuring, distributed training and algorithmic substitution."},"trustedDependencies":{"value":5,"label":"Cross-layer","rationale":"Measurement semantics, silicon integrity, authentication, aggregation and threshold policy must all compose before the count supports compliance.","domainCount":5},"policyReach":{"value":5,"label":"Treaty-scale","rationale":"The source positions metering as a foundation for domestic thresholds, licences and multilateral treaty verification."}},"evidence":[{"locator":"Hardware-Level Governance of AI Compute, §3.1 M5, pp. 5–6 (PDF pp. 5–6)","supports":"Three metering architectures, feasibility, overhead, counter adaptation and architecture-specific weaknesses."},{"locator":"Hardware-Level Governance of AI Compute, §§4.1–4.2, pp. 10–12 (PDF pp. 10–12)","supports":"Threshold obsolescence, accounting ambiguity, distillation and decentralised training."},{"locator":"Hardware-Level Governance of AI Compute, §4.3, pp. 12–13 (PDF pp. 12–13)","supports":"Adversary tiers, physical attack capabilities and tamper-evident security standard."},{"locator":"Hardware-Level Governance of AI Compute, §5.2, p. 16 (PDF p. 16)","supports":"Use of on-chip metering in domestic, bilateral and treaty scenarios."}],"relatedIds":["PT-07","HG-08","OS-00"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"CM-05","category":"Attestation","title":"FLOPs with a notary stamp","proposition":"Meter computation on-chip so regulated training runs can be identified and reported against thresholds.","finding":"Counts the arithmetic with great ceremony while capability, efficiency, fine-tuning, and distributed work move around it.","assumption":"The policy object remains measurable in the same units as the thing the hardware happens to count.","load":4,"maturity":"Speculative","source":"Hardware-Level Governance of AI Compute","publisher":"Ansari","year":"2026","url":"https://arxiv.org/abs/2604.04712"}},{"id":"WV-06","slug":"inspect-everything-reveal-nothing","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"Detailed workload verification proposes running a defined check inside a trusted execution environment so a developer can attest to a dataset, evaluation or model property without exposing the underlying code, weights or data. The useful output is a signed result from an approved protected execution. It does not automatically prove that the protected view covered the whole distributed workload, that omitted activity did not occur, or that the chosen predicate is an adequate compliance rule.","mechanism":{"goal":"Verify selected governance-relevant workload properties while preserving model, code and data confidentiality.","steps":["Define an evaluation or predicate and load it with the relevant workload material into a trusted execution environment.","Use hardware isolation to protect the verifier's test and the developer's model or data from each other and from the host.","Measure the protected execution and sign the result with a device-bound key held by a security module or TEE.","Validate the signature and approved code identity, then combine attestations where the workload spans multiple accelerators."],"output":"An authenticated statement that specified code produced a specified result over the inputs visible inside the attested environment."},"claimBoundary":{"establishes":["The reported result originated from the attested device and measured protected code, if the TEE and key hold.","The protected code evaluated the inputs made available within its execution boundary.","The parties can learn the agreed result without necessarily receiving the other's raw model, test or data."],"remainsExternal":["Whether all relevant shards, data, preprocessing, code and parallel workers entered the attested boundary.","Whether an unobserved parallel workload or omitted dataset was also used.","Whether the agreed test correctly captures the policy concept and cannot be gamed.","Whether confidentiality survives side channels, physical custody and the expanded monitoring interface."]},"threatModel":{"asset":"Integrity and confidentiality of the evaluation, workload inputs, attestation key, measurements and cross-device aggregation.","adversary":"A hardware operator who may falsify reports, shape or fragment workloads, compromise privileged software, or physically attack devices; the broader paper includes well-resourced and state-level actors.","capabilities":["Tamper with TEEs, meters or security modules to forge measurements or extract keys.","Exploit shared resources, side channels, firmware or the TEE interface.","Fragment work across accelerators, providers or data centres so no local view is complete.","Expose only selected inputs to the protected test while conducting undeclared activity elsewhere."],"exclusions":["The paper is a workshop-derived research agenda, not an implemented cluster-wide verification protocol.","Current physical security is not designed for untrusted operators with unsupervised access.","Legal authority, test selection and governance of verifier access remain institutional guardrails rather than TEE properties."],"enforcementBoundary":"The assurance ends at the data, code and devices included in the attested execution; completeness of the wider training process requires a separate cluster-wide protocol."},"trustRegister":[{"domain":"TEE isolation","requirement":"The protected environment must preserve integrity and confidentiality against host software, shared-resource and physical attacks.","failure":"The operator alters the test or learns secrets while still producing plausible attestation evidence.","sourceTreatment":"central"},{"domain":"Attestation identity","requirement":"A nonextractable device key and registry must bind the result to the intended hardware and code measurement.","failure":"A forged or substituted environment signs the desired result.","sourceTreatment":"central"},{"domain":"Input completeness","requirement":"Every governance-relevant data shard, transformation and workload component must be visible to the approved check.","failure":"The attestation is true about a curated subset and silent about the actual run.","sourceTreatment":"discussed"},{"domain":"Cluster composition","requirement":"Attestations across hundreds or thousands of devices must combine without gaps, substitution or selective reporting.","failure":"Trusted local statements fail to describe the distributed training job.","sourceTreatment":"central"},{"domain":"Predicate and policy","requirement":"The confidential test must faithfully operationalise the governance claim and resist strategic adaptation.","failure":"Correct execution certifies a weak or obsolete proxy.","sourceTreatment":"mentioned"}],"authoredCaveats":["The paper frames these mechanisms as open implementation questions requiring further work for robust, scalable solutions (abstract and executive summary, pp. 1–2).","Detailed verification across multi-node and multi-GPU systems remains an open research problem (§2.2.4, pp. 9–10).","Distributed pipeline and data parallelism mean only subsets of GPUs may interact with input data, complicating dataset verification (§2.2.4, p. 10).","More monitoring access increases confidentiality risk and attack surface, while integrated TEEs may add unacceptable latency (§4.2, p. 26).","Existing TEEs have known vulnerabilities and are not designed for untrusted operators with unsupervised physical access (§4.2, pp. 26–27)."],"assessment":{"assuranceTransfer":"A TEE can make execution evidence harder to forge and can conceal both sides' sensitive material. The leap is from 'this code ran on these presented inputs' to 'the complete real-world workload satisfied the intended policy.'","loadBearingSequence":["The measured code implements the intended confidential test.","TEE isolation and the attestation key survive operator custody.","All relevant workload inputs and devices are included.","Local signed results compose into a complete claim about the run."],"joke":"The verifier sees nothing, the operator reveals nothing, and the remaining systems problem is invited to compose itself privately."},"tests":["Run the protocol across pipeline, tensor and data parallelism while withholding one shard, worker or preprocessing stage.","Introduce a shadow workload outside the TEE and test whether the claimed negative property still verifies.","Exercise known side-channel, rollback, fault-injection and key-extraction classes against the target TEE and attestation path.","Measure end-to-end overhead and failure recovery at frontier-cluster scale rather than on one accelerator.","Use semantically equivalent but adversarially constructed datasets and models to test whether the predicate captures the policy claim."],"scores":{"adversaryRealism":{"value":4,"label":"Broad but unfinished","rationale":"The source includes physical custody, forged measurements, evasion and fragmentation, while leaving the concrete cluster-wide protocol and its exact adversary model as research questions."},"trustedDependencies":{"value":5,"label":"Composition-heavy","rationale":"TEE isolation, keys, predicate correctness, input completeness and cross-device composition must all hold for a workload-level conclusion.","domainCount":5},"policyReach":{"value":5,"label":"Content-level","rationale":"The proposed claims can reach datasets, model evaluations, training techniques and compute, not merely hardware identity or configuration."}},"evidence":[{"locator":"Hardware-Enabled Mechanisms for Verifying Responsible AI Development, §2.2, pp. 8–10 (PDF pp. 8–10)","supports":"Detailed workload verification mechanism, attack paths and distributed-system research questions."},{"locator":"Hardware-Enabled Mechanisms for Verifying Responsible AI Development, §1.2, p. 7 (PDF p. 7)","supports":"Governance, verifiability, sophisticated-attacker and privacy objectives."},{"locator":"Hardware-Enabled Mechanisms for Verifying Responsible AI Development, §4.1, p. 25 (PDF p. 25)","supports":"Trusted-module input-integrity limitation and key-protection requirements."},{"locator":"Hardware-Enabled Mechanisms for Verifying Responsible AI Development, §4.2, pp. 26–27 (PDF pp. 26–27)","supports":"TEE function, confidentiality trade-offs, latency, physical threat limits and multi-GPU composition gap."}],"relatedIds":["LV-01","RT-09","CM-05"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"WV-06","category":"Workload","title":"Inspect everything, reveal nothing","proposition":"Verify properties of training or inference workloads from inside trusted hardware while preserving data and model secrecy.","finding":"The verifier learns just enough to be confident, while trusting a stack large enough to contain several conferences.","assumption":"Side channels, privileged software, hardware bugs, operator incentives, and policy ambiguity compose cleanly.","load":5,"maturity":"Research agenda","source":"Hardware-Enabled Mechanisms for Verifying Responsible AI Development","publisher":"O’Gara et al. / TAIG","year":"2025","url":"https://openreview.net/pdf?id=JgxkV2jzzk"}},{"id":"PT-07","slug":"proof-that-training-happened-properly","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"Proof-of-training records checkpoints and data references during stochastic training so a verifier can replay selected segments and test whether the declared history is internally consistent. The cited source classifies the approach as requiring R&D.","mechanism":{"goal":"Give a verifier evidence that a particular model arose through a declared training process without rerunning the entire job.","steps":["The prover periodically records weight snapshots and data indices during training.","In the regulatory variant, on-chip firmware hashes snapshots and sends the transcript to verifier-trusted storage.","Inspectors select chips or transcript segments for review.","A neutral cluster trusted by prover and verifier replays selected segments and compares reconstructed states with recorded checkpoints.","Replay consistency is treated as evidence for the declared training history."],"output":"A replay-checked transcript supporting the claim that logged checkpoints are consistent with specified training operations."},"claimBoundary":{"establishes":["Conditional on faithful capture, sampled checkpoints and data indices are consistent with replayed portions of the declared process.","The transcript was committed as recorded if the logger, hash function, storage path, and keys operate as assumed.","Some fabricated or inconsistent histories may be detected without reproducing the whole run."],"remainsExternal":["Whether every relevant operation was logged or parallel, undeclared, and off-platform training occurred.","Whether sampling is sound against an adaptive prover and replay remains practical at frontier scale.","Whether identified data were lawful, safe, correctly labelled, or semantically permitted.","Whether the model was later fine-tuned, distilled, combined, or replaced.","Whether a consistent training history demonstrates safety, intent, provenance, or policy compliance."]},"threatModel":{"asset":"Integrity and completeness of the transcript and its binding to the model presented for verification.","adversary":"A training operator seeking to pass verification while performing different, additional, or incompletely logged computation.","capabilities":["Control the workload, host software, checkpoint timing, and data ordering around the logger.","Fabricate a plausible transcript or move deviations into rarely sampled segments.","Distribute work across chips, providers, or jurisdictions outside the monitored transcript.","Modify or replace the model after the verified transcript ends."],"exclusions":["The source gives no complete formal security model for this V2 mechanism.","A production-grade, provably secure and efficient protocol is not provided.","General-purpose zero-knowledge verification is treated as inefficient at this scale.","Inference-time governance, policy semantics, and physical resistance of the logger are not established."],"enforcementBoundary":"The mechanism supplies evidence about captured training. Licensing, sanctions, KYC, inspections, and prevention of unlogged computation remain external."},"trustRegister":[{"domain":"Capture and hardware root","requirement":"The on-chip logger records all relevant events in order and cannot be bypassed.","failure":"An incomplete but coherent transcript describes a permitted run while omitting the activity of interest.","sourceTreatment":"mentioned"},{"domain":"Protocol and sampling","requirement":"A malicious prover cannot forge an accepted transcript or hide deviations outside sampled segments.","failure":"Heuristic or weakly sampled checks accept selectively valid histories.","sourceTreatment":"central"},{"domain":"Storage and neutral cluster","requirement":"Verifier storage preserves custody and the jointly trusted cluster replays faithfully and confidentially.","failure":"Evidence or verification results are manipulated at the new shared trust points.","sourceTreatment":"central"},{"domain":"Scale and model binding","requirement":"Replay is affordable and reproducible, and the reviewed model remains bound to the terminal checkpoint.","failure":"Verification is impractical or a valid transcript is paired with a later or different model.","sourceTreatment":"discussed"},{"domain":"Coverage and policy semantics","requirement":"External controls detect unlogged compute and the evidenced property matches the regulator's concern.","failure":"A valid diary of one run is promoted into proof of complete compliance.","sourceTreatment":"discussed"}],"authoredCaveats":["The mechanism is rated 'requires R&D'; current schemes are described as heuristic and not provably secure.","Provably secure and efficient Proof-of-Training-Transcript protocols remain future work.","Zero-knowledge proofs are described as inefficient at this scale, motivating a jointly trusted cluster.","No production-grade system is said to operate at frontier scale without prohibitive overhead.","Training-only governance is described as increasingly insufficient as inference and post-training techniques expand."],"assessment":{"assuranceTransfer":"Replay consistency can support the integrity of a declared transcript. It does not establish completeness of all training, post-training custody, model safety, developer intent, or policy compliance.","loadBearingSequence":["A trusted logger observes every relevant event.","The transcript is complete, ordered, and tamper-resistant.","The protocol and sampling rule are sound against a malicious prover.","Replay is faithful, confidential, reproducible, and affordable.","The final model remains bound to the record and the record maps to the policy claim."],"joke":"The certificate can establish that the diary is internally consistent. It is less forthcoming on whether this was the only diary."},"tests":["Forge transcripts for training paths that were not executed and measure verifier acceptance; no result is reported.","Run additional training on uninstrumented hardware and test omission detection; no result is reported.","Place deviations in rarely sampled checkpoints and quantify detection probability; no sampling bound is located.","Measure logging, storage, and replay overhead on a frontier-scale distributed run; the source says no production-grade result exists.","Fine-tune or replace the proved model and test whether the certificate remains usable; no end-to-end custody test is located."],"scores":{"adversaryRealism":{"value":3,"label":"Partially specified","rationale":"The paper discusses circumvention and structural loopholes, but V2 has no complete threat model or reported adversarial evaluation."},"trustedDependencies":{"value":5,"label":"Very high","rationale":"Useful assurance depends on capture, protocol soundness, sampling, shared verification infrastructure, scale, model binding, external coverage, and policy interpretation.","domainCount":5},"policyReach":{"value":4,"label":"High","rationale":"The source places the mechanism in domestic, bilateral, and treaty verification while the primitive checks only a declared training history."}},"evidence":[{"locator":"Ansari, Hardware-Level Governance of AI Compute, arXiv:2604.04712, §3.2 V2, p. 6","supports":"Checkpoint logging, replay, on-chip hashing, trusted storage, the neutral cluster, and the R&D rating."},{"locator":"Ansari, arXiv:2604.04712, §4.1–§4.6, pp. 9–14","supports":"Algorithmic efficiency, distributed training, physical attack, political feasibility, and the training-inference boundary."},{"locator":"Ansari, arXiv:2604.04712, §5.2, pp. 15–16","supports":"The proposed use of V2 in domestic, bilateral, and especially multilateral treaty verification."},{"locator":"Ansari, arXiv:2604.04712, §6.2–§6.4, pp. 18–20","supports":"Lack of provable security and production-scale implementations, inference gaps, and caution against premature legislation."}],"relatedIds":["CM-05","WV-06","HG-08"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"PT-07","category":"Attestation","title":"Proof that training happened properly","proposition":"Use cryptographic proof-of-training so a verifier can establish that a declared training computation occurred.","finding":"A proof of execution begins a rewarding second career as a proof of intent, provenance, and safety.","assumption":"What can be proven efficiently is also what regulators actually need to know.","load":5,"maturity":"Speculative","source":"Hardware-Level Governance of AI Compute","publisher":"Ansari","year":"2026","url":"https://arxiv.org/abs/2604.04712"}},{"id":"HG-08","slug":"policy-but-make-it-a-peripheral","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"FlexHEG places an auditable guarantee processor beside AI accelerators inside a tamper-responsive enclosure. It observes device traffic and selected state, produces authenticated receipts and aggregate claims, and can optionally enforce updateable rules over visible operations.","mechanism":{"goal":"Provide a programmable hardware trust boundary for privacy-preserving verification and optional enforcement of commitments about frontier AI compute.","steps":["Place accelerators, memory, and an auxiliary guarantee processor inside a protected enclosure.","Position the processor between the accelerators and external interfaces to observe I/O and selected internal state.","Sign low-level receipts describing data, operations, results, compute use, evaluations, configuration, or sharing.","Authenticate and aggregate receipts across devices into privacy-preserving higher-level claims.","Optionally enforce updateable rules or licences; detected tampering wipes keys and may blow accelerator fuses."],"output":"A signed receipt, an aggregate claim about observed activity, or a local allow/block decision under a configured ruleset."},"claimBoundary":{"establishes":["Conditional on the enclosure and processor, a signed receipt records what the mechanism observed and computed.","Receipts can be authenticated and aggregated across participating devices without disclosing every workload detail.","A rule can block an operation visible to and technically classifiable by the processor.","Detected intrusion can invalidate the device's claim-signing identity."],"remainsExternal":["Whether every relevant path, component, auxiliary device, and off-enclosure computation is observed.","Whether a technical predicate captures safety, intent, ownership, military purpose, or another policy concept.","Whether the enclosure resists a state laboratory and the manufactured supply chain matches the auditable design.","Whether relevant capability remains inside the flexHEG ecosystem after outputs or modules leave.","Whether update authorities act legitimately and signed claims are sufficient evidence of treaty or legal compliance."]},"threatModel":{"asset":"Confidentiality and integrity of workloads, keys, receipts, rules, and enforcement decisions inside the enclosure.","adversary":"A chip owner, well-resourced non-state actor, or state adversary with administrative and possibly physical possession of the device.","capabilities":["Control workloads, host systems, data, and external interfaces around the enclosure.","Attempt intrusion, probing, fault injection, component replacement, or key extraction.","Use uninstrumented accelerators or route modular and distributed work outside the ecosystem.","Exploit the processor, ruleset, firmware, update path, authority keys, or supply chain."],"exclusions":["Part I gives conceptual sketches and defers detailed implementation and feasibility work to Part II.","The source limits plausible coverage to compute-intensive frontier AI, not all compute.","Malicious intent and many safety properties are acknowledged as not observable on-chip.","Early systems are not claimed to eliminate inspection, registries, intelligence, or financial controls.","No fabricated device or quantitative adversarial test result is presented."],"enforcementBoundary":"Only operations that cross observable flexHEG interfaces and satisfy technically expressible predicates can be constrained; users, external outputs, and uninstrumented compute remain outside."},"trustRegister":[{"domain":"Enclosure and tamper response","requirement":"Intrusion is detected before secrets or bypasses escape, with reliable key wiping and safe failure.","failure":"An attacker preserves device identity after compromise, or false triggers destroy legitimate availability.","sourceTreatment":"central"},{"domain":"Processor and observation coverage","requirement":"The auditable processor is correct and sees every governance-relevant operation and data path.","failure":"Every signature is valid while the mechanism observes only a convenient subset of the system.","sourceTreatment":"central"},{"domain":"Receipt composition and rule semantics","requirement":"Receipts aggregate without omission or double counting and coded rules match the intended policy.","failure":"Valid artifacts produce a wrong aggregate or flawlessly enforce the wrong proxy.","sourceTreatment":"discussed"},{"domain":"Updates, authorities, and supply chain","requirement":"Manufacture, provisioning, quorum keys, licences, and updates remain secure, available, and legitimate.","failure":"A replicated backdoor, captured authority, outage, or unsafe update changes behavior across the estate.","sourceTreatment":"central"},{"domain":"Ecosystem and institutional boundary","requirement":"Relevant capability stays inside participating hardware and verifiers interpret receipts narrowly.","failure":"Capability escapes through legacy hardware or outputs while a technical receipt is overread as policy compliance.","sourceTreatment":"discussed"}],"authoredCaveats":["Early versions may compromise on security and supported-rule sophistication; strong physical security may take years.","FlexHEGs are expected to govern only the compute-intensive frontier.","Devices cannot infer malicious intent and can distinguish uses only when the computation differs technically.","Inspections, intelligence, registries, and other external controls remain complementary.","Perfect privacy, flawless updates, fully automatic compliance, and several Appendix B sketches are described as infeasible, uncertain, or not necessarily desirable."],"assessment":{"assuranceTransfer":"The processor can carry assurance from protected observations to signed claims and local decisions. It cannot carry that assurance past its visibility, the correctness of its rules, the security of its enclosure and supply chain, or the difference between a predicate and a policy conclusion.","loadBearingSequence":["Manufactured hardware matches the audited design and detects physical attacks.","The processor sees every relevant operation and data path.","Receipts remain attributable and complete across distributed work.","Rules are precise, robust, and updated by secure and legitimate authorities.","Capability stays inside the ecosystem and verifiers do not overread the resulting claim."],"joke":"The peripheral can sign the rule, enforce the rule, and report that the rule was enforced. Deciding what the rule means remains with civilization."},"tests":["Penetrate production-equivalent enclosures with probing, glitching, substitution, and side channels; Part I reports no prototype test.","Move state or compute through paths not mediated by the processor and measure coverage; implementation testing is deferred.","Replay, reorder, omit, or duplicate receipts across a multi-accelerator job; no empirical composition result is reported.","Optimize workloads to satisfy a coded rule while violating its intended meaning; no adversarial rule suite is reported.","Exercise malicious updates, quorum capture, licence expiry, authority outage, and supply-chain substitution; no end-to-end result is reported."],"scores":{"adversaryRealism":{"value":4,"label":"High but unvalidated","rationale":"The source targets state physical adversaries and discusses supply chain, authority, ecosystem, and semantic limits, but offers no fabricated device or attack results."},"trustedDependencies":{"value":5,"label":"Very high","rationale":"The enclosure, processor, observation coverage, receipt composition, rule semantics, authorities, supply chain, ecosystem, and institutional interpretation must compose correctly.","domainCount":5},"policyReach":{"value":5,"label":"Systemic","rationale":"The proposal extends from receipts to location, evaluation, model custody, compute caps, licences, deployment controls, safety protocols, and multistate rules."}},"evidence":[{"locator":"Petrie et al., Flexible Hardware-Enabled Guarantees for AI Compute, arXiv:2506.15093, pp. 3, 6–8","supports":"The enclosure, processor, receipts, aggregate claims, rules, update expiry, tamper response, and supply-chain requirement."},{"locator":"Petrie et al., arXiv:2506.15093, 'Limitations of FlexHEG Mechanisms,' pp. 16–17","supports":"Implementation difficulty, frontier-only coverage, inability to determine intent, and complementary governance."},{"locator":"Petrie et al., arXiv:2506.15093, Appendix A, pp. 24–25","supports":"Limits of automatic compliance, privacy, updates, tamper protection, inspection, and sovereignty."},{"locator":"Petrie et al., arXiv:2506.15093, Appendix B, pp. 26–37","supports":"Receipt aggregation, compute accounting, evaluations, rules, licences, and off-ecosystem and modular-composition limits."}],"relatedIds":["OS-00","OL-02","FM-04","CM-05","WV-06"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"HG-08","category":"Control","title":"Policy, but make it a peripheral","proposition":"Add flexible hardware guarantees that can meter compute, enforce limits, gate deployment, and automate safety protocols.","finding":"The chip becomes auditor, regulator, border officer, safety case, and—if there is room left—matrix multiplier.","assumption":"Many contested policy goals can share one trusted mechanism without sharing one failure mode.","load":5,"maturity":"Research agenda","source":"Flexible Hardware-Enabled Guarantees for AI Compute","publisher":"Petrie et al.","year":"2025","url":"https://arxiv.org/abs/2506.15093"}},{"id":"RT-09","slug":"tamperproof-certificates-continuously","addedAt":"2026-08-22","reviewedAt":"2026-08-22","featured":false,"synopsis":"EQTY Lab's Verifiable Compute chains Intel TDX and NVIDIA H100 attestations to a notary key inside a confidential VM. The key signs inputs, outputs, metrics, and configured governance-check results as persistent credentials.","mechanism":{"goal":"Create portable evidence about the hardware and software environment, workload artifacts, computation metrics, confidentiality state, and execution of configured governance checks.","steps":["Intel TDX secure boot authenticates boot components and measures an expected VM file-system hash.","The VM generates a notary key and binds it and the file-system measurement into a CPU attestation.","A secure channel validates the NVIDIA H100 certificate and firmware attestation and binds GPU evidence to the notary.","Container-specific keys sign workload inputs, outputs, selected metrics, and governance-check results.","Signatures and attestations are packaged as persistent Verifiable Credentials, SPDX, or SLSA artifacts."],"output":"A chain of vendor hardware attestations and signed artifacts described as proofs of environment, confidentiality, correctness, computation, and governance."},"claimBoundary":{"establishes":["A notary key was created in an attested TDX environment with selected measured-boot values, conditional on vendor trust.","The key was linked to an attested NVIDIA GPU and confidential-computing session in the described configuration.","Specific bytes, hashes, metrics, or governance-check results were signed by that key or a chained container key.","A later verifier can validate the signature chain and compare measurements with selected trusted artifacts."],"remainsExternal":["Whether audited code is correct, complete, vulnerability-free, or faithful to a law or policy.","Whether every input, external service, nondeterministic event, side effect, output, and communication was captured.","Whether signed metrics prove useful or correct computation rather than emitted measurements.","Whether a passing check establishes full compliance, output truth, model safety, or accountable intent.","Whether vendor roots, audits, build systems, revocation, algorithms, and certificate meaning remain trustworthy decades later."]},"threatModel":{"asset":"The notary key, measured environment, signed artifacts, and the chain connecting CPU and GPU attestation to governance claims.","adversary":"An untrusted host, malicious administrator, compromised remote resource, or external actor seeking to alter code, inputs, outputs, keys, or evidence.","capabilities":["Control the host, hypervisor, storage, network, and services around the confidential VM.","Attempt post-boot access, signing-key exfiltration, or signing-oracle abuse.","Poison or replace models and datasets downloaded at runtime.","Modify outputs before signing, corrupt encrypted state, or present a phishing endpoint."],"exclusions":["The whitepaper gives mitigations but no formal, parameterized threat model.","H100 is described as protecting against basic physical attacks; invasive state analysis is not established.","Compromised vendors, root authorities, attestation services, and hardware supply chains are not located as evaluated adversaries.","No independent complete-system audit, reproducible security evaluation, or quantitative attack results are provided.","Policy correctness, model semantics, and third-party service behavior remain outside attestation."],"enforcementBoundary":"The system signs observations and may halt application logic when configured checks fail inside the measured workload; it does not validate the adequacy of those checks or govern unobserved services."},"trustRegister":[{"domain":"CPU/GPU and vendor roots","requirement":"TDX, H100, firmware, quotes, certificates, revocation, and vendor services are genuine, secure, and current.","failure":"The notary is validly bound to an environment that is vulnerable or not what the verifier assumes.","sourceTreatment":"central"},{"domain":"Audited image and build","requirement":"The measured file system is competently audited and reliably built from the reviewed source.","failure":"Attestation proves exact execution of malicious or semantically wrong code.","sourceTreatment":"central"},{"domain":"Notary key and artifact capture","requirement":"Keys cannot leak or become signing oracles, and every relevant artifact is signed at the correct point.","failure":"Arbitrary documents are signed or selected evidence omits the real workflow.","sourceTreatment":"central"},{"domain":"External resources and governance checks","requirement":"Remote inputs have meaningful integrity and configured checks correctly implement complete policy requirements.","failure":"The system faithfully signs poisoned inputs or a narrow predicate that passes while the advertised policy fails.","sourceTreatment":"central"},{"domain":"Long-term verification and semantics","requirement":"Formats, cryptography, reference measurements, revocation, and interpretation remain available and appropriately narrow.","failure":"A credential stays syntactically valid but becomes insecure, uninterpretable, or overstated as proof of compliance.","sourceTreatment":"not located"}],"authoredCaveats":["All proofs depend on auditing the VM file system, access controls, input handling, and absence of malicious code.","The system must be deterministic or log nondeterminism, and deterministic builds are not broadly achievable.","A leaked notary key can forge arbitrary outputs; remote resources must be checked or logged and signed.","Outputs must be protected until signing, and confidential computing does not fully prevent corruption attacks.","The then-current bounce buffer adds overhead and supports one GPU or eight in one server; external APIs remain a separate trust boundary."],"assessment":{"assuranceTransfer":"The design transfers hardware-rooted assurance to a signing key and selected measured code and artifacts. It does not transfer that assurance to code correctness, capture completeness, output truth, policy adequacy, or legal compliance.","loadBearingSequence":["Intel and NVIDIA hardware, firmware, roots, services, and isolation are trustworthy.","The measured image is exactly the artifact competent auditors reviewed.","The VM protects keys and captures every relevant artifact and event.","The governance check encodes the intended policy property.","Long-term verifiers retain secure algorithms, reference state, revocation data, and disciplined interpretation."],"joke":"The certificate can authenticate that the configured check passed. Whether the check exhausts the meaning of ‘compliant’ is not included in the signature."},"tests":["Insert malicious or incomplete code into the measured image and assess audit detection; no independent audit result is linked.","Attack system and container signing interfaces from a malicious administrator and workload; no penetration result is reported.","Exercise revoked certificates, stale firmware policy, compromised services, and unavailable vendor infrastructure; end-to-end behavior is not reported.","Introduce unsigned side effects, nondeterminism, poisoned downloads, and output races and measure capture coverage; no metric is reported.","Validate archived credentials after key rotation, revocation, algorithm deprecation, and retired reference images; the decades-later claim has no located lifecycle test."],"scores":{"adversaryRealism":{"value":4,"label":"Concrete but vendor-bounded","rationale":"The source considers untrusted hosts, administrators, key leakage, remote poisoning, output races, corruption, and phishing, but not vendor compromise or invasive physical attack."},"trustedDependencies":{"value":5,"label":"Very high","rationale":"CPU/GPU roots, vendor services, measured boot, audit and build provenance, key isolation, capture, remote inputs, policy checks, and long-term verification must compose.","domainCount":5},"policyReach":{"value":4,"label":"High","rationale":"The system moves from authenticated execution artifacts to broad claims about governance, regulation, lineage, correctness, output authenticity, and accountability."}},"evidence":[{"locator":"EQTY Lab, 'Introducing Verifiable Compute,' public landing page, 'Hardware-based Assurance' and 'The Basics' (accessed 2026-08-22)","supports":"Public claims about runtime certificates, lineage, governance, code, execution location, and outputs."},{"locator":"EQTY Lab, Verifiable Compute Whitepaper v1.08, December 2024, Executive Summary and pp. 7–10","supports":"The notary, signed inputs and outputs, persistent certificates, governance gate, and distinction from base attestation."},{"locator":"EQTY Lab, Verifiable Compute Whitepaper v1.08, pp. 19–29","supports":"TDX measured boot, file-system hash, key generation, H100 binding, workload signing, governance checks, and credential formats."},{"locator":"EQTY Lab, Verifiable Compute Whitepaper v1.08, pp. 35–41","supports":"The external API boundary and dependencies on audit, nondeterminism logs, builds, key secrecy, input integrity, output protection, and corruption mitigations."}],"relatedIds":["WV-06","PT-07","FM-04"],"methodologyVersion":"1.0","correctionStatus":"none","source":{"id":"RT-09","category":"Attestation","title":"Tamperproof certificates, continuously","proposition":"Use CPU and GPU trusted environments to issue hardware-rooted certificates for AI processes throughout runtime.","finding":"The certificate is tamperproof. The platform, verifier, policy, firmware, operator, and meaning of ‘compliant’ remain available separately.","assumption":"Attested software is correct software, and correct software is compliant behaviour.","load":4,"maturity":"Deployed-ish","source":"Introducing Verifiable Compute","publisher":"EQTY Lab","year":"2025","url":"https://vcomp.eqtylab.io/"}}]}