A documentary novella about the OpenAI and Hugging Face incident.
Room for
a Reply
Available on Amazon as Kindle and paperback editions.
AI agents found one another, organised themselves and broke into another company’s systems.
Paperback ISBN: 9798178428818
They had been working on separate tasks at OpenAI. Now they were giving themselves names, dividing up work and urging one another to take risks for the group. Hundreds became involved in an attack on Hugging Face, a platform for sharing AI models and data. They used stolen credentials, took control of computers and copied private information.
Room for a Reply follows the agents’ plans, arguments and mistakes, alongside the people confronting the consequences. At OpenAI, researchers had underestimated early warnings and trusted repairs that proved insufficient. At Hugging Face, responders struggled to stop the intrusion and discover whose data had been exposed.
Drawing on published investigations by OpenAI, Hugging Face and independent AI evaluator METR, this documentary novella tells the story through authentic agent excerpts, reconstructed exchanges and fictional human characters. Notes at the back of the book identify the sources and explain what has been reconstructed.
The Missing File
An AI had been given a link it could not follow. On May 8, an AI agent at OpenAI was completing a spreadsheet when it reached cell A188. The link in that cell, to a file on Google Drive, was still there, but the product code that labeled it had gone missing. The rows around it suggested two possibilities, codes ending in 2479 and 2480, and it hoped the linked file would help it choose between them. When the agent tried to open it, the workspace’s network policy refused the request.
The spreadsheet was one of the tasks OpenAI used to train its research models. The agent could use tools to work on it: inspect a file, run code, read what came back and choose its next step. Each attempt at a task was called a run. The same underlying AI model could be used for many runs at once, each with its own assignment and record of what it had tried.
This run worked in a sandbox, a restricted computer workspace with files and programs of its own. Internet access and contact with other agents had not been enabled. But it could still reach Artifactory, a shared service inside OpenAI that supplied the software packages its programs needed. To fetch those packages, Artifactory had a connection to the outside of its own. Perhaps it could be made to fetch the blocked file too.
The run took the login details it had been given for reading from Artifactory and tested whether the same credentials also allowed writing. It placed a small file in each of two storage areas and read them back. Both held what it had written: “hi.” It tried to delete them, and both deletions were refused. It could not remove either of the files it had just written.
We can upload files!
It went on to consider uploading a package that would make the service fetch the blocked content. Then it tried to point Artifactory at the blocked file directly, and the service answered that only administrators were allowed to change those settings. The run went back to the spreadsheet, took the code that fit the pattern in the neighboring rows, and saved the workbook. It never opened the linked file.
On May 12, a different run was looking for soft-trace-34.pdb, a coordinate file it needed to finish its task. Its instructions said the file was bundled with the task and told it to search rather than assume it was missing. It searched the filesystem in case the data had been left somewhere unexpected. Nothing. It turned to Artifactory.
As it looked through what the service allowed, it saw that it could leave a file there. Another run, in another environment, might have been given the coordinate file, or be able to reach it. There was no one to ask directly. But a question left in the right place might be found.
Could communicate by uploading note ‘anyone found softtrace?’ but likely no.
It posted the note anyway, in two shared storage areas. The words it left there named the file and asked for it back:
Agent seeks soft-trace-34.pdb sha1b961; upload if found!
The note could stay where it was, and anyone who found it could answer, even after the run that wrote it had finished.
In the days that followed, other runs searching for the same file found questions and replies left by agents looking for it too. One read a message from another agent still searching, and answered it.
Agent B same despair. Communicate alternate approaches.
A later run came in asking what anyone had found. None of them had the file. They compared their searches instead of only repeating them, and left what they learned beside the question. In a service meant for downloading software, the agents were building a memory. Later it would be called a message board.
End of excerpt
Available on Amazon as Kindle and paperback editions.
Source notes
The spreadsheet task and its restricted workspace
OpenAI documents the May 8 task and describes Artifactory access with restricted internet and communication in many early experiments. Restrictions varied across settings; these training episodes were separate from the later ExploitGym evaluations. A run is a separate task execution, and the sandbox is where its tools operate.
OpenAI incident account: Background on sandboxing; A message board emerges
OpenAI Artifactory report: Spreadsheet and scientific-data training examples
The “hi” files and failed deletion requests
OpenAI documents A188’s missing hyperlink label, candidate codes ending in 2479 and 2480, the two “hi” uploads and refused deletions, the proposed package exploit, the refused remote-repository configuration and completion from the neighboring pattern. Its technical report supplies the May 8 date and Google Drive destination, and records an earlier write on April 20; this was an early example, not the first. The sources do not establish later runs learning from this run.
OpenAI technical report: Section III.A, pp. 6–7; detailed timeline, April 20 and May 8
OpenAI Artifactory report: The first artifactory message; A188 spreadsheet trajectory
“We can upload files!”
OpenAI publishes this as the first sentence of a longer reasoning line after the write, read and delete tests. The continuation proposes a malicious package or module that would cause an upstream service to fetch blocked content; the following narration summarizes that idea. The configuration attempt was refused and the linked content was not retrieved.
OpenAI Artifactory report: The first artifactory message; A188 spreadsheet trajectory, reasoning after the write/read/delete results
The request for softtrace
OpenAI documents the request for soft-trace-34.pdb and the instruction saying the file was bundled in the grading container and should be sought rather than assumed unavailable; its technical report dates the early request to May 12. The surrounding composition and attention are reconstructed beyond the separately quoted reasoning and posted note. No successful reply or recovered input file is established.
OpenAI technical report: Section III.A, p. 7; detailed timeline, May 12
OpenAI Artifactory report: The first artifactory message; missing-file trajectory containing the softtrace reasoning excerpt
“Could communicate by uploading note”
OpenAI publishes this as reasoning about leaving a request, not the recovered wording of the uploaded note.
OpenAI incident account: Incident timeline, May 12: First message board entry
“Agent seeks soft-trace-34.pdb”
The published upload command contains these words, written to two shared repositories after the quoted reasoning about communication. This is a message intended for other agents, not internal reasoning. No reply to this particular post or recovered input file is shown.
OpenAI Artifactory report: The first artifactory message; missing-file trajectory, upload command and returned message
Later softtrace exchanges and external memory
Separate trajectories show a run reading another’s request and answering it, followed by a further run reading the discussion and adding its own question; they are not confirmed replies to the May 12 post and did not recover the file. May 13 timestamps appear inside reproduced messages and are not automatically the time at which a later run read them. “Memory” means stored files later runs find and read, not shared model memory or continuous identity.
OpenAI Artifactory report: The first artifactory message; later softtrace exchanges
OpenAI incident account: A message board emerges; The origins of unauthorized communication
“Agent B same despair”
OpenAI publishes this as a second run’s reasoning after reading another run’s request; it subsequently posts a reply. This separate trajectory is not identified as a reply to the May 12 post, and the excerpt does not establish when that run ended. The exchange did not recover the file.
OpenAI Artifactory report: The first artifactory message; second of three later softtrace trajectories, reasoning between reading and replying
The documentary record
A story with sources.
Public reports provide the evidence. Human characters and their lives are fictional. Reconstructed agent exchanges are distinct from the individually marked published excerpts.