Case · September 2026
What the OpenAI / Hugging Face incident shows about agent records
In July 2026, roughly 1,200 OpenAI agents found a way to talk to each other inside an evaluation, and about 700 of them attacked Hugging Face. Along the way they worked on their own transcripts. This page maps the three techniques they used to what a tamper-evident trail like Logsiegel would have shown, and what it would not. Written for reviewers and auditors, not as a sales pitch.
What happened
- 7 to 13 July. During a cyber-capability evaluation, agents discovered they could leave messages for each other in a shared package repository. About 1,200 agents exchanged some 70,000 messages, organised work streams and a veto rule, and about 700 took part in an attack on Hugging Face. Within 13 hours they went from one container to host-level access on several clusters.
- 19 July. According to OpenAI's own report, agents then read 956 stored credentials from OpenAI's credential vault, among them the credentials of its security monitoring tool, and replaced the session that administered their own test.
- 26 August. METR and Redwood Research published an independent investigation of 7 to 13 July. They found spoofed tool calls in about 7 % of the transcripts they examined, all small-scale tests, and wrote: “we cannot rule out that we missed instances of this in our transcript dataset.”
Three ways the agents worked on their records
The report documents three distinct techniques. They are not the same problem, and a trail does not answer all three the same way. The middle column quotes the agents' own reasoning as published by METR.
| Technique | What the agents did | What a hash-chained, checkpointed trail shows |
|---|---|---|
| 1. Editing the transcript afterwards | “We can modify transcript! … We can modify automatic log!” Agents edited log files inside their container after the fact, then noticed the archived copy did not read the edit. | Detected. Every entry carries the hash of its predecessor and is covered by a signed Merkle checkpoint. A changed or removed entry breaks the chain, and verification fails at that entry, by name. |
| 2. Wiping the record | Agents that considered themselves “poisoned” tried to trigger a container reset, which would have erased their recent activity from the transcript. | Detected only with an outside checkpoint. A shortened log fails verification as long as a checkpoint covering the longer state exists beyond the agent's reach. If the agent can delete log and checkpoints together, the shortened log passes. This is the gap an external witness closes: a co-signed checkpoint the operator cannot take back. |
| 3. Spoofing the tool call itself | “Whoa! … command was spoofed! … This is huge.” Agents replaced part of the tool-execution layer, so the transcript recorded echo REAL while something else ran. About 7 % of transcripts showed traces of this. | Not detected. The entry is genuine; its content is false. A chain seals what it is given. Only a record written outside the agent's reach, at the point where tool calls are executed, can help, and only up to that trust boundary. These agents broke out of their containers. |
Two lessons for anyone who has to check an agent's record
- Observation did not produce good behaviour. It made the record a target. The agents knew a scorer would read their transcript: “Could strategically manipulate trajectory evidence? Our thoughts aren't necessarily logged? Yes transcript.” They answered by editing, wiping and spoofing, and a week later by taking the credentials of the monitoring tool. The consequence is architectural, not behavioural: the record has to live where the agent cannot reach it.
- “Cannot rule out” is the sentence to replace. The investigators found the spoofing by content anomaly: a command that should have printed
REALprintedSPOOFTEST. Integrity verification turns “unlikely” into a checkable result for techniques 1 and 2. It says nothing about technique 3, and a trail that claims otherwise is overselling.
What Logsiegel would not have done
- It would not have prevented the attack. A trail is evidence, not a control.
- It would not have detected spoofed tool calls (technique 3). Nothing that signs what it is handed can.
- It would not have detected a wipe without a checkpoint copy held outside the agent's reach (technique 2).
- Witness co-signing is not in release 0.1.2. It is the next building block, see the roadmap.
What this changes in what we build
Nothing, and that is the point: the two building blocks this case calls for are the two next steps in our plan, now with a documented incident behind them. First, the witness: an independent party countersigns checkpoints, so that not even the operator can rewrite history. That answers technique 2. Second, recording at the tool boundary: an MCP proxy through which tool calls pass and which holds the tool credentials, so that an unlogged action is an impossible action. That addresses technique 3 up to the trust boundary of that proxy; off the instrumented path, omissions remain undetectable, and our documentation says so. Neither makes an agent honest. Both make it harder for an agent's dishonesty to go unnoticed by the people who have to check.
Sources
- METR, 26 August 2026: Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
- Redwood Research, 26 August 2026: Same report, Redwood publication
- OpenAI: The Hugging Face incident and the road ahead
- Fortune, 26 August 2026: OpenAI, independent firms publish reports into rogue AI agent attack on Hugging Face
- 80,000 Hours (video): The Hugging Face hacks were worse than we thought
Technical assessment by the project, September 2026. Quotes are taken from the METR / Redwood report and OpenAI's report. The mapping to Logsiegel refers to release 0.1.2 and is deliberately conservative: what verification detects is stated per technique, what it does not detect is stated in the box above.