Secure, Governable Chips
A policy-forward case for embedding governance mechanisms in chips. Read for the design constraints this would place on chip vendors and deployers.
Available via cnas.org.This is the engineering unit. It is organised by mechanism family rather than author or year, so you can move from the policy motivation into the practical question: what would actually let a third party verify claims about AI development.
Hardware-rooted approaches try to build tamper evidence and governance hooks into chips, packaging, memory, or the cluster surrounding them. They are physically grounded, but their deployment cycles are slow and their threat models have to be unusually explicit.
A policy-forward case for embedding governance mechanisms in chips. Read for the design constraints this would place on chip vendors and deployers.
Available via cnas.org.A concrete catalogue of possible on-chip governance mechanisms and deployment paths. Useful for understanding vendor incentives and engineering trade-offs.
Available via rand.org.A detailed proposal for a tamper-resistant compute-governance device. Read for the architecture and for the threat-model assumptions it depends on.
→ arXiv:2506.15093A chiplet-level proposal for making memory participate in verifiable AI workloads. Read as a lower-level counterpart to flexHEG-style system designs.
Available via the AI Security Forum.A hardware security paper focused on protecting generative workloads on NPUs. Read for the accelerator-engineering view of where protection can sit.
Available via IEEE Xplore.Inference verification asks whether a deployed model is the model that was safety-tested, without revealing weights or disrupting production workloads. The approaches range from practical statistical checks to heavier cryptographic proofs.
The practical statistical framing of inference verification. Read for FSSL, Token-DiFR, and the limits of detecting model-weight exfiltration from outputs.
→ arXiv:2511.02620The companion paper on verification despite nondeterminism. Read alongside Rinberg et al. for the current practical picture of API inference checks.
→ arXiv:2511.20621The zero-knowledge route for LLM inference. Read for what ZK proofs can guarantee, and the overheads that still make the approach difficult.
Available via the ACM Digital Library.A lighter-weight use of zkSNARKs for verifiable model evaluation. Useful for thinking about audits where the model or data cannot be revealed.
→ arXiv:2402.02675The systems side of ZK inference: compilers, runtime optimisations, and the engineering work needed to make proofs less expensive.
Available via the ACM Digital Library.A privacy-preserving audit scheme that lets claims about a model and dataset be checked without revealing either. Read for the threat model.
Available via the ICML proceedings.Telemetry approaches infer what a system is doing from network traffic, timing, memory access, power, or other observable signals. They matter when verification must work at cluster scale or without chip-vendor cooperation.
A network-layer treatment of workload classification in AI datacentres. Read for what secure taps can and cannot reveal at scale.
Forthcoming.The chip-level analogue to network telemetry. Read for how timing and memory signals might support governance claims about GPU workloads.
Forthcoming.A training-compute verification proposal. Read for the mechanics of detecting whether large-scale training rules are being followed.
→ arXiv:2303.11341Attestation and audit approaches create institutional or technical routes for a third party to trust specific claims: what ran, where it ran, who certified it, and which intermediary can be held responsible.
A TEE-based approach to verifiable AI safety benchmarks. Read for the promise and fragility of trusting secure execution environments.
→ arXiv:2506.23706An alternative trust model based on jurisdictional certification. Useful when hardware alone cannot carry the verification burden.
→ arXiv:2308.15514The cloud-provider chokepoint argument. Read for why compute providers may be central institutional actors in any realistic verification regime.
Available via Oxford Martin.A comparative survey across hardware, cryptographic, inspection, and institutional mechanisms. Read for deciding which mechanism fits which agreement.
→ arXiv:2408.16074Some work contributes a component rather than a whole verification regime. These pieces are useful for project ideas that combine hardware, software, cryptography, and audit design.
A training-data verification problem: how can a verifier check what data a model was trained on. Read as a counterpoint to inference-focused mechanisms.
Available via the NeurIPS proceedings.A memory-erasure protocol relevant to audits that require proof that sensitive data, weights, or checkpoints have actually been destroyed.
→ arXiv:2401.06626The cluster-level version of compute verification. Useful for regimes that cannot rely on modified chips or vendor cooperation.
Forthcoming.A broad survey of verification mechanisms. Read alongside the other taxonomies to compare how researchers are carving up the space.
Forthcoming.Short problem-shaped requests for discussion. Treat these as project seeds: each one points at a concrete verification gap.
Available via aisecurityforum.org.