Hardware attestation versus independent re-execution: two threat models
When a company asks a vendor to prove what its AI actually did on a given input, the answer usually arrives as one of two things: an attestation report from confidential-computing hardware, or a record produced by someone who re-ran the work on their own machines. Both get described as verification. Both get sold as trust. They are not the same product, and the difference is not a matter of degree. It is a matter of which adversary each one assumes.
This piece lays out the two threat models side by side, using only public research. My own bias is disclosed at the end.
The two questions people conflate
There are two distinct questions hiding inside the phrase "verified AI".
The first is confidentiality: did anyone other than me see my data while the model processed it? The operator of the machine, the cloud provider, an administrator with root access?
The second is evidence of execution: did the computation happen the way the record says it did? The model named in the record, on the input named in the record, producing the output named in the record, without silent substitution or skipped work?
Confidential computing was built for the first question and offers an answer to the second as a consequence of how it works. Independent re-execution was built for the second question and offers nothing on the first. Most buyer confusion comes from treating one product's answer to its own question as an answer to both.
What hardware attestation actually gives you
A trusted execution environment, whether an Intel TDX trust domain, an AMD SEV-SNP confidential VM, or an NVIDIA confidential-computing GPU anchored to one of those, does something genuinely strong. At launch it measures the code and data loaded into the protected region, and it produces a signed report of that measurement. The signing key chains up to the silicon vendor. A remote party can check the signature against the vendor's certificate chain, compare the measurement to the expected one, and conclude that a specific workload is running inside a genuine enclave on genuine hardware.
Two properties follow. Data inside the enclave is encrypted in memory, so the host operating system and the operator cannot read it. And the measurement binds a specific code identity, which for an AI workload can include the model weights, to the report. That second property is why attestation is often pitched as evidence of execution: the report says these weights were loaded into this enclave, and the enclave promises that nobody outside it could tamper with what ran.
The overhead is small, the technology is mature, and confidential instances are now available on every major cloud. When the assumptions hold, attestation is the cheapest strong evidence there is.
The assumption that carries all the weight
Every attestation report rests on two things the verifier cannot check remotely: that the silicon vendor's root of trust is sound, and that the physical machine has not been tampered with.
The vendors are explicit about the second one. Physical attacks on the memory bus sit outside the threat model of Intel's and AMD's confidential-computing products, and both companies restated that position in their advisories after the research I describe below. This is a defensible engineering choice. Defending against an adversary with a soldering iron and access to the DIMM slots is expensive, and the products were designed for a different adversary: malicious software, a compromised hypervisor, a remote attacker who has gained root.
The question a buyer has to ask is who, in their actual deployment, has physical access to the server. The answer is the operator. The hosting provider's staff, the colocation facility, the data center technician. In other words, the party whose word you were trying not to take is exactly the party the threat model excludes.
What the research showed
In October 2025, researchers at Georgia Tech and Purdue published TEE.fail, an attack on the current generation of server TEEs using an interposer on the DDR5 memory bus. The device was built from commodity parts for under a thousand dollars and read encrypted memory traffic passively. Earlier work in 2025, WireTap and Battering RAM, had done similar things against DDR4 systems with interposers costing anywhere from about fifty dollars to a thousand.
TEE.fail matters more than its predecessors because it reaches the products that were supposed to be the fix. The researchers extracted keys from Intel TDX and from AMD SEV-SNP with Ciphertext Hiding enabled, on fully updated machines in trusted status. On the Intel side they recovered a Provisioning Certification Key, the device-identity credential used in attestation, and with it signed their own attestation keys that did not come from a genuine quoting enclave. That let them produce SGX and TDX reports for arbitrary content. Because NVIDIA's GPU confidential computing uses a CPU confidential VM as its trust anchor, they also reused an NVIDIA attestation from one machine as if it belonged to another, and ran workloads outside any TEE protection while presenting a valid-looking attestation.
Read that last part slowly, because it is the whole argument. The attack does not merely leak data. It lets a party with physical access produce a report that says a workload ran inside a genuine enclave when it did not. The researchers put it plainly on their site: they could provide incorrect output while still faking a successfully completed attestation.
The researchers notified Intel in April 2025, NVIDIA in June and AMD in August before publishing. The vendors' responses were consistent: physical attacks are out of scope, and this does not change that. Again, a defensible position for a product. It is not a defensible position for a buyer whose adversary is the operator.
The other threat model
Independent re-execution starts from the opposite assumption. It assumes nothing about the executor's hardware, because it never relies on it.
The construction is simple to describe. The party that ran the model, the executor, submits the input, the output and the model identity. A second party, the verifier, running on separate hardware under separate administrative control, re-runs the same model on the same input and compares. If the result matches within a tolerance calibrated for GPU numerics, the verifier signs a record binding the model, the input and the output. That record is the evidence. Its authority comes from the verifier's independence, not from any property of the executor's machine.
The executor can forge whatever it likes about its own environment. It can run on hardware with no enclave at all. It can be a data center operator with an interposer soldered to every slot. None of that reaches the verifier, because the verifier's claim is not "the executor's machine was genuine." The verifier's claim is "I ran this myself, elsewhere, and here is what I got."
The costs are real and different. Re-executing everything doubles the compute bill, so in practice the verifier re-runs a sample of the work, chosen unpredictably, and the assurance becomes probabilistic per job rather than certain per inference. Why that is enough is an economic argument rather than a cryptographic one. The verifier sees the inputs it re-runs, so this offers no confidentiality from the verifier. And the comparison must tolerate the fact that two GPUs rarely produce bit-identical floating-point output, which is a subject for its own article.
Where each one is stronger
Stated as honestly as I can.
Hardware attestation is stronger when the machine is physically intact and the adversary is software. It gives per-inference assurance at near-zero overhead, and it keeps the data hidden from the operator, which re-execution cannot do at all. If the first fear in a deployment is data leakage, attestation is the right tool and re-execution is not a substitute.
Independent re-execution is stronger when the adversary is the operator, or when the hardware cannot be trusted for any reason: physical access, an unknown supply chain, a vendor root of trust the buyer is not willing to depend on. It also works on commodity hardware from any provider, which matters for cost and for avoiding a single hardware vendor becoming a single point of failure in the evidence chain.
Neither one is a general solution. They are answers to different questions, and the honest vendor of either will say so.
Defence in depth, and where open evidence registries fit
The strongest configuration is not one or the other. It is attestation for confidentiality and per-inference assurance in the normal case, plus an independent re-check on separate hardware so that the evidence survives the case where the machine was not what it claimed to be. Each covers the other's excluded adversary.
This also clarifies what the new open evidence registries do and do not add. Several vendors, and at least one open specification under standardisation, now publish signed records of what ran into an append-only log whose checkpoints are countersigned by an independent witness. That establishes that a record has not been rewritten since it was logged, which is valuable. It does not establish that the record was true when it was written. Where the record's truth rests on hardware attestation, the log inherits the threat model described above: an operator who can forge attestation can log a forged record, and the witness will faithfully pin it. Records produced by independent re-execution carry their own truth claim and anchor into such logs naturally. The two layers are complementary, and a buyer should ask a registry vendor what the truth of a record rests on. That separation is pulled apart in more detail in Three properties of an AI evidence record.
Questions to ask any vendor
Which of the two questions does your evidence answer: who could see the data, or what actually ran?
If the operator of the machine were the adversary, what in your evidence would still hold?
What is the root of trust, and what happens to your guarantees if it is compromised?
Do you produce anything a party who never touched the machine can check for themselves?
A vendor with a good product will have crisp answers. A vendor selling one threat model as if it were both will change the subject.
Disclosure: I build independent re-execution at Cyberian Systems. The facts about TEE.fail, WireTap and Battering RAM above come from the researchers' publications and the vendors' public advisories, and none of it is a criticism of confidential computing as a technology. It is an argument about which adversary you are paying to defend against.