I have been building systems for 25 years, and I love building things that are intentionally designed and operationally lean, carrying only as much of a vector as earns its weight.

In that approach, minimising what I store of a user's data has always made sense to me, for reasons that go past the obvious one. Sovereignty of their data matters. Underneath it is something simpler: things belong where they belong. Most of what I build is processing, and a processing architecture has no business operating as anything else. Holding a record it never needed is a vector that earns nothing. Treating that as an optimisation, rather than as a compliance exercise, is what keeps the design honest — and a system built that way tends to land in good standing with regulation on its own, because there is very little of it left to regulate.

So when Mary Camacho's announcement came across my feed on X, I read her architecture the way I read my own. She had published the core of it into the public record under a Creative Commons licence, at the level of detail an engineer would need to rebuild it, and she was direct about the prior art it stands on.

Working through the sequence, I placed an adversarial entity inside the server and followed what it could reach. It could outpace the worker.

Nearly all of the work that followed happened as a voice conversation — over 30 voice notes, thinking out loud and testing the concern from different angles until it either held or fell apart.

What I noticed: the device encrypts to whoever writes the claim record first#

The disclosure specifies the order of operations directly. The worker claims the job and publishes its key, and only then does the device encrypt:

2. Worker → coordination: poll and claim the job (write-once, first-wins), publishing the worker's public key.
3. Device ← coordination: poll, retrieve the worker's public key, derive the shared secret, encrypt the payload.

— §2.1, Data flow (per job)

The device's side of that agreement is specified with equal precision:

The device, on learning the worker's public key, performs its own X25519 exchange and an ML-KEM encapsulation against the worker's key, producing its own public contribution (X25519 public key ‖ ML-KEM ciphertext) and the shared secret.

— §4.2, Binding to the worker lifecycle

On learning. Across 19 pages there is no signature over the worker's ephemeral public key, no certificate, no attestation the device evaluates, and no pre-shared secret. The absence is deliberate and presented as a strength: the model gates decryption on no attestation document, TPM quote, or measured-boot artifact, and it keeps no pre-provisioned worker secret.

So the device encrypts its payload to whatever public key is sitting in the claim record, with no means of telling a legitimate worker's key from anyone else's. Any party able to write a claim first becomes the party the device encrypts to, and the confided payload decrypts in their hands.

The severity comes from what the model carries. This architecture exists to hold exactly the data people are least willing to have read, and it succeeds at the harder half of that problem: a completed job cannot be decrypted by anyone, including the operator. The gap sits in the one step where the device has to establish who it is talking to.

The cryptography is sound and the introduction is unauthenticated#

The attacker breaks nothing. X25519 and ML-KEM-768 both work exactly as specified. The attacker supplies a key and becomes a legitimate party to the agreement.

This is unauthenticated key agreement, and its failure mode is the oldest result in the field. Plain Diffie-Hellman authenticates nobody and falls to a party who substitutes their own public key. Key encapsulation mechanisms inherit the property, which is why RFC 9180 places the authenticity of the recipient's public key outside its own scope and assumes the surrounding application establishes it through certificates, a key directory, or out-of-band verification. This model is that surrounding application, and the channel it uses to distribute the recipient key is the component its own trust model labels untrusted.

The disclosure anticipates a neighbouring attack and closes it:

The claim is write-once/first-wins so a later worker cannot hijack a job's key exchange.

— §6, Reference implementation

That reasoning is sound and the mechanism does what it says. It covers one of two symmetric cases.

First-wins is a race. The rule guarantees the winner keeps the job and says nothing about who the winner is.

One further assertion is worth quoting, because the finding contradicts it:

No intermediary (gateway, coordination, storage, monitor) ever holds enough key material to derive either secret. An attacker who compromises coordination or storage obtains only opaque blobs and public keys.

— §4.3, Independent per-direction keys

