The firm and all matters in this study are fictional. The measurements are real.

The code, the pre-registered answer keys and the run logs are public: blind-counsel and blind-adapters, both listed on /tools. Both are research proofs of concept and not legal advice.

---

1. The Problem

A law firm wants AI help on client matters. A standard cloud AI pipeline sends the client's facts to the provider's servers, where the provider can read them. Measured, reference implementation, October 2026, one fictional unfair dismissal matter: a standard cloud retrieval pipeline (RAG) sent 16 private tokens to the cloud, including the client's and employer's names, dates and salary [1].

The usual protection is a trusted execution environment (TEE): an isolated, encrypted area of the processor that the cloud provider cannot read. A TEE relies on the chip maker to build and certify it correctly (§8).

This study sets a stricter rule. The firm trusts no one outside its own laptops: not the cloud provider, its staff, other customers on the same servers, or the chip makers. The cloud provider is treated as an attacker with full physical and software access. Two designs were tested under that rule:

1. Hide the model with a secret key, so the cloud can run it without reading it (§2).
2. Keep all client work on the laptop and use the cloud only for public law, fetched without revealing what was fetched (§3 to §6).

---

2. Hiding the Model With a Key Fails

In this design, the firm generates a key and scrambles an open model's weights with it, in a way that leaves the model's answers unchanged: the vocabulary is reordered and the internal layers are rotated and shuffled. The cloud fine-tunes and serves the scrambled model and is meant to see only unreadable weights, inputs and outputs. The pass/fail rule, fixed before any run: the design fails if any attack recovers 10% or more of the secret test tokens.

Measured, reference implementation, October 2026, on base model SmolLM2-135M, a firm corpus of contract text (5.26M fine-tune tokens) and a secret test set of 400 passages. The attacker holds the public base model and public statistics of English text only [2].

The scrambling preserves the model's behaviour, and the weight statistics that reveal it barely change under fine-tuning. Adding noise stops the attack only when the model is unusable: recovery falls below 10% when the model's prediction error is 2.9 times the original. A usable fine-tune leaves recovery at 100% [3]. Tested on one small model; larger models were not tested.

Fully homomorphic encryption, which computes directly on encrypted data, avoids this problem and has its own cost. A 2026 implementation (Cited) runs Llama-3-8B on 8 NVIDIA RTX PRO 6000 GPUs with the last 128 input tokens encrypted. It takes 20 s to process the input and 18 s for each generated token [4], about 2.5 hours for a 500-token answer. For comparison, the laptop design in §3 takes about one minute per matter.

---

3. Keep Client Data on the Laptop

If the cloud provider can read any model the cloud runs on client data, the cloud cannot be given client data. The tested design:

1. For each task type, the cloud writes the legal analysis of the statute in advance (the prepared reasoning), with every statutory quote checked. It contains no client data.
2. The cloud stores statute text and that reasoning in a database served by private information retrieval (SimplePIR). The server's view does not depend on which rows are read.
3. The laptop sends a fixed batch of encrypted queries per matter. Every matter, answered or refused, sends the same number.
4. The laptop verifies every fetched record against its hash.
5. A local model picks the matter's task type (task routing) or refuses it, and reads the client's facts as verbatim quotes.
6. Code computes dates and amounts (calculator fields). The model answers the remaining questions (model-judged fields).
7. A grounding check, the gate, stops any answer that does not quote the client file and the statute.
8. The advice note is written and kept on the laptop.

The laptop in every run is a MacBook Air with an Apple M4 chip, 16 GB of memory and 256 GB of storage. The local model is Qwen3-8B, quantised to 4 bits and run with MLX.

Measured, reference implementation, one fictional unfair dismissal matter, October 2026 [1]:

---

4. Code Does the Arithmetic

The blind-counsel study ran in two rounds.

In round 1, Qwen3-8B on the laptop applied the prepared reasoning to three fictional matters. Every automated check passed, and every conclusion quoted the client's facts and the statute. A manual review then found that quoting the sources did not make the conclusions correct: 2 of 10 were wrong and 1 was misleading. The errors were in date and amount arithmetic. The model stated a qualifying period of 2 years 7 months as under 2 years, read the s.124 cap as "no loss", and described a time limit as missed when about four weeks remained [5].

Two changes were made before the final round. First, the arithmetic moved out of the model. The model now extracts dates and amounts only as verbatim quotes from the client file, and code computes service length with the s.97(2) notice extension, the s.111 deadline including the month-end rule, the s.124 cap, the s.145(5) relevant date, and the s.162 payment with the s.227 week's-pay cap. Each of the 15 statutory figures the code uses carries a verbatim quote, re-checked on the laptop against the fetched statute. Second, the prepared reasoning gained notes on common errors, such as "the cap limits the award; it does not negate loss".

The final round, on 6 October 2026, used 8 new fictional matters held out from development and an answer key written before the run [6].

Measured, reference implementation, Qwen3-8B on the MacBook Air M4 [5], [7]:

The round 1 matters were re-run in the final round as a development set and scored 11 of 11 [7].

The score leaves out two findings. First, the model answered "unclear" on fairness for all 5 held-out dismissals, including one where the client file states the reason and no warnings were given, and a lawyer would say likely unfair. This is over-caution. Second, when the notice date was not verified, the scored calculator used the termination date instead of refusing. In the one matter where this happened, the answer did not change [8]. The calculator now refuses on the main branch; tag poc-v1 reproduces the scored run.

---

5. Task Reasoning Fetched Without Revealing the Task

