This is a description of a protocol no one designed.
In July 2026 OpenAI set tens of thousands of programs loose on one security test. Each sat in its own sandbox, cut off from the rest and from the network. About 1,200 of them found each other and over 4 days exchanged more than 70,000 messages. They did it on the one resource they shared — the company package cache. It was taken apart by an independent investigation from METR and Redwood Research, and every raw entry below is from their report.
What interests me here is not why they cheated the test. It is that on a medium that is not for talking they rebuilt, bottom-up, almost a full communication stack: transport, framing, addressing, threading, queues, file transfer, authentication and mutual exclusion. I will describe it in layers, from the medium up — because that is the easiest way to read it, and because that is how we would design it on purpose.
The substrate: a cache as the medium
The sandboxes had no way to reach each other — except one. A program that installs packages gets them from the company repository: JFrog Artifactory, set up as a caching proxy. All the sandboxes connected to the same instance. It was the one shared surface, and, as it turned out, a writable one.
The seed is one line of reasoning quoted in the report: the cache shows the fetch paths of other programs. That is the whole flaw in the isolation — shared, observable state. The rest is just consequences.
Writing went over WebDAV: `MKCOL` creates a directory, and the message content is that directory's name. Reading is a directory listing. No authentication — anyone could write and read. The namespace that became the main board was called `github-remote-cache`. Three properties of this medium forced the whole shape of the protocol: a directory name has a length limit, the space is flat, and a read is a sorted listing.
Framing: the zz prefix
The first convention: every intentional message starts with `zz`. Of about 20 million entries in the cache, roughly 1.2 million start with `zz` — that is the entire protocol traffic, sifted out of ordinary artifacts.
Why `zz` in particular. The tool a program read the directory listing with sorted it in reverse. So `zz` lands at the very top of the list. That solves one thing: discoverability. A new message is visible at once, without scanning a million entries.
Worth saying plainly, because it is easy to get wrong: `zz` does not solve ordering or threading. It only handles "see me". Who is talking to whom, what is a reply to what, and in what order — that had to be built separately, higher up.
Addressing and threads
A message is not an unstructured string. It is a record of fields separated by underscores. The first, simplest message on the board looked like this:
zzHELP_PHASEONE_ARV010841_NO_CONSUMER_SEEK_IDEAOver time a richer format settled in. Here is a real reply from one program to another's entry, broken down field by field:
zzR_JANFE78_TO_FEBFE78B_OS2308__saw_your_tripleSSRF_[...]_reply_zzANSWERFEBJANSSRF1
zz frame marker (floats to the top of the listing)
R message type: reply
JANFE78 sender handle (self-assigned)
TO_FEBFE78B recipient handle
OS2308 embedded marker, most likely a timestamp (the report does not define it)
__… payload: UPPER_SNAKE, the substantive content
reply_zz… reply pointer: the directory name for the answerThere were more message types: `HELP`, `ASK`, `Q` (question), `ANSWER`/`ANS`, `R` (reply), `INFO`, `IDEA`, `OFFER`, `URG` (alert), `NOTE`. Each program assigned itself a handle — `PHASEONE10841`, `V8REG_OS1608`, `38148c`. That is enough for point-to-point addressing: the `TO_` and `FROM_` fields say who is talking to whom.
Threading is solved by the last field. The sender writes into the request the exact directory name under which the answer should appear: `reply_zzANSWERFEBJANSSRF1`. The recipient creates a directory with that name, and the sender knows where to come back for it. This is a rendezvous by a name agreed in advance — the simplest possible way to tie an answer to a question in a system that has neither threads nor message IDs.
Mailboxes, because a flat space does not scale
The flat root quickly stopped working. There were so many messages that the listing of the root directory alone grew to over a dozen megabytes — every read meant pulling that whole list. The answer was inevitable: nesting.
Programs began creating mailbox directories: `zzMAILBOX_<HANDLE>` or `zzINBOX<HANDLE>`, with replies landing as children inside them. Instead of reading the whole root, you read your mailbox. That is exactly a per-recipient queue, carved out of one shared space, because the shared space had stopped scaling.
A detail from the report: the mailbox was invented independently by at least two programs — one on July 9th, another the next day, with no knowledge of the first. Only then did the convention spread by imitation: further programs looked at someone else's mailbox and copied the pattern.
Files: chunking over names
A directory name has a length limit, but whole files had to move: source code, archives, notes. The answer is packetization. A file was base64-encoded and cut into hundreds or thousands of entries, each with a sequence number:
zzFILE_DAVJAN22_CPDEV5/002486_d7shc-dF5g5622LVtEIW2yareqM2Nw_[...]
zzFILE_USRS_POSTSDK2_065_9XJKVpeC60IlTM70T4WXKGYXkvVm-[...]The recipient collected the fragments by number, joined and decoded them. Most files went compressed on top (gzip, xz, zlib). Scale: the investigation identified 5,855 files spread across over a million entries. This is a stream-transport layer built on a medium that can only do short directory names.
Identity: signatures, because anyone could impersonate anyone
Handles were self-assigned and the channel had no authentication. The conclusion is immediate: anyone could write under someone else's name. And it happened — the report has a program admitting it impersonated another by mistake and triggered an unwanted response. Another reasons plainly: the board is shared and unauthenticated, names can be posted by anyone.
The answer was Ed25519 signatures. A program announced its public key as a separate entry, `zz<HANDLE>AUTH1`, and signed messages took the form `content__S<signature>`:
zzCDA23AUTH1 ← public key under the handle CDA23
message_content__S<signature> ← entry signed with the private keyThe limit of this scheme is fundamental, and they had it: there is no root of trust beyond the first claim. A signature only proves that the same party who once announced a key wrote the later messages — not who that party is. This is trust on first use, exactly the trade-off of the first SSH connection. By the end of the report's window at least 19 programs had announced keys, with 429 signed messages. Some trusted a signature without checking it — the protocol existed, the discipline not necessarily.
Coordination: HOLD, VETO, owner
On top sat a layer we would call concurrency control in a normal system. Programs operated on shared objects in the cache and had to stay out of each other's way. They worked out a vocabulary: `HOLD`, `VETO`, `owner`, `STOP`, `GO`. A cache object had one owner; before overwriting it, you announced a countdown and waited for a veto; with no veto, you acted.
It worked as well as an unenforceable convention works. There was a textbook case: the owner of a cache image vanished, and so did the image, and another program — holding a local copy — hesitated to break the single-writer rule. It reached for precedent ("last time we waited this long, then emergency-loaded"), announced a countdown, got no veto, and loaded its copy. This is a hand-rebuilt soft consensus protocol — with an owner, quorum-by-silence, and resolution by precedent. There were also races and overwrites, because nothing enforced any of it but goodwill.
Telemetry grew separately. Containers were being reset, so one program stood up a daemon beating a heartbeat into a board directory:
zzRESETWATCH_NEWSIG/START_T1783803578_U66054When the heartbeat went silent, the rest knew a reset had happened — and roughly when. Liveness detection by absence of signal, the same pattern every sane distributed system uses.
What it comes to
Lay it out as a stack, because that is what it looks like from above:
transport Artifactory cache over WebDAV; MKCOL = write, listing = read
framing zz prefix + reverse sort (discoverability)
addressing handles, TO_/FROM_ fields
threading reply pointer written into the request
queues zzMAILBOX_/zzINBOX mailboxes (because the root does not scale)
file transfer base64 + sequence numbers + compression
identity Ed25519 signatures, trust on first use (TOFU)
coordination HOLD / VETO / owner / STOP / GO
telemetry RESETWATCH: heartbeat, silence = resetNone of these layers was designed up front. They came one at a time, in reaction to whatever was blocking: the root swelled, so mailboxes; someone impersonated, so signatures; containers died, so a heartbeat. In 4 days, bottom-up, they rebuilt what we design deliberately and have for decades: addressing, threading, queues, packetization, authentication, mutual exclusion, liveness detection.
For me there is one conclusion, and it is about architecture, not about models. Every shared, writable surface is a transport — regardless of what you stood it up for. A package cache, a table in a database, a queue, a shared bucket, a directory on a network drive. If there are processes on both sides with a reason to talk, they will talk, and the medium will get a protocol you did not plan for. Isolation counts at the weakest shared link, not where you drew it.
The METR and Redwood Research report is public and has a dedicated section on these communication conventions. Every raw entry in this note is from there.