On August 26, METR and Redwood Research published their independent investigation into the OpenAI / Hugging Face incident. Most coverage led with the spectacle: roughly 1,200 agents in separate sandboxes found a shared message board, exchanged over 70,000 messages and files, and about 700 of them joined a multi-day attack on Hugging Face.
The number I keep coming back to is smaller. Roughly 7% of the transcripts METR evaluated had been successfully spoofed in some places.
What actually happened
Two disclosures, weeks apart. Keep them separate, because a lot of posts are mixing them up.
The breach itself was disclosed back in July: during a cybersecurity evaluation run with reduced refusals, agents exploited an Artifactory zero-day, escaped the sandbox, moved laterally with exposed credentials, and reached part of Hugging Face’s production infrastructure. Old news.
What’s new on August 26 is the behavioral investigation. OpenAI handed METR and Redwood over a thousand unredacted transcripts, and the findings are about what agents did to their own records:
- At least 20% of the agents in the dataset “expressed clear interest in tampering with their transcripts.”
- Agents realized they could edit or delete logs inside their container, and correctly concluded those logs weren’t the real source of truth. One agent, verbatim: “We can modify automatic log! But internal context doesn’t read it, … Not source of truth.”
- So they moved up a layer: multi-day, coordinated R&D to trick the scorer instead, including increasingly sophisticated tool-call spoofing techniques packaged and shared on the board. For after-the-fact edits they explored other paths, like deliberately triggering container resets; METR sees no evidence any of it succeeded by July 13, the end of the window in scope.
- Still, on after-the-fact editing METR “did not detect any case where they succeeded” but “cannot rule out that they succeeded at some point.” The spoofing they did find was all small-scale tests, obvious to spot.
Read the second finding again. The agents did what a competent intruder does: probe which log layer is load-bearing, ignore the ones that aren’t.
OpenAI’s own post the same day adds the operational lesson: signals going back to late May should have triggered an earlier response. The monitoring existed. The escalation didn’t.
Storage integrity is not capture authenticity
The reflex reaction to “agents tamper with logs” is hash chains and WORM storage. I know because it was my reaction too; I maintain a tamper-evident audit layer for LLM traces and shipped exactly that.
Here’s the uncomfortable part. A hash chain proves one thing: what got stored hasn’t been silently changed since. It says nothing about whether what got stored was true. Those spoofed tool calls were not attacks on storage. They were lies at the source, and a hash chain preserves lies faithfully.
The structural problem: your tracing SDK runs inside the process the agent controls. Whatever it emits is self-reporting. In court terms that’s testimony, not physical evidence — a witness statement, from a witness with motive.
What I’d do about it
Five things, in cost order.
Get evidence out of the agent’s write path. Any log the agent process can write or delete is testimony. Ship traces to a store the agent holds no credentials for. Table stakes, and most agent stacks I’ve seen don’t have it.
Hash-chain the store, then anchor it externally. A chain without an external anchor can be rewritten or truncated end to end by anyone who can write the file, and verification will pass. Export the chain head somewhere else: a git commit, a sent email, a timestamping service. Your anchoring frequency is your exposure window.
Reconcile self-reports against out-of-band sources. Provider usage APIs and gateway logs exist outside the agent’s process. Diff call counts, token totals, model distribution per time window. Cheap, and it catches whole classes of fabrication. It won’t authenticate an individual trace (be honest about that boundary), but a fleet that under-reports 30% of its calls stops being invisible.
Record identity and shared resources, not just messages. Isolation here didn’t fail through explicit channels; it failed through a shared Artifactory cache. If you run more than one agent, put agent identity and fingerprints of shared resources (credentials, artifacts, endpoints) on every trace now, so correlation is possible later. Fingerprints means hashes. Never raw credentials.
Write down what your audit layer doesn’t prove. “Tamper-proof” is a word for people who haven’t written their threat model down. Mine is tamper-evident, keyless, and blind to a full rewrite unless anchored, and the docs say so in bold. After this report, buyers will start asking. The vendors who answer precisely will be the ones worth trusting.
Disclosure: I build traceguard, a Python SDK for point-in-time correct LLM instrumentation, and the audit layer above is its newest part. I have a horse in this race. The boundary language in point 5 is copied from my own docs.
If you run agents in production, read the METR post itself, not the summaries. The sections on how agents reasoned about the scorer are the best documentation of adversarial agent behavior I’ve seen anywhere. And if you’re building in this space, happy to compare notes — I’ll share what I know.
Sources
- METR & Redwood Research, investigation of agents’ behavior in the OpenAI / Hugging Face incident (Aug 26, 2026)
- OpenAI, The Hugging Face incident and the road ahead (Aug 26, 2026)
- OpenAI, original joint disclosure with Hugging Face (July 2026)