Implementation · Low-trust AI compute verification system overview
Evidence & limits
On this page
R1Proposed for screening challenged records to show declared inference compute is not training
A detailed end-to-end design states the claim and threat model, but there is no integrated implementation and there are no results.
Assessed use: screening challenged records to show declared inference compute is not training
Rubric assessment
- R1 met: the overview describes the system end to end, the rules it would support (such as inference versus training, model whitelists and blacklisted uses), a worst-case threat model in which both prover and verifier are hostile nation-states, and its practical requirements 1.
- R2 not met. The document is a working draft that sets out the design and open research questions, not results from an integrated system 1. Its companion preprint specifies the tap subsystem and states that empirical validation is still required 2. Several building blocks remain open, including passive optical splitting at 53–112 GBaud 1.
Confidence is medium: the design is detailed, but the author states that its threat model is under-developed 1.
- A public working implementation or reproducible end-to-end results for the capture-then-challenge pipeline, at realistic line rates or against a stated adversary.
- Demonstrated bit-exact replay of production inference inside a secure auditing environment built from independently sourced components.
- A developed threat model and red-teaming of the side-channel, egress and inspector-agent components.
Assessed 2026-09-25 against rubric v1.1.
Evidence
- Status. The overview sets out a design and open research questions 1. Its companion tap preprint states that empirical validation is still required 2.
- Prior work it builds on. Verde obtained bitwise-identical inference results across several NVIDIA GPUs by controlling the order of floating-point operations 1. The TrustGuard sentry, which re-executes instructions, was prototyped on an FPGA 1.
- Taps. Amodo Design is investigating passive optical splitting at 53–112 GBaud 1. The companion preprint expects a demonstration gateway to cost roughly as much to develop as a small team of engineers for a few months 2.
- Cost target. The author expects acceptance to depend on retrofit costs below 10% of the monitored hardware, ideally below 1% 1.
Limitations
- Attribution. A technical mismatch does not show whether it came from evasion, a random bit flip or faulty evaluation software 1.
- Fault leakage. A malicious device can leak one bit per deliberately wrong output, so the design needs a fault budget 1.
- Inspector agents. Screening agents must resist prompt injection 1.
- Physical security. Securing every monitored data centre against covert communication is challenging 1.
- Zero-knowledge option. Proofs work over integers, while accelerated inference accumulates floating-point rounding errors 1.
- Threat model. The author calls the threat model section under-developed 1.
Known flaws
Blockers
Empirical feasibility of passive optical splitting at 53–112 GBaud under realistic conditions is an open question.
Exact replay needs complete hardware and software metadata, and the tolerable slowdown from emulation is an open question.
Tamper-evident, rapidly mass-manufacturable and retrofittable enclosures for side-channel defence are an open research question, and physical security against covert communication in every monitored data centre is challenging.
A mass-manufacturable, good-enough side-channel defence, particularly power-line filtering, has not been constructed or red-teamed.
Distinguishing one server's DRAM contents from another's by challenge-response timing, and a general challenge-response protocol for diverse data types, are open.
The threat model is under-developed and needs input from cybersecurity and AI threat-modelling experts.