Get Involved in Verification
AI Futures Project · Updated July 9, 2026
We are looking to support people and organizations that can help advance the verification goals outlined in our plan. We are especially interested in people with backgrounds in hardware design, hardware security, intelligence collection, arms control and verification, cryptography and formal verification, energy and grid analysis, semiconductor supply chains, frontier AI, China policy, and defense against nation-state adversaries.
If you are interested in working on verification, please fill out this form. We may be able to connect you to relevant funders, collaborators, companies, and domain experts.
Plan A stands or falls on verification. An agreement to step back from the race to superintelligence, between rivals who do not trust each other, is only as strong as each side's ability to check that the other is keeping to it. Our verification plan lays out what that takes: tracking compute closely enough that nothing material can be hidden, retrofitting the world's AI datacenters to allow workloads to be verified, and hardening all of it against nation-state attackers.
Most of the systems this requires do not exist yet, and while research on AI verification has been supported by companies like Anthropic, whose RSP roadmap lists provable inference as a moonshot R&D project, it is still a tiny field. In our scenario, verification R&D gets serious government funding in 2027 and imperfect, temporary retrofitting happens for inference-only in 2029. The more progress is made in verification technology, the more likely something like Plan A is to actually happen, as it can drastically reduce the initial cost and uncertainty involved in setting up a deal. Therefore the next few years matter enormously (we believe shifting the probability of something like Plan A happening upwards is enormously impactful) and the field needs far more people than it has. This page hopes to be a resource for people to explore more information on what needs to be built, who is needed to build it, and how you might get involved. It was created in collaboration with some of the existing verification community, and we hope to update the bottom of this page periodically with opportunity postings in the verification field.
State of Play
Our primary near-term recommendation is preparing the ability to develop an inference-only retrofitting solution, because it achieves much of the upside of making an initial pause period more robust and less costly. Our concrete proposal for the inference-only solution is to make simple passive network taps which redirect copies of traffic to trusted servers for random partial recomputation. Building and testing this solution would likely uncover many complications in the implementation details, and will either lead to a more robust solution being ready, or lead to another better approach being pursued instead. In any case, there is still a lot of engineering to be done that nobody has done yet.
Amodo Design, a hardware engineering firm working on inference verification prototypes, graded the state of each engineering workstream alongside our release. Their bottom line is that of the seventeen workstreams the retrofit we propose needs, only four have at least one active effort, and the rest currently have nobody working on them:
Network taps on the frontend network
Passive devices that copy all of a datacenter's input and output traffic to a recomputation server.
- Passive optical tapsActive
Work at 400G today; the 800G and 1600G line rates arriving in datacenters look feasible but are undemonstrated.
- Recomputation servers (capture)Active
Capturing all frontend traffic can work without new R&D, but needs a lot of infrastructure plus work on network topologies and sampling.
- New tap types and bandwidth limitsNot started
Sampling or packet-hashing taps, and ways to cut the capture bandwidth the recomputation side needs.
- Path from the storage bank to the inference unitsNot on track
Moving model weights to inference servers off the frontend network likely needs partitioned networks and data diodes; no work seen yet.
Reproducible workload packets
Forcing AI workloads into discrete, reproducible packets so their correctness can be proven later.
- Inference reproducibility workaroundsActive
Demos exist that work around non-determinism (e.g. implementations of DiFR), short of making workloads truly reproducible.
- A reproducible inference stackNot started
Non-determinism is not inherent; a fully reproducible stack looks possible but needs substantial software and tooling.
- Network reproducibilityNot started
Packets are not individually reproducible by default; may need considerable software, firmware, and possibly hardware work.
Partial recomputation
Re-running a small random sample of packets to verify all outputs with very high probability.
- Recomputation algorithmsActive
Schemes like TOPLOC and DiFR are well described and now being tested on relevant hardware and models.
- Frontier recomputation algorithmsNot started
Algorithms must evolve in lock-step with new model architectures and inference techniques; model developers should own this.
- Recomputation red-teamingNot started
Most algorithm development remains academic; robust red-teaming is needed to bring techniques up to scratch.
Physical security
Keeping the verification hardware itself safe from tampering inside the prover's datacenter.
- Recomputation server securityNot on track
The server sits inside the prover's facility, possibly under their physical control; hardening it against integrity attacks needs significant research.
- Tap installation and monitoringNot on track
Checking that hundreds to hundreds of thousands of taps are correctly installed, and stay installed, is not a solved problem.
- Verification reportingNot on track
The integrity of what the recomputation server reports back to the verifier has not been explored.
- Physical security and auditsNot on track
Little work exists on how to inspect compute at scale, or how to inspect a verification system.
Completeness: side channels and memory wipes
Ensuring the only persisting outputs of a cluster are its verified inference outputs.
- Memory wipesUncertain
Existing algorithms (e.g. PoSE) may be suitable; early testing on relevant hardware is underway.
- Side-channel mitigation (shielding plus noise)Not on track
No plan yet for quickly scaling side-channel defences on a frontier cluster; only early theoretical pieces exist.
- Side-channel wardensNot on track
Scanning and observing side channels to detect covert communication is unexplored.
What needs to be done
One useful breakdown of verification work involves four tracks that can be worked on in parallel, because they tackle different parts of the problem space, run on different timelines, and need different kinds of people (adapted from James Petrie):
Domestic regulation or company-to-company agreements (which may be involved in e.g., Plan C or B) may not require any new verification technology. Companies are less able to backdoor their own chips than nation-states, so embedded auditors together with existing hardware might be able to reach sufficient assurance. The work involved in this track is figuring out the implementation details that such an auditing regime would need to follow, and red-teaming its robustness.
AVERI: Frontier AI Auditing ↗Options deployable before highly secure, purpose-built hardware exists. This is our plan's inference-only retrofitting solution (e.g., in our case, passive optical network taps, randomized recomputation, memory wiping, tamper-evident enclosures, and human inspections). There may be other solutions possible, like cryptographic proof-of-work or proof-of-memory schemes. The work involved here is to develop these into fully scoped designs, and then prototype and red-team them.
Phase 1 of the verification plan →A deal is only stable if neither side can have built a material stockpile of hidden compute. Interventions to make it more likely that compute existence and ownership can be well accounted for are great. Currently smuggled chips seem like a large source of potential secret compute. Intelligence measures are centrally relevant here.
Our covert AI projects supplement →Verification that can tell arbitrary approved and banned workloads apart at large scale with extremely high assurance. This will require a lot of progress in cryptography as well as hardware and physical security. In our plan, it is implemented with a recomputation-centric approach that gets more and more granular over time, with many other supplementary parts. Overall this area seems like less of a blocker than Track 2, but early work might nonetheless be very important, especially to the extent that we are overly optimistic about fast progress being made on this being tractable in a short period of time once an international agreement is actually being pursued.
Workload verification in the plan →Open problems
Across these tracks, Kristian Rönn of Lucid Computing sent us the following pitch of where the hard but tractable open problems currently are, written for people trying to figure out where they could contribute:
Can you prove what data went into and out of a cluster by tapping the network at the physical layer, instead of trusting the software running on it? The open questions here are passive optical taps at the next line rates (1600G is arriving and may need a new chip), capturing traffic and timing inside the cluster and not just at its edge, and closing covert-channel gaps like NVLink contention. This is probably the most time-sensitive hardware problem in the field.
Even with monitoring in place, information can hide in a model's inputs and outputs. The work here is about measuring and putting a ceiling on those channels, for example encrypted-prompt schemes plus input wardens that commit to the prompt and output distribution, so that hidden capacity is a known quantity rather than an unknown.
Most verification today leans on trusted hardware. The goal at the frontier is to stop depending on it: zero-knowledge proofs of inference, bit-exact recomputation, optimistic re-execution, and proof-of-training, so that “this model produced this output” or “this model was trained this way” can be checked with math rather than trust. Inference verification for large models (over 30B) that's competitive with plain recompute is still open.
No single mechanism closes the gap, so real systems combine a lot of them. The open problem is proving the combination is sound, i.e. that a policy set actually enforces the independence between trust roots it claims to, rather than quietly collapsing back to one.
A technical proof is only useful if an institution can act on it. This is the mapping between machine-checkable artifacts (receipts, audit trails) and the legal and treaty instruments now coming online, things like conformity-assessment schemas, retention rules, and dispute resolution. There's also the incremental path from unilateral declarations to a monitoring body to a treaty. Good area for people who span technical and policy work.
Accelerator TEEs keep getting broken and then patched, and side-channel and telemetry attacks on the host tend to reach the accelerator too. So there's ongoing work on hardening these enclaves and building independent corroboration (power, timing, network) so that one broken TEE doesn't take the whole verification story down with it.
Ben Harack also added:
All feasible hardware-enabled governance seems to require inspection and monitoring (otherwise the hardware guarantees can be broken), so the open question is whether a scheme limited enough to be acceptable to cyber and physical security teams (e.g., confidential network loggers plus monitoring of the perimeter and the spaces between racks) can still deliver the needed guarantees.
What kind of people are needed
Verification is deeply interdisciplinary and no single field owns the problem. Most of the skills it needs also currently exist almost entirely outside of it. Yannick Mühlhäuser of the Future of Life Institute put together the following breakdown of the kinds of people the field needs:
Arms-control veterans who understand monitoring regimes and cheating incentives, IAEA and treaty-verification experience, international lawyers, and national security professionals with deep US or China experience.
Intelligence-collection experts (open-source intelligence, satellite imagery, signals), energy and grid analysts who can infer compute from electricity draw, export-control and end-use monitoring specialists, and semiconductor supply chain experts who can account for global chip flows.
The people who build the devices themselves: chip designers, FPGA engineers, fab engineers, embedded and firmware developers for the trusted software stack, and systems integrators who turn components into working prototypes.
Secure-hardware engineers (roots of trust, TPMs, TEEs, secure boot), attack-and-defence researchers (Trojans, fault injection, glitching), anti-tamper and side-channel specialists, and physical inspection experts (X-ray, decapping, electrical measurement).
Optical networking engineers for taps, splitters, and line-rate capture; datacenter builders and operators who know what is operationally feasible; and physical and operational security experts for the facilities themselves.
Verification is a deployed system that must run for decades: systems engineers, technical program managers, integration engineers, independent test-and-evaluation teams, and lifecycle leads for maintenance, key rotation, and hardware refresh.
Cryptographers (zero-knowledge proofs, attestation, proof-of-work schemes, tamper-evident logging), formal-verification experts for both hardware and software, minimal-TCB architects who shrink the trusted core until it can be audited, statisticians who design sampling schemes with explicit detection targets, and top-tier offensive security people to red-team it before it gets deployed.
Frontier ML systems researchers who know how large-scale training and inference actually run, and therefore which covert workloads matter, plus model evaluation, auditing, and oversight experts.
People who can turn all of the above into organizations: founders ready to take on one of the tracks, operators and chiefs of staff who make small technical teams function, and program managers who can run pilots with AI companies and governments.
If you recognize yourself anywhere on this list, the field likely needs you (almost nobody working on verification today started in it).
How to get involved
If you have expertise in relevant areas and want to contribute to the verification technology featured in Plan A, this expression of interest form will allow hiring organizations and funders to learn about your background and interests. Your responses may be shared with relevant funders and organizations working in the space. It takes about five minutes and commits you to nothing.
Open the expression of interest form ↗We cannot guarantee a response from funders or that every submission is passed on.
By role
Amodo also put together concrete recommendations for what you can do depending on who you are: a government, an AI company employee or leader, a philanthropist, a venture funder, or an engineer, researcher, or scientist.
www.amododesign.com/ai-verification/plan-a-recommendationsopen ↗How you can help, by roleConcrete next steps for supporting the R&D and deployment of AI verification technologies: R&D funding programs and verification demos for governments, pilots for labs, gaps for funders, and problems for engineers.Meet the field
The field is currently small enough that just showing up works. There is a verification community night in San Francisco every few weeks (rotating between host organizations), and several of the organizations on the opportunities board below have said they're happy to talk to people trying to find their first project, so don't be afraid to reach out.
Start reading
Some good starting points if you want to read your way into the field:
Opportunities
Below are organizations in the field that have told us what they're looking for or who publicly advertise verification opportunities. We will keep updating this board as more come in.
Lucid builds the hardware-rooted verification layer that lets an outside party check what actually ran on an AI cluster (which model, on which chips, under which policy) without having to trust any single party or any single piece of silicon. They collaborate with outside researchers and engineers on TEE hardening, side-channel and telemetry-based workload verification, and cryptographic inference and training verification, and they hire across hardware, cryptography, systems, and policy. They are also happy to point newcomers to technical verification at a first tractable project.
Amodo is a hardware engineering firm prototyping the network-tap and recomputation approach at the center of the plan's inference-only proposal, including passive optical taps and an implementation of the DiFR recomputation scheme. Alongside Plan A they published the workstream-by-workstream SITREP featured above and role-specific recommendations for how to help.
Bridging the political gap between Asia and the West, this collaboration between the Future of Life Institute and the Singapore AI Safety Hub is building a prototype of a Confidential Network Logger, the device that would allow for the inference-only retrofitting contained in Plan A. SASH is hiring for this work, and a get-involved form is on the way.
The Compute Verification Project is a research nonprofit designing new protocols for verifying how compute is used without revealing confidential information. We developed the current SOTA inference verification algorithms as well as an inference server with deterministic builds, serving, and networking. Most recently, we published a working draft of a new protocol that can structurally distinguish between inference and training based on communication patterns. We show that it renders standard frontier training algorithms infeasible, and are organizing a competition to develop new training algorithms that circumvent it. We are well-funded and are hiring technical generalists with backgrounds in security, systems, and ML.
The RAND AI verification team focuses on research projects that advance technical verification mechanisms for international agreements on AI and other applications: conducting in-depth analysis, writing products for senior stakeholders, and advising external organizations on R&D projects. RAND CAST is currently seeking technical and policy researchers to join its AI verification workstream.
The Oxford Martin AI Governance Initiative (AIGI) pairs technical analysis of AI systems with deep policy work to anticipate and reduce the risks of advanced AI. Within AIGI, the Hardware AI Governance Lab (HAIGL) combines computer hardware expertise with AI governance. Both teams focus heavily on AI verification. Both are growing fast, with many ways to get involved. Ben Harack leads the verification initiatives and welcomes contact from anyone who wants to contribute.
ARIA (the UK's Advanced Research and Invention Agency) is funding opportunity seeds under its Trust Everything, Everywhere opportunity space, which aims to extend digital trust infrastructure into the physical world. Relevant topic areas include hardware and silicon security, cryptography, and trust tools that make physical security systems easier to design and verify. Seeds are up to £500K per proposal, with applications open until July 27.
An 8-week, fully funded research and engineering programme in Cambridge, UK, where residents take on concrete projects in cybersecurity and hardware-enabled verification to mitigate the risks of frontier AI. With the possibility of extension funding for up to 6 months, it is an easy way to transition into AI verification by working with leading organizations and academics in the field. Applications are open until July 26.
A recurring happy hour for the AI verification scene, rotating between host organizations: technical folks, policy folks, and anyone curious about how to make AI systems whose properties can actually be checked. Pizza, drinks, and the people you should be talking to. Event spaces and co-hosts are welcome. Link will be posted here.
If you run an organization, fund work, or host events in this space and want to be featured here, please email romeo@ai-futures.org.