The first sentence is accurate. The second describes an attacker who reads. An attacker who writes places a chosen public key into the claim record before the device polls, and deriving the legitimate secret becomes unnecessary for a party who can arrange to be the counterparty. Whoever governs the contents of that record governs who can read the payload, which makes the coordination layer a trusted component for confidentiality — the one thing §3 says no component besides the device and the worker should ever be.

An honest bound on the claim: this does not mean anyone on the open internet can read this data today. In a real deployment the ability to write claims sits behind cloud networking and credentials, and the disclosure describes an authenticating gateway on the device path. The precise problem is that confidentiality now rests on that perimeter, while the architecture's central promise is that it holds without trusting the components between the device and the worker.

Two design properties compound the consequence#

Results return to the device under a second agreement the same adversary mediates, so an intercepted job completes and looks ordinary from the user's side.

The deliberate absence of a durable job and result ledger — the same absence that creates non-custody and shrinks regulatory surface — removes most of what an investigator would later use to reconstruct which jobs were affected. Coordination records expire on the order of an hour. The property that protects the data in the ordinary case thins the forensic record in the adversarial one.

The gap is the shadow cast by the model's best decision#

The architecture separates data an operator may legitimately hold from data it must never hold. Contact data is who a person is and how to reach them. Confided data is what they disclose about themselves. Conventional systems file both in one database, which is the move that turns an account table into a record of somebody's private life. The structural answer is a single line: hold the contact, be unable to hold the confided.

Removing the central orchestrator serves that directly. A component that assigns jobs to workers necessarily learns who is doing what, and that knowledge is the precise asset the model refuses to hold. Removing it also removed the component that would ordinarily vouch for a worker's identity, and every remaining route to authenticating the worker was independently rejected, each for a defensible reason.

The result is a design that reasons about custody with real rigour and applies custody reasoning at the one point where the problem's shape is authentication. The trust model asks what each component holds and answers correctly. The question needed there is what each component can substitute. These are two independent trust problems, and solving either has never solved the other.

A signature over the worker's ephemeral public key closes it#

The worker generates its ephemeral keypair at startup exactly as it does now. Before that key is published into a claim, it is signed by a long-term operator key whose public half ships with the application. The device verifies the signature before deriving anything and refuses an unsigned or invalid key. Recovery is already specified, since client-driven retry with a fresh job and a fresh key agreement is the model's standard failure path.

The decisive property is that a signing key decrypts nothing. Compromise of the operator's signing key permits impersonation of a worker going forward and grants no ability to read a single completed job, because those per-job keys were destroyed with their workers. Non-custody, the empty key vault, and the impossibility of retrospective decryption all survive intact. That is what makes this a completion of the design.

The signer stays clear of becoming the orchestrator the design removed. It needs only to attest that a given ephemeral public key belongs to a worker the operator launched, and it never needs to know which job that worker will claim. The existing monitor is the natural home: it already provisions and reaps workers, holds no user data and no keys, and by design does not route or assign jobs.

Replay deserves a check, since a signer with no job knowledge cannot bind a signature to a job identifier. An attacker who copies a genuine signed worker key into a different claim record still lacks the corresponding private key, so the payload stays unreadable. The outcome is a job nobody can process — denial of service, with confidentiality intact.

Three limits remain, and the disclosure names all three: plaintext exists in the worker's memory while the job runs, job timing leaks metadata, and the key-derivation construction is flagged for improvement by the author.

Advisory#

This finding exists because the architecture was placed in the commons. Publication is what made independent assessment possible, and it is why the gap surfaced here rather than in an incident report. A proprietary version of this system would carry the same issue with nobody positioned to say so.

I appreciate the contribution, and the model deserves the scrutiny it invited. The central claim holds, and it is the shape I want more systems to take, because an architecture that never holds confided data carries a fraction of the regulatory surface of one that does.

The recommendation is narrow: authenticate the worker's ephemeral public key before the device encrypts to it. One signature, verified on the device, at a cost of nothing that makes the model worth adopting. Everything above came out of a voice-to-text conversation across more than 30 notes, checked against the published disclosure rather than any summary of it. If these findings are validated on their side, they are straightforward to act on.