From Verifiability to Model-Weight Security

A frontier model’s weights are an unusual kind of asset. They are data, but they are also capability.

The weights encode the result of an enormous investment in compute, training data, algorithms, engineering, and research. If they are stolen, an attacker does not merely obtain source code or confidential documents. They obtain the ability to run the model independently, remove its safeguards, modify it, fine-tune it, and use it without the developer’s oversight.

That makes model-weight security both a commercial and a national-security problem. As models become more capable, stealing their weights could allow a competitor to erase years of technological advantage—or allow a nation-state or terrorist organization to gain access to capabilities that the original developer had deliberately restricted.

RAND’s report, Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models, treats weights as the critical leverage point in frontier AI security. The report identifies 38 distinct attack vectors, ranging from compromised software dependencies and malicious insiders to advanced physical attacks and nation-state operations. It emphasizes that a failure along just one viable path can be enough to compromise the entire system.

This problem is central to Attestable’s history. Before founding the company, our CEO, Yogev Bar-On, co-authored the RAND report and worked with frontier AI labs and the U.S. government on AI security. The conclusion was uncomfortable: the technologies available to security teams were not sufficient to reach the required level of protection on the timetable set by AI progress.

We need to reach Security Level 5 faster

The RAND report defines five security levels.

At the lower levels, organizations defend against amateurs, professional criminals, insiders, and increasingly capable cyber operations. Security Level 5, or SL5, is the highest level: a system that could plausibly withstand the top-priority operations of the world’s most capable nation-states.

This is the threat model that matters when the asset being protected may be one of the most strategically important technologies in the world.

RAND concluded that an internet-connected production system cannot currently reach SL5 using off-the-shelf security products and normal industry practices. The report estimated that, even with serious prioritization, organizations could require at least five years and support from the national-security community to reach it. It also concluded that achieving SL5 for production deployments was probably not yet possible.

Five years is a reasonable security roadmap in many industries. It may be an unacceptable one for frontier AI.

If highly capable systems arrive before the infrastructure holding them can withstand a top-tier state actor, then the world may develop transformative intelligence before it develops the ability to keep that intelligence secure. Attestable was founded because closing this gap requires more than incremental improvements to existing security products. It requires new primitives that allow AI labs to leapfrog parts of the traditional security roadmap.

Zero-knowledge proofs offer one such primitive.

Stop trying to create trust

A modern AI datacenter is an extraordinary accumulation of trusted components.

We trust GPUs, CPUs, network cards, firmware, drivers, operating systems, container runtimes, orchestration software, compilers, inference frameworks, third-party libraries, monitoring agents, build systems, update mechanisms, employees, contractors, and hardware suppliers.

Traditional security tries to make every one of those components sufficiently trustworthy. It hardens systems, limits privileges, scans for malware, audits dependencies, monitors activity, isolates networks, and adds layer after layer of defense.

All of that remains important. But the architecture has an inherent weakness: the trusted computing base is enormous.

A sophisticated attacker does not have to defeat every defense. They need to find one path through a sprawling stack of hardware, software, people, and suppliers. The RAND report’s 38 attack vectors illustrate just how many such paths exist.

Zero-knowledge proofs let us ask a different question.

Instead of asking:

Is every component inside the datacenter uncompromised?

We can ask:

Can the datacenter mathematically prove that this output was produced by the approved computation?

That change in question is the foundation of the verifiable datacenter.

Turn the entire datacenter into a deterministic function

Malware is a side-effect of general-purpose computing. In a perfect world, a computer does only very specific things it is allowed to do. So, imagine placing a verification firewall at every external interface of the environment containing the model weights.

Every legitimate input enters through this firewall. The firewall sees the input, authenticates it, and records or commits to it. When the datacenter produces an output, it must also produce a zero-knowledge proof establishing that the output was generated by the approved model, using the approved program, policy, and input.

The firewall releases the output only if the proof verifies. Everything else is blocked.

The good news, and the bad news

The performance is already here.

The strongest version of the architecture proves every output before releasing it, But that may not always be necessary.

For model-weight security, the objective is often not to guarantee that every individual response is correct. The objective is to make sustained malicious behavior, and therefore bulk exfiltration, overwhelmingly likely to be detected before a meaningful amount of data can escape.

The firewall can randomly select outputs for proof verification. The selection must remain unpredictable to the datacenter and should occur only after the output has been cryptographically committed. Otherwise, malware could behave correctly whenever it knows a proof will be requested and cheat only on unsampled outputs.

Using this method, we no longer need a negligible proof system, and the Attestable solution is already practical today.

But it is not a replacement for defense in depth.

An attacker with physical access may try to remove storage devices, probe memory buses, implant unauthorized hardware, photograph displays, compromise technicians, or extract information through power analysis, electromagnetic emissions, acoustics, temperature, or fault injection.

The datacenter may also leak information through channels that are not part of the nominal output. Response timing, packet sizes, connection failures, power consumption, proof-generation latency, and deliberate denial-of-service patterns can all carry information.

Today we are making a huge step towards SL5, but there is a long way to go