Raspberry Pi 5 off the grid: a signed poisoned knowledge package sailed through every check

What happens to a local AI assistant if it lives on a device with no network connection, yet still has to be trusted? Researchers Georgios Feredzakis and Alexandros Papaspiridis tested exactly that on a Raspberry Pi 5: a fully local RAG pipeline under network isolation, three sizes of Qwen2.5 (1.5B, 3B, 7B), three context sizes, and 300 questions from SQuAD 2.0. The upshot: some of the trust mechanisms work almost flawlessly, while the most obvious safeguard — a digital signature — turns out to be insufficient on its own.

Five connectivity modes and knowledge packages instead of the cloud

Most generative AI deployments in IoT assume the cloud is always within reach. Real devices often operate intermittently, inside closed loops, or with no connectivity at all. The authors propose a C0–C4 connectivity scale for this, a taxonomy of trust mechanisms at inference time, and an update channel for disconnected modes: signed, versioned knowledge packages. A device receives a new package, verifies it, and only then connects it to the database the model draws context from.

Where trust works, and where it doesn't

The first mechanism is a gateway based on the relevance score of retrieved fragments, calibrated empirically. It catches queries that aren't in the corpus at all almost perfectly: an AUROC of 0.97. It handles unanswerable questions within a familiar topic noticeably worse, with an AUROC of 0.68. Such questions resemble corpus documents closely enough that the retrieval score alone can't distinguish them from normal ones.

The second mechanism is a deterministic output validator. It turns "off" answers into an explicit refusal, and in doing so didn't cost the model a single correct answer. An NLI-based verifier model, which the authors also tried, added little. For the 7B model, 96% of substantive answers to questions labeled "unanswerable" matched normalized fragments of retrieved passages. The model isn't fabricating — it's pulling text from context even when there's technically no answer in it.

A signature is not the same as truth

The toughest part of the work concerns updates. Signature-and-hash checks alone accepted 6 of 9 attacks: version rollback, replay, expired package, revoked keys, model incompatibility. Layered verification rejected all 9 in about 4.5ms.

But a poisoned package with a valid signature passed every check and stripped the model of correct answers on all 30 targeted questions. As the authors put it: integrity establishes provenance, not truthfulness. Trust in content has to be enforced at the publisher, before signing, not on the device. This test was only run on the 3B model, so the 7B model's behavior remains an open question — in the main experiment it refused to answer unanswerable questions more often.

Key figures from the study

• Platform: Raspberry Pi 5 with 16 GB of memory, network isolated
• Models: Qwen2.5 1.5B, 3B, 7B; three context sizes
• Data: 300 questions from SQuAD 2.0
• Retrieval-score gating: AUROC of 0.97 for out-of-corpus queries, 0.68 for in-topic unanswerable queries
• Deterministic output validator: zero correct answers lost
• NLI verifier: minor added value
• 7B model: 96% of substantive answers to unanswerable questions matched passage fragments
• 3B vs. 7B: same share of answers containing the gold reference, at less than half the latency and estimated energy; a 3B query takes about 22 seconds
• Peak resident memory at query completion: 6.3 / 9.4 / 13.6 GiB for 1.5B / 3B / 7B
• Update attacks: signature and hash checks missed 6 of 9, layered verification rejected 9 of 9 in ~4.5ms
• Poisoned signed package: broke correct answers on 30 of 30 targets

What engineers should take away

For offline devices, it makes more sense to go with 3B rather than 7B: containment quality is the same, while latency and energy are halved. An output validator is cheap and should be deployed immediately. Updates need a monotonic version counter, an expiration window, key revocation, and model compatibility checks — a signature alone isn't enough.

Open questions remain: the authors acknowledge that key custody and authorized rollback to a known-good package aren't fully resolved, that no ready-made update profile exists specifically for RAG, and that the key used in the experiment was generated on the device itself. Discussion participants suggest additionally running a fixed set of control questions before switching over to a new package. There's a window for this: embedding a package on the Pi takes about 29 minutes.

All figures reproduce with a single command, and the code and per-query outputs have been published.