Plan A Verification SitRep

Early 2029: The President announces that the US will pursue international cooperation to avoid an imminent intelligence explosion.

That’s what the AI Futures Project’s “Plan A” says. Plan A is their proposal for what should happen, but are we on the right track?

At Amodo, we’re working on AI Verification, and Plan A requires exactly that:

“We recommend an international deal to avoid a catastrophic race to superintelligence, spearheaded by the US and China. This deal needs to be enforceable without relying on trust, because the US and China will be unlikely to make an agreement that cannot be verified; and they are much less likely to defect on the agreement if any defection is likely to be caught.”

In this piece, we break down their verification plans and describe the current state of play of different research projects.

Inference-only verification

“The US and China want to avoid an imminent intelligence explosion. In order for an agreement along these lines to be trustless, they need some way to verify that neither side is unilaterally training dangerous AI. Distinguishing dangerous AIs from safe ones will require more time and understanding, so for now they go with a simple solution: a temporary pause on all new training runs. Both sides can still use datacenters for inference (i.e. running the AIs that already exist), but they will retrofit each other’s datacenters with devices that will let them verify that they aren’t being used for new large training runs.”

The clear goal: develop solutions that allow datacentres to be used for inference, but block datacentres from being used for new large training runs. This is exactly what we’ve been working on at Amodo, so how does AIFP’s plan stack up compared to our work, and where are their important research gaps to achieve the AI 2040 Plan A in time?

Across the five inference-only measures below, here is where the engineering stands today:

Passive network taps on the frontend network

Add in simple, passive network taps on the frontend network (also known as north-south networking) that redirect copies of all input/output traffic to a recomputation server. These network taps on frontend networks have multiple possible implementations. We currently think they should probably be completely passive and split optical signals into two because this is probably easiest to trust. Separately there should be a path from the storage bank back to the inference units.

Discrete, reproducible workload packets

Force all AI workloads (inference, agentic tool use, etc.) to be organized in discrete and reproducible packets, which are transparent to the recomputation server (because they pass through the network taps). Reproducibility is required to enable correctness proofs on the packets. By default, inference workloads are not necessarily reproducible. Achieving reproducibility may involve some cost overhead in order to maintain reproducibility but we think it is a solvable problem.

Partial recomputation to check correctness

Perform partial recomputation (random samples of the packets) on the recomputation server to check the correctness of the packets. The integrity of the recomputation server is an extremely important aspect of this step, but assuming its computations and outputs can be trusted, then partial recomputation through random sampling should scale extremely favourably to verify the correctness of all the outputs with extremely high probability while only using a small fraction of the original compute.

Physical security against tampering

Have strong physical security properties to help ensure integrity of the verification measures from e.g. tampering attacks. The integrity of the verification process requires there to be sufficient physical security measures to avoid tampering, and other attacks that could subvert the verification process.

Completeness: side-channel limits and memory wipes

Verify completeness by bounding the maximum side channel communication, and using periodic memory wipes (probably through forced memorization). The completeness of this verification proposal, i.e., that the only outputs from the cluster are verified inference tokens, requires side channel mitigations and memory wiping as described. We do not verify that spare compute isn’t used for unapproved workloads (because this seems very challenging) but try to ensure that the only persisting results in the form of outputs are verified inference outputs. This requires strong side channel mitigations and periodic memory wiping on the inference units (which we think can be done through forced memorization).

In this section, we described just the state of play of the engineering R&D. We want to see more work on all of these problems. Even problem areas described as “Active effort” need more attention. At a minimum, existing work needs to be extended, including:

• Turning proof-of-concept papers into reliable prototypes
• Red-teaming prototypes, including with NatSec teams
• Preparing plans for quick and secure scaled-up manufacturing
• Stockpiling crucial components, including ready-to-implement TAPs and recomputation servers
• Creating an installation playbook and guidance for governments
• Collaborating with AI developers, data centres, and governments on which bits of the plan are likely to work, or fall apart

Further verification research

This inference-only retrofit is just the start of AI verification. As the deal progresses, more advanced verification features need to be developed; ideally, R&D for these should start now. In this section, we describe some of the verification projects that the AI Futures Project describe in Plan A:

• Secure network gateways. One potential upgrade to this proposal would be to build more complex ‘secure network gateways’ that have more functionality than the network taps, and organize and randomly sample the logs of reproduction packets to send to the recomputation server in a robust way.
• Cryptographic / ZKP verification. On top of this key effort to build the network-tap and recomputation centered approach, there is also significant funding (order of 100M) mobilized into R&D for other approaches, including software-only and cryptography-centric (e.g. ZKPs) approaches, and a similar pool for physical security R&D (order of 100M) that supplements the inference-only retrofitting solution.
• Workload verification. Our view is that workload verification is solvable in a similar way to what we discussed previously (evidence collection via network taps, and then partial recomputation of randomly selected reproducible packets).
• Workload reproducibility mandate. Our guess is that, in order to reach extremely high levels of assurance — which will be increasingly necessary in Plan A — a reproducibility mandate, combined with complete (and increasingly granular) on-path evidence collection, paired with a partial recomputation-based verification algorithm, will be a viable approach.
• Low-latency challenges and validity checks. That being said, we are not confident that another approach (e.g. using low-latency challenges and validity checks) might not be able to reach the same levels of assurance at lower costs, or higher levels of assurance at equal costs.
• Packet-based verification: increasingly granular on-path evidence collection. By default, computational steps execute with randomness, but if they can be forced to be reproducible (e.g. seeded randomness is fine), then we can have a predictable relationship between the granularity of the evidence collection and the assurance level of the verification algorithm. This is because partial recomputation with random sampling of some small percentage of the workload has favourable scaling of detection probability as you decrease the size of the individual workload packets that you check the correctness of. The concrete regime we imagine for the first few years of the deal is to still use network taps for evidence collection, and partial recomputation of randomly selected reproducible packets to verify correctness — the same high-level approach as inference-only, with smaller and smaller packet sizes over time by moving the network taps to lower levels of the backend network.
• Workload approval. Workload approval will be closely tied to the form of AI R&D rules that are in place (e.g. are they just experiment compute caps? Are there specific banned techniques? Are there specific required techniques?) and our overall baseline proposal for approval is for this to just be manually carried out by teams of auditors in the R&D clusters.
• Anti-steganography measures on the declared workloads and data.
• Auditor compilation into GPU instructions, ideally with increasingly robust and secure programming languages.
• AI-assisted data filtering and checks.

Other parts of a workload verification scheme:

• Running evaluations that also get verified for correctness.
• Final model approval for release leads to the model weights being downloaded from the opaque internal database and transported to the inference-only clusters. This process is extremely high stakes from a model weights theft perspective, so would need to be carefully designed and executed.
• SL5 inference-only clusters. First SL5 inference-only clusters are online and start serving the first post-deal models that have been approved from the R&D clusters for broad public deployment. These clusters have the same basic verification approach as the retrofitted ones (network taps and partial recomputation) but with improved security properties. By the end of the year, around 40% of world compute (500M of the global 1.2B H100e) is in these new post-deal SL5 inference-only clusters.

We don’t cover SL5 research specifically here. We believe that leading groups working on this are at RAND, the SL5 taskforce, and the leading AI model developers.

• Security and verification improvements. By 2033 we expect significant hardware security, and more general security properties of the data centers, verification regime and capabilities, to have improved significantly.