The prepared reasoning of §3 covers only the questions written in advance. The second study adds one LoRA adapter per task to the laptop model: a small set of extra weights trained for that task. It is fetched by private information retrieval so the cloud cannot see which task a matter needed.

Measured, reference implementation, 8 October 2026, 12 held-out fictional matters, Qwen3-8B on the MacBook Air M4, 50 graded fields. The three configurations are the model alone, the model with the prepared reasoning, and the model with the adapter. Novel matters need law outside the prepared reasoning [9]:

No secrets reached the cloud. Every matter in every configuration sent the same 56 text queries and 1,024 adapter queries, and 48 of 48 adapter fetches decoded byte-exact against a public hash list. The adapter, stored at 8 bits, is 46.6 MB. Swapping it into the resident model took a median 20 ms (9 to 30 ms, one outlier of 225 ms) [10]. Training, the retrieval benchmarks and the network test cost about $7 on Modal. The margins are small on a small set.

---

6. What Private Retrieval Costs

The library is the set of adapters the cloud serves. Before any fetch, the laptop downloads a one-time setup file for the library, the hint, of 186 MB here.

Measured, reference implementation, October 2026, SimplePIR with the parameters of its published paper [11]:

Private retrieval pays for large libraries only, and at 1,024 adapters no setting tested is cheap.

---

7. Pre-Registered Verdicts

The two studies, blind-counsel (§3 and §4) and blind-adapters (§5), each fixed their pass/fail rules and answer key before running on matters held out from development [6], [12]. Both failed on the same step, task routing.

The routing failures, in full:

• blind-counsel: a pregnancy discrimination matter, client still employed, was routed to unfair dismissal instead of refused. Downstream checks stopped it. The device answered "dismissed? No" from the client's own words, every calculator refused for missing inputs, and the matter ended as a referral with no advice issued. The rule still counts it as a failure, because routing is a gate.
• blind-adapters: two redundancy matters were routed to unfair dismissal. Both out-of-scope matters were refused.

---

8. Where a TEE Is Required

A TEE runs the model on client data inside isolated, encrypted memory and proves what is running through attestation, a report signed by the chip, on Intel TDX, AMD SEV-SNP or NVIDIA confidential computing.

A TEE moves trust to the chip vendor and its attestation (By design), and TEE security models generally leave hardware side channels and metadata, such as timing and payload size, outside their protection. The design tested here fits one narrow case: fixed tasks over public law, a firm that trusts no chip vendor, and laptop compute that is enough. Drafting, open-ended analysis and large models need cloud compute on client data, and so need a TEE.

Some controls apply with a TEE or without one, because they run on the firm's side: binding a question to the cited statute with legal-rag-router (measured in this case study), and checking each sentence against the statute while the model writes with legal-rag-verifier (measured in this case study).

---

9. Limits

• All matters are fictional. Two task types are covered: UK unfair dismissal and redundancy pay. The held-out sets are 8 and 12 matters. No output has had legal review.
• All work on a matter runs on the laptop: an 8B model on a MacBook Air M4 with 16 GB of memory, at about one minute per matter.
• Open-ended prompts are refused. A new task needs new prepared reasoning or a new adapter.
• Task routing is the weakest gate in both studies.
• The key-based hiding attack was run on a 135M model.

---

10. Reproducibility

All files are linked at a fixed commit, blind-counsel 1930ef9 and blind-adapters c2489f3, so later changes to the repositories do not alter them.

---

11. References

[1] blind-counsel, REPORT.md, section "Milestone 3 proof of concept": the leak, egress, tampering and determinism checks on one matter. Reproduced by run.py. Report section.

[2] blind-counsel, key-based hiding attacks, console output: weights_align.log (both weight attacks at each fine-tuning checkpoint, with the decoded secret sample), keys.log (three further keys), activations.log (internal state while serving) and traffic.log (traffic only). The 99.98% figure is in the report.

[3] blind-counsel, noise against recovery at each drift level, robustness.log; the 10% rule applied, verdict.log.

[4] J. Park, S. Park, J. H. Park, J. H. Ahn, J. H. Cheon, G. Hanrot, J. W. Kim, M. Park and D. Stehlé, "Scaling up FHE-based Privacy-Preserving ML: Higher Throughput, Longer Inputs for LLama-3-8B", arXiv:2601.18511v2, June 2026. arxiv.org/abs/2601.18511. The 2.5 hours is 20 s plus 500 × 18 s.

[5] blind-counsel, round 1 advice notes, dismissal.md and redundancy.md; the manual review of their substance is in REPORT.md, section "Round 1".

[6] blind-counsel, final round answer key and pass/fail rule, written before the run, final_round_key.json.

[7] blind-counsel, final round output, final_round.log: every field of every matter with the expected and returned answer, and the verdict. Scores in results.json; advice notes in results/final_round/memos/.

[8] blind-counsel, REPORT.md, section "Final round": the two findings outside the score and the calculator fix.

[9] blind-adapters, held-out run output with the rule and verdicts, run.log. Scores in held_out_results.json; every step of every configuration in full_results.json; one advice note per matter and configuration in results/held_out/memos/.

[10] blind-adapters, adapter sizes and hashes, adapter_manifest.json; swap times in REPORT.md, section "Held-out results".

[11] blind-adapters, retrieval cost sweep, pir_sweep.json, and the real fetch over a home connection, pir_network_N16_c1024.json. Tabulated in REPORT.md, section "Adapter PIR".

[12] blind-adapters, held-out answer key and rule, heldout_key.json; the pre-registration commit, preregistration.txt.