Building verification mechanisms for high-stakes coordination over AI development and deployment.
No single lab, evaluator, or government can make frontier AI safe on its own. As capabilities grow, safety increasingly depends on coordination, and coordination depends on trust. Our engineering team works on the technical mechanisms that underlie high-stakes coordination.
Our goal is to make it inevitable that verification mechanisms are built. We don’t have to be the ones who develop the final systems, but we do need to make sure someone — possibly ourselves — does the work. As such, we work in two ways.
Verification is a process, not a one-shot solution. A ladder of technical mechanisms can build trust towards high-stakes coordination over AI — and nuclear verification history shows how the early rungs get climbed.
Verification technologies might be useful even if you're not shooting for an international agreement. Here are a few reasons why.
Our envisaged AI verification scheme requires recomputation of parts of the workload to tell whether the prover is using their data centre in line with approved workloads. We are starting by verifying they are running an approved AI model.
We are working on implementing a “verifier proxy” that scrapes inference responses to be verified. Our next focus is capturing inference responses for verification using network TAPs and red teaming the recomputation algorithm.
Network TAPs might be needed to capture data centre traffic for recomputation. Placed on the front-end network, ideally, they should be able to mirror network packets to the verifier’s recomputation server.
We are testing existing off-the-shelf fibre TAPs to see whether they work at 800G. We’ve also been working on the design of an “Optical-Electrical-Optical” TAP and supporting the initial design of an FPGA-based TAP.
Forced and verified memory wipes can be used to bound the amount of illegal computation that a server can do. Forcing regular memory wipes makes it more difficult for an adversary to be running illegal workloads. The challenge is verifying a memory wipe has been done and making sure that a memory wipe is fast enough.
Our next focus is speeding up memory wipes of SSDs or designing data centre architectures that work around the speed limitations we’ve found with whole SSD wipes.
Capturing all front-end network traffic requires a huge amount of high-bandwidth information capture and a very large amount of storage. One approach is to hash packets before storage and combine this with a packet retrieval/recreation mechanism.
We’re finishing up our theoretical analysis of hashing and creating proof of principle demos that look at hashing speed on server CPUs, NICs/DPUs, and consider theoretical speeds on dedicated FPGAs.
Verification schemes often rely on capturing all server communication. If all communication is happening over the network fabric, then in theory all of this traffic can be captured. If there are high-bandwidth side-channels, then the prover might be able to covertly run workloads and communicate results without the verifier capturing them.
We are working to turn our internal write-up into something that can be shared with other researchers. After this, we will be using www.sidechannel.cloud to test some of these side-channel mitigations.
On top of these discrete research priorities, we are also working on or plan to work on:
Hashing network traffic creates a tamper-evident record of what data has transited a link. We benchmark line-rate hashing at 400GbE across CPU and DPU hardware, with an interactive dashboard of the results.
Wiping cluster memory and proving that it's been wiped. Initial experiments with H200s.
Our first attempt at AI inference verification: implementing and testing DiFR on a tray of H100s against example model attacks (append and append-on-trigger), across 37,500 prompt runs.
Recomputation-based schemes for verifying that an AI cluster ran the workloads it declared — covering inference (TOPLOC, Token-DiFR) and pre-training — plus the non-determinism, game theory, and practicalities that make them work.
Wiping cluster memory and proving that it's been wiped. Initial experiments with H200s.
Verifying what a compute cluster is doing might involve "tapping" the network — copying network packets for recomputation. These notes explore what it might take to do that.
We mapped the power delivery systems of AI data centers. Our diagram explores the data available at each stage, measurement techniques and signals of interest for AI security.
A quick test installation of a 10G network tap for AI verification — passive vs active taps, fibre types, and what scales to production speeds.
We used a DPU as a tray-level bandwidth limiter — an extra layer of security for protecting model weights, achieving near line-rate encryption with hardware-offloaded IPsec.
Free security and verification research infrastructure.