Research Engineer / Research Scientist, Zero-Knowledge Verification

The Team

Some of the most consequential decisions of the AI era will depend on answering one question: can we verify what is happening inside AI datacenters? Answering it could unlock international cooperation, help countries protect their sovereignty, and enable trustworthy adoption of AI in high-stakes industries. Building tools that can earn trust across borders is an urgent technical and political challenge.

SASH’s Verification team builds and tests tools to verify agreements about AI. We prototype new verification mechanisms, lead international research collaborations, and work with policymakers around the world to show what these tools can do and inform how they’re used.

You’d join a small team combining technical expertise with international AI policy experience. Our technical team is led by Pascal Berrang, an Associate Professor at University of Birmingham, and brings experience from the Singapore Government. Our policy team brings experience from Oxford and the Centre for the Governance of AI, while our partners include experts from the Future of Life Institute and the University of Oxford.

The problem

An international agreement on AI is only as broad as what can be verified, and the appetite for verification is growing. In September 2026 Anthropic gave independent third-party evaluators permanent, employee-level access to its systems, and OpenAI said it would match it. Frontier developers now accept that outsiders should be able to check their work.

Between states, the options are cruder: take the operator's word that a datacenter is running a declared, safety-tested model and nothing else, or put inspectors and hardware inside the building. Inspections do not scale, and installing hardware might not be acceptable to every operator.

Zero-knowledge proofs are the one approach that removes both problems at once. The prover can demonstrate a claim — the committed model produced these output tokens — while revealing nothing about the weights, and the verifier's trust rests on mathematics rather than on hardware it has to manufacture, ship and guard. Progress here can be deployed immediately, because there is nothing to fabricate and nothing to install.

The catch has always been cost, and the figures usually quoted for it are badly out of date: the literature still puts proving at four orders of magnitude more expensive than the computation being proved. Our own prototype proves a full conversation with an 8-billion-parameter model in about an hour and a half on a single GPU, and most of what is left is ordinary engineering rather than cryptography.

Extrapolated to a 405-billion-parameter model, fifty times larger, that is 16 to 24 hours because cost grows far more slowly than the models do.

Verification is also a much friendlier setting for ZKPs than the applications they were designed for. A verifier needs confidence that, say, 99% of compute is used legitimately — and sampling roughly 300 outputs is enough for 95% confidence in that claim.

Better still, the sampling can go inside a single proof: preliminary work suggests blocks within a transcript can be sparsely sub-sampled, so floating-point matrix multiplication only has to be emulated exactly for a small sample of vector products. For some problems that is a 100,000x saving over a complete proof.

Your work

You would own the line from "this works in a paper" to "a policymaker can rely on this."

Concretely, that means driving down proving cost, closing the gap between what our proofs currently explain and what a frontier inference actually does, and making the resulting system one that a sceptical adversary's technical staff would sign off on.

You'd work alongside hardware-security and systems colleagues on the team and with external cryptographers, and you'd be expected to publish since the whole approach depends on other people being able to check it.

Representative projects

• Prove a full inference transcript from a frontier-scale model end to end, and report honestly what it cost.
• Get an open prototype to parity with the best proprietary systems. The most useful thing anyone can do for this field right now is make the state of the art public and checkable.
• Close out the data-preparation path that dominates our current proving time, using the reference-implementation check as a correctness oracle for AI-assisted optimisation.
• Help develop the agenda for where this field goes next, including where AI-assisted research can be pointed at.
• Design and analyse the sub-sampling scheme: what fraction of blocks must be checked, under what adversary model, to bound the information a dishonest prover can smuggle through.
• Bring ZKPs closer to what is deployed today, integrating exact emulation of the hardware's floating-point behaviour, including its rounding, scaling and accumulation, or moving production inference to integer arithmetic with batch-invariant kernels.
• Build proof circuits for low-precision formats such as NVFP4, where "just emulate the hardware" turns into numerical engineering.
• Investigate compute- and memory-exhaustion schemes such as proof-of-useful-work or proof-of-space.
• Hide the model architecture itself, perhaps through proof recursion.
• Red-team our own constraint system.

About you

We are hiring this role at a range of levels, from people early in their research career to people who have shipped proof systems in production. We care more about ability and trajectory than years of experience.

You may be a good fit if you:

• Have built something real with a modern proof system (Halo2, Plonky3, STARK-based stacks, or comparable) or have deep GPU and ML systems experience and want to learn proof systems on the job. We expect to hire both profiles.
• Are comfortable reasoning about soundness: what an adversary can do, what your assumption actually buys you, and where the argument is critical.
• Can write code that other people will attack, and enjoy that prospect.
• Are willing to do the unglamorous last mile: generalising across model architectures, chasing numerical mismatches, rather than only the interesting part.
• Thrive in ambiguous, early-stage environments where defining the problem is part of the job.

Strong candidates may also have:

• Published work in applied cryptography, verifiable computation, or succinct proofs.
• Low-precision numerics experience: rounding modes, accumulation order, and why two GPUs disagree.
• Formal verification experience, especially of a verifier codebase or a protocol.
• Familiarity with lookup arguments, recursion, or folding schemes.
• Experience explaining a cryptographic guarantee to someone who will never read the proof.
• Experience using AI systems as research collaborators on problems where correctness is checkable, and a view on where that works and where it does not.