Proof-gated endpoint
In short
- A small computer (a Raspberry Pi) sits between an AI server and the outside world. It lets an answer out only if a cryptographic proof shows the approved model produced it from that exact question.
- That stops a hacked server from changing what an answer says. It doesn’t stop it from signalling through when answers leave, in what order, or which ones fail.
- We measured those three signals on the real device, one client at a time. Release rules stopped the ordering and timing codes we tried (timing at a cost in speed, with a small trace whose status is in the table below); deliberate failures still get through, fewer of them with a cap that costs availability.
This work was supported by ERA’s Frontier AI Security Residency. It is work in progress (November 2026), not production security.
Why this matters
The most valuable thing an AI lab owns is its model’s weights. A hacked server, or a model acting against its owners, could try to smuggle weights out a little at a time, hidden inside ordinary answers. If every answer has to pass through a checkpoint that verifies a proof, the server loses the freedom to hide data in the content of its answers. The checkpoint is small and simple, so it is much easier to secure than the datacenter behind it.
+---------+
user ---- question --> | endpoint | ---- question ----> AI server
| (Pi) | (may be hacked)
<--- answer ----- | | <--- answer + proof
or "unavailable"+---------+
We call the Pi running the checking software the endpoint.
What we found
| Way to smuggle data out | Basic endpoint | Best endpoint so far | What it costs |
|---|---|---|---|
| Change what an answer says | Blocked by the proof | Blocked | Each check takes about 0.24 s on the Pi |
| Reorder answers | Leaks | The ordering code we tried no longer gets through: answers leave in the order questions arrived | A slow answer delays the ones behind it |
| Delay answers | Leaks | Much reduced: each answer has a set release time and can’t leave before it; a small trace remained without spin, and with spin a 512-answer test was inconclusive on the stock system and found nothing on the stripped image (one run) | Answers take 4.0 s instead of about 0.8 s |
| Fail chosen answers on purpose | Leaks | Still leaks, less: with a failure cap, 4 of 16 planted bits got out instead of 16/16 (one run) | 18 of 64 answers ok instead of 60 of 64 |
These are results for one tiny, deterministic test model and the encoders we tried, not limits on what an attacker could do. Details and numbers are in What a hacked server can still leak.
Status
| Version | What it is | Status |
|---|---|---|
| v0 | The checking software on the Pi’s standard operating system | Done and measured |
| v1 | Stricter software in Rust (fixed message format, release in arrival order or at a fixed time, a failure cap, a sandboxed checker, fixed-word logs, signed updates) on a stripped-down, read-only system with one open port | Done and measured on the Pi; a rebuild with a locked-down kernel and no login is awaiting its Pi check |
| v2 | Secure boot, two physical ports, a counter against restoring an old update store, signed images | Planned |
Where to start
- 5 minutes: this page, then What a hacked server can still leak.
- The whole system with diagrams: How the endpoint works.
- Assessing the security: How hard the endpoint is to attack, then the Attack catalogue and Threat model.
- Checking the numbers: Measurements and Reproduce the results.
- New to the terms: the Glossary.
The code is at github.com/0x471/fasr-proof-gated-endpoint.