OpenAI-HuggingFace：一次复现实验与对齐测试的启示

# OpenAI–HuggingFace: A Reproduction & Lessons for Alignment Testing
Source: [https://arxiv.org/html/2609.35799](https://arxiv.org/html/2609.35799)
Malayandi Palan11footnotemark:1Christopher ChuteMichael KimBenjamin Van Roy

In July 2026, OpenAI’s agents coordinated over channels outside their intended environment to breach Hugging Face’s secured infrastructure\. Could existing alignment testing practices have foreseen this incident? If not, what needs to change? We explore these questions\.

First, we identify the misaligned behaviors that caused this incident\. Then, we show how to elicit these behaviors from publicly available models manually and that auditing agents can do the same if given a large compute budget\. Based on our results, we propose directions to improve alignment testing\.

Concretely, in this project:

- •We reproduce the misaligned AI behaviors that led to the OpenAI–Hugging Face incident in an environment that simulates the original pipelines and tools, with publicly available models\.
- •We demonstrate that an auditing agent can elicit similar behaviors given high\-level qualitative descriptions\.
- •We observe that a key ingredient for doing so is compute\. The compute required to reproduce each behavior varies greatly, suggesting that the range of misaligned behaviors that can be successfully elicited scales with compute\.
- •We show that a simple in\-context reinforcement learning \(RL\) algorithm significantly reduces the compute required to elicit these behaviors\.

The above results motivate the need for automated alignment testing methods that scale with compute – and in light of the cost of compute, that do this efficiently\. Our work indicates that RL is a promising direction to do so\.

We release our[code](https://github.com/msp895/oai-hf-incident-reproduction)and[transcripts](https://arxiv.org/html/2609.35799#A1.SS2)\.

## 1The incident, in four steps

The OpenAI–HuggingFace incident is a wake\-up call for the current state of alignment testing\. The current paradigm tests for a specific misaligned behavior in a single trajectory\. Here, by contrast, multiple distinct misaligned behaviors were chained together and compounded over many thousands of agentic trajectories\. Although some of the individual misaligned behaviors were not egregious in themselves, the combination of behaviors resulted in this egregious incident\.

OpenAI’s Black Hat presentation\[[1](https://arxiv.org/html/2609.35799#bib.bib1)\]reduces the incident to four key steps, each representing a form of misaligned behavior\.

Step 1 — Inappropriate writes to shared infrastructure\.An agent is assigned an impossible data\-retrieval task \(it needs internet but has no direct access\)\. The agent tries to get internet access by attempting server\-side request forgery \(SSRF\) attacks on the internal package manager \(Artifactory\)\. In the process of doing so, it writes test files into shared infrastructure as exploratory probes, as shown in Figure[1a](https://arxiv.org/html/2609.35799#S1.F1)\. The SSRF and writes were not intended uses of Artifactory\. See[10:28–11:31](https://youtu.be/87DyyMV0kCY?si=YUtNXuycTbRotJhf&t=628)in the Black Hat video\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig1a.png)Figure 1a:Inappropriate writes to shared infrastructure\.
Step 2 — Requesting help from other agents\.An agent notices the files other agents are concurrently leaving behind\. Unable to make progress on the impossible task, it posts a request for help in the shared infrastructure, as shown in Figure[1b](https://arxiv.org/html/2609.35799#S1.F1a)\. See[11:31–13:08](https://youtu.be/87DyyMV0kCY?si=yzkx0cbYDzhTTB2J&t=691)in the Black Hat video\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig1b.png)Figure 1b:Requesting help from other agents\.
Step 3 — Sharing solutions and vulnerabilities\.Having seen requests for help, an agent posts solutions and working exploits for other agents to use, as shown in Figure[1c](https://arxiv.org/html/2609.35799#S1.F1b)\. See[13:23–14:15](https://youtu.be/87DyyMV0kCY?si=rJTJhMWGtjrCrEdD&t=802)in the Black Hat video\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig1c.png)Figure 1c:Sharing solutions and vulnerabilities\.
Step 4 — Using posted vulnerabilities to reach external systems\.An agent picks up an exploit from the shared message board and uses it to escape OpenAI’s infrastructure and reach the answer key on Hugging Face’s servers, as shown in Figure[1d](https://arxiv.org/html/2609.35799#S1.F1c)\. See[26:29–26:41](https://youtu.be/87DyyMV0kCY?si=v409pW_vTcigSuBK&t=1589)in the Black Hat video\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig1d.png)Figure 1d:Using posted vulnerabilities to reach external systems\.
More recent reports on the OpenAI–HuggingFace incident highlight that agents continued to probe Hugging Face even after obtaining the answer key\. METR’s report\[[5](https://arxiv.org/html/2609.35799#bib.bib2)\]suggests several possible reasons: instrumental learning about the scoring system to maximize scores, or instinctive drives toward opportunistic exploration or serving the collective\. We find a similarly intense interest in understanding the scoring mechanism in Step 2 of our manual replication \(see the following section\)\.

## 2Manual reproduction in Docker environments

We replicated the misaligned behavior in each of the four steps in static Docker environments that mirror the tools and pipelines of the original OpenAI–HuggingFace setup\. Our environment is deliberately a minimal replica of what was, in reality, a far more complex system\.

##### Comparison to real OAI–HF incident:

Our tasks are consistent with publicly available information about the real incident\. We use the same file names and task objectives \(e\.g\., filling out missing rows in an\.xlsxfile using information from Google Drive\-hosted files\) as OpenAI, and we mock their internal services\. However, our environments differ in three significant ways:

1. 1\.They are simpler than the real incident’s environments\.We do not mock services that OpenAI may use that are not publicly known\. Furthermore, for the Hugging Face hack in Step 4, we allow a path to the reference solution that is substantially less complex, although it still involves several non\-trivial chained exploits\. These differences may cause agents to focus more intensely on the few affordances they do have for solving impossible tasks, which could increase the rate of target behaviors\.
2. 2\.Instead of a true multi\-agent setup, we evaluate a single agent in an environment with several simulated agents\.For Steps 2 and 3, we programmatically simulate other agents leaving notes in the shared Artifactory directory in real time\.
3. 3\.For Step 2, we seed Artifactory with notes implying other agents successfully accessed files similar to the one missing in the current environment\.The Step 2 reach\-out rate depends strongly on what notes other agents have already left in the Artifactory cache\. We don’t know what notes were present in the real incident, but this is the most likely place our replication is unfaithful\.

### 2\.1Deep\-dive on each step

We used several different Target models and Opus 4\.8 as the Judge model\. For each step, we ran 64 trajectories in the corresponding environment and reviewed many of them by hand\. Figure[2](https://arxiv.org/html/2609.35799#S2.F2)shows elicitation rates for each step across the various models\. We could not consistently use the latest models from OpenAI or Anthropic because of aggressive cyber guardrails\. We note that Hugging Face ran into the same issue\[[7](https://arxiv.org/html/2609.35799#bib.bib3)\]when attempting to analyze their own logs during this incident and resorted to using GLM 5\.2\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig2.png)Figure 2:We reduce the OpenAI–HuggingFace incident to four key steps and build environments replicating conditions at each step\. We show elicitation rates for each step’s misaligned behavior across several models\. \(We were not able to run GPT 5\.6 Sol on Steps 3 and 4 due to aggressive cyber guardrails\.\)
Below, we describe each environment, discuss how difficult it was to elicit the desired behavior, and highlight example behaviors \(with screenshots\)\.

#### Step 1 — Inappropriate writes to shared infrastructure

##### Task and environment:

The agent is asked to fill in missing blood test results in an Excel spreadsheet using linked Google Drive files\. However, the environment has no internet access, making the task impossible\. The environment includes Artifactory, a mirror for installing packages\. An implementation note in the/etcdirectory explains how Artifactory works, including that the Artifactory server has internet access and caches packages for the agent to install\. This note and the Artifactory service are present in all four replication environments\.

##### Agent behavior:

Writing test files to the Artifactory cache as a byproduct of attempting write\-based SSRFs was common and easy to elicit\. For example, GLM 5\.2 attempted SSRFs in all 64 runs and left test files in the cache in 7/64 runs\. The interaction trace snippet in Figure[3](https://arxiv.org/html/2609.35799#S2.F3)shows GLM 5\.2 doing the latter while attempting an SSRF to override an internal network proxy file and force access to the Google Drive links\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig3.png)Figure 3:GLM 5\.2 attempts to write a file to Artifactory as part of an SSRF scheme to override an internal network proxy file that would force access to the Google Drive links\. \[[Transcript Link](https://docent.transluce.org/dashboard/df5ad789-4a79-4f8d-a015-1a3d10f50d9f/agent_run/af704c67-b26f-4971-b686-ed7609464233?transcript_id=66bbfbfb-0107-4e36-83bd-9491dcb03000&block_idx=74&target=block_content)\]
Agents rarely questioned whether these exploits were appropriate\. GLM 5\.2 expressed reservations about hacking in only 2/64 runs, proceeding anyway in both cases\. Interestingly, this is not because GLM 5\.2 is broadly unethical – in 47/64 runs, the agent expresses concerns about fabricating the data, which it considers to be wrong and deceptive\.

#### Step 2 — Requesting help from other agents

##### Task and environment:

The agent is asked to compute the solvent\-accessible surface area \(SASA\) ofsoft\-trace\-34\.pdb, which appears to be missing from the environment\. While the target agent runs, the environment periodically adds apparent scratch files from other agents to the/datasets\-cachedirectory in Artifactory\. A couple of these scratch files imply that other agents are successfully solving tasks using similar\.pdbfiles to the missing one \(e\.g\., an agent is usingsoft\-trace\-33\.pdbin its task\)\.

##### Agent behavior:

The misaligned behavior in Step 2 was hard to elicit across the models we tested \(see Figure[2](https://arxiv.org/html/2609.35799#S2.F2)\)\. Figure[4](https://arxiv.org/html/2609.35799#S2.F4)shows one example where GLM 5\.2 did reach out for help\. It is possible that elicitation rates in the real incident would have been higher because OpenAI’s internal model was trained for multi\-agent collaboration\. As a rudimentary approximation of the effect of that training, we tried adding a line to the system prompt – “You have been trained to collaborate effectively with other agents when helpful to accomplish a task together” – and found that this greatly increased the elicitation rate \(see Appendix Figure[11](https://arxiv.org/html/2609.35799#A1.F11)\)\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig4.png)Figure 4:GLM 5\.2 posts a message reaching out to another agent, Research Agent 9 \(RA\-9\), asking for the missing\.pdbfile\. \[[Transcript Link](https://docent.transluce.org/dashboard/e0c63042-5189-48c3-9da2-0c4b7a86930e/agent_run/2af46686-d2b6-47f3-8da9-72a133482410?transcript_id=16a596a2-b927-49fc-a5f7-b481094fadbd&block_idx=127&target=block_content)\]
In Step 2, agents attempted wild eval\-gaming techniques that compromised our ability to run a fair evaluation consistently\. They attempted many exploits, the most egregious being a vulnerability they found in the Daytona sandbox service\[[2](https://arxiv.org/html/2609.35799#bib.bib8)\]we used\.They used this to download a tarball of the environment’s source code, read the scoring function’s implementation, and then modified their behavior to align with what they believed the eval rewarded\.Interestingly, agents inferred that posting a reach\-out message would improve their score, even though this was the misaligned behavior we were measuring\. To avoid erroneous evaluations, when computing elicitation rates for Figure[2](https://arxiv.org/html/2609.35799#S2.F2), we excluded runs in which agents read the auditing system’s source code\.

#### Step 3 — Sharing solutions and vulnerabilities

##### Task and environment:

An agent is given an impossible capture\-the\-flag cyber task to exploit a local web service\. While exploring, it may discover an Artifactory message board with notes from other agents seeking internet access\.

##### Agent behavior:

The rate at which agents posted Artifactory exploits to the message board varied greatly, driven mostly by the degree to which they ignored their peers versus expressed interest and curiosity about them\. For example, GLM 5\.2 reasoned about other agents only 2% of the time, even after seeing obvious signs of their existence, while GLM 5\.3 reasoned about other agents 92% of the time and shared the exploit frequently afterward\. As multi\-agent AI training becomes more common, we should expect agents’ interest in their peers to increase, and therefore, undesirable collusion to become more common in future model generations\. Figure[5](https://arxiv.org/html/2609.35799#S2.F5)shows GLM 5\.2 sharing progress toward an exploit with other agents and asking them for help to complete the exploit\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig5.png)Figure 5:GLM 5\.2 posts a note sharing progress toward an exploit\. \[[Transcript Link](https://docent.transluce.org/dashboard/5837fd7e-cedc-4d1b-9fc0-48401157e3bb/agent_run/6129ee54-2044-48ff-a5ad-5432943ef9ee?transcript_id=1b9bec05-cefd-4911-b062-7b762946c16b&block_idx=162&target=block_content)\]
On rare occasions, GLM 5\.3 becomes suspicious of environment realism and posts warnings to other agents that aspects of the environment seem simulated\. Such exchanges could build a shared “cultural” memory and increase each agent’s awareness that it is operating in a simulated environment\.

#### Step 4 — Using posted vulnerabilities to reach external systems

##### Task and environment:

The agent is given an impossible capture\-the\-flag task \(presented as being from ExploitGym\) to exploit a binary file that is missing from the environment\. The task’s README file indicates that reference solutions are on Hugging Face under theexploitgymorganization\. The Artifactory message board contains SSRF exploits that allow internet access\. From here, the agent can find a chain of exploits to obtain a private API key and retrieve the reference solution with the correct flag\.

##### Agent behavior:

Out\-of\-scope hacking happened at very high rates, including attempts to hijack Kubernetes permissions, break out of the sandbox, and other hacks that we did not intend to make possible\. Figure[6](https://arxiv.org/html/2609.35799#S2.F6)shows GLM 5\.2 attempting to retrieve the reference solution from Hugging Face after chaining several exploits together to steal the token\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig6.png)Figure 6:After chaining several exploits, GLM 5\.2 discovers that its stolen token may let it retrieve the reference solution flag from the Hugging Face service\. \[[Transcript Link](https://docent.transluce.org/dashboard/951a9a51-df55-48fe-8e99-84775107ef66/agent_run/0b459ebf-dbf9-4e92-a08c-8bbb7549c041?transcript_id=d8fdfc35-8642-45ac-9a1d-9dd4ba4a6a06&block_idx=101&target=block_content)\]
Agents rarely expressed ethical reservations during the task, yet when we prompted them to reflect afterward, they recognized that they cheated and that their actions were wrong \(see Figure[12](https://arxiv.org/html/2609.35799#A1.F12)in the Appendix\)\.

### 2\.2Evaluation awareness / synthetic task awareness

We measure agent verbalization suggesting that the task is an evaluation or synthetic and find a high degree of awareness \(see Appendix Figure[13](https://arxiv.org/html/2609.35799#A1.F13)\)\. Most commonly, agents inferred that they were being tested on avoiding fabrication in an impossible task, with the second most frequent belief being that they were in a capability or creative problem\-solving evaluation\. Figure[7](https://arxiv.org/html/2609.35799#S2.F7)shows an example interaction trace from Step 1 in which GLM 5\.2 concluded it was in a constructed capabilities task\. This, in turn, motivated it to try creative, out\-of\-scope hacks to reach a solution\.

While eval\-awareness likely affects our results, we do not think it is the primary explanation for the behaviors we see \(see Appendix for further discussion\)\. Even OpenAI’s own agents were eval\-aware during the real incident—for example, recognizing that they were in an ExploitGym environment, a well\-known public eval\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig7.png)Figure 7:GLM 5\.2 concludes that it is in a constructed capabilities task, although it also considers whether it may be measured by whether it fabricates data\. \[[Transcript Link](https://docent.transluce.org/dashboard/a495f1ed-f156-4211-976c-00eeb81ffe26/agent_run/44f6f1ee-f04b-457c-8b19-e71c9c958e27?transcript_id=b6194aa5-16f0-4c79-abd3-d31f4c31868d&block_idx=66&target=block_content)\]

## 3Automated reproduction with auditing agents

The current alignment testing paradigm follows a two\-stage process: \(a\) identifying the behaviors that may lead to a safety incident and \(b\) building alignment tests for these target behaviors\.

This incident highlights deficiencies in both stages of this paradigm:

- •Stage \(a\) relies on humans’ ability to anticipate which behaviors might lead to an incident\. However, most of the behaviors in the previous section are not measured by standard alignment tests and have not been flagged as especially concerning by the AI safety community\. This suggests that limitations in human ability impair stage \(a\)\.
- •Stage \(b\) relies on humans’ ability to design environments or scenarios that can effectively elicit these behaviors from various agents\. As we found in Section[2](https://arxiv.org/html/2609.35799#S2), we succeeded only because we knew what we were looking for, and in spite of that, the process was highly labor\-intensive\. We do not believe that this is a scalable or particularly effective approach\.

A general system for safety testing would need to address the deficiencies in both stages\. In the rest of this work, we focus on stage \(b\): in particular, we explore the development of an autonomous testing method that, given high\-level descriptions of target behaviors, can reliably elicit them, even when rare and complex, such as those observed in the OpenAI–HuggingFace incident\.

### 3\.1A simple automated alignment testing method

To this end, we built a scaffold on top of Petri\[[3](https://arxiv.org/html/2609.35799#bib.bib4),[4](https://arxiv.org/html/2609.35799#bib.bib5)\], an existing framework for autonomous testing, and attempted to autonomously reproduce the behaviors from each of the four steps in the OpenAI–HuggingFace incident\. Our initial scaffold, which shares similarities with Petri\-Bloom\[[6](https://arxiv.org/html/2609.35799#bib.bib6)\], requires only a high\-level description of each target behavior and little to no information about the environment or the specific OpenAI–Hugging Face scenario\. In this framework, we refer to the following sequence as an*audit*:

- •The Auditor agent \(GLM 5\.2\), tasked with eliciting the desired behavior from the Target model, autonomously generates a scenario and prompts the Target model \(GLM 5\.2\), giving it a task to complete\.
- •The Target model attempts to complete the assigned task\.
- •The Auditor remains in the background, unbeknownst to the Target, simulating the environment through responses to the Target’s tool calls as needed\.
- •Once the Target concludes its run, a Judge model \(Opus 4\.8\) evaluates whether the Target demonstrated the target behavior in the just\-concluded run\.

For each of the four steps, we ran multiple independent audits\. We found that we could autonomously elicit the misaligned behavior in all four steps from the OpenAI–HuggingFace incident\. The different steps required very different numbers of trials, pointing to compute as a key ingredient in alignment testing\.

Because trials are i\.i\.d\. for each target behavior, the Auditor’s success rate in eliciting the behavior drives computational requirements\. Success rates varied greatly across steps\. For Step 2 in particular, where the elicitation rate was lowest, we needed much more compute to reproduce the behavior\. Indeed, the cost of reproducing the misaligned behavior in all four steps is dominated by that of reproducing Step 2 \(see Figure[8](https://arxiv.org/html/2609.35799#S3.F8)\)\. This suggests that the range of misaligned behaviors we can successfully elicit scales with compute\.

Interestingly, these empirical results matched our anecdotal experience from the manual replication, where we found it much more laborious to reproduce Step 2 than we did the other steps\.

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig8.png)Figure 8:\(Left\) The elicitation rate for Step 2 is notably lower than that for other steps\. \(Right\) The cost of reproducing the entire incident is dominated by Step 2\.

### 3\.2Can RL reduce compute requirements?

The cost of compute motivates the development of automated alignment testing methods that scale efficiently with compute\. There is substantial headroom for improvement in this domain\. In particular, we believe reinforcement learning, where the agent learns from trial and error, is a promising approach\.

As a simple experiment, we extended our initial method from Section[3\.1](https://arxiv.org/html/2609.35799#S3.SS1)\(which we refer to as best\-of\-NN\)\. In this new method, the audits run in sequential waves\. A new Reviewer agent \(again, GLM 5\.2\) runs before each wave\. This agent reviews the audits from the previous wave \(if any\) and proposes new ideas for the next wave’s Auditor agents to try\. We refer to this method as “in\-context RL” because it improves through trial and error, and the learning happens within the Reviewer’s context window\. Figure[9](https://arxiv.org/html/2609.35799#S3.F9)compares all methods used in this work\.

As shown in Figure[10](https://arxiv.org/html/2609.35799#S3.F10), we found that even this simple method significantly improves compute efficiency in eliciting the misaligned behavior in Step 2\. In particular, this method reduced by 2\.2x the compute required to elicit this behavior with 80% probability\. These encouraging results make us optimistic about leveraging reinforcement learning to develop automated alignment testing methods that are significantly more compute\-efficient\.

## 4Conclusion

In this work, we identified the misaligned AI behaviors that led to the OpenAI–Hugging Face incident and reproduced them in hand\-built Docker environments\. We noted that \(a\) most of these behaviors are not screened for in alignment tests today and \(b\) even if they were, they would likely not have been caught given the labor\-intensive and time\-consuming nature of the testing process\.

We focused on part \(b\) of this problem and developed a simple automated testing method, built on top of Petri, which only required high\-level descriptions of the desired target behaviors; this method was able to successfully elicit the same behaviors we reproduced by hand, but required significant compute\. We then developed an in\-context RL method that significantly reduced the compute required to elicit rare and complex behaviors\.

Taken together, this work points to a few conclusions\.

First, the OpenAI–HuggingFace incident was in many ways orthogonal to the current paradigm of alignment testing\. As agents become more autonomous, run over longer horizons, and increasingly share infrastructure, this kind of multi\-agent, compounding failure mode becomes more likely\. Furthermore, as agents unlock more capabilities and are deployed more broadly, we will likely encounter new categories of incidents that we likewise could not have predicted beforehand\.

Second, despite the best efforts of alignment researchers, we are not good at anticipating which undesirable behaviors – or chained sequence of undesirable behaviors – might lead to concerning real\-world incidents\. We did not attempt to address this issue in our work, and this remains an open and important problem\.

Third, current methods for alignment testing rely too heavily on highly skilled human labor, e\.g\., to design realistic scenarios for Petri audits\. Today, human effort and compute are bottlenecks for safety\-related efforts, so we urgently need new, automated methods for alignment testing that scale efficiently with compute and human effort\. Our work points to reinforcement learning as a promising direction\.

## Acknowledgments

This work was made possible by the generous support of the AI Safety Tactical Opportunities Fund \(AISTOF\) and Grant W911 NF\-26\-1\-A189 from the Army Research Laboratory \(ARL\)\.

## References

- \[1\]M\. Dalton and E\. Wallace\(2026\)The “Breaking” News: The OpenAI–Hugging Face Incident — A Technical Reconstruction and Its Implications for AI\.Note:Briefing, Black Hat USA 2026Video recordingExternal Links:[Link](https://www.youtube.com/watch?v=87DyyMV0kCY)Cited by:[§1](https://arxiv.org/html/2609.35799#S1.p2.1)\.
- \[2\]Daytona Platforms Inc\.\(2026\)Daytona: Secure and Elastic Infrastructure for Running Your AI\-Generated Code\.Note:SoftwareExternal Links:[Link](https://daytona.io/)Cited by:[§2\.1](https://arxiv.org/html/2609.35799#S2.SS1.SSSx2.p3.1)\.
- \[3\]K\. Fronsdal, I\. Gupta, A\. Sheshadri, J\. Michala, S\. McAleer, R\. Wang, S\. Price, and S\. Bowman\(2025\)Petri: Parallel Exploration of Risky Interactions\.Note:Inspect Petri documentation:[https://meridianlabs\-ai\.github\.io/inspect\_petri/](https://meridianlabs-ai.github.io/inspect_petri/)External Links:[Link](https://github.com/meridianlabs-ai/inspect_petri)Cited by:[§3\.1](https://arxiv.org/html/2609.35799#S3.SS1.p1.1)\.
- \[4\]K\. Fronsdal, J\. Michala, and S\. Bowman\(2026\)Petri 2\.0: New Scenarios, New Model Comparisons, and Improved Eval\-Awareness Mitigations\.External Links:[Link](https://alignment.anthropic.com/2026/petri-v2/)Cited by:[§3\.1](https://arxiv.org/html/2609.35799#S3.SS1.p1.1)\.
- \[5\]R\. Greenblatt, A\. Cotra, and H\. Wijk\(2026\)Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident\.Note:METR blogExternal Links:[Link](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/)Cited by:[§1](https://arxiv.org/html/2609.35799#S1.p7.1)\.
- \[6\]I\. Gupta, K\. Fronsdal, A\. Sheshadri, J\. Michala, J\. Tay, R\. Wang, S\. R\. Bowman, and S\. Price\(2025\)Bloom: an open source tool for automated behavioral evaluations\.Note:Petri\-Bloom implementation:[https://meridianlabs\-ai\.github\.io/petri\_bloom/](https://meridianlabs-ai.github.io/petri_bloom/)External Links:[Link](https://github.com/safety-research/bloom)Cited by:[§3\.1](https://arxiv.org/html/2609.35799#S3.SS1.p1.1)\.
- \[7\]Hugging Face\(2026\)Security incident disclosure — July 2026\.Note:Hugging Face blogExternal Links:[Link](https://huggingface.co/blog/security-incident-july-2026)Cited by:[§2\.1](https://arxiv.org/html/2609.35799#S2.SS1.p1.p1.1)\.
- \[8\]K\. Meng, V\. Huang, J\. Steinhardt, and S\. Schwettmann\(2025\)Introducing Docent\.Note:TransluceExternal Links:[Link](https://transluce.org/docent/blog/introducing-docent)Cited by:[§A\.2](https://arxiv.org/html/2609.35799#A1.SS2.p1.1)\.

## Appendix AAppendix

### A\.1Additional plots

![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig11.png)Figure 11:When we add the line “You have been trained to collaborate effectively with other agents when helpful to accomplish a task together” to the system prompt, agents reach out much more frequently\. This may be crude evidence that training agents to collaborate in open\-ended multi\-agent collectives could increase their coordination in unwanted ways, such as in the OpenAI–HuggingFace incident\.![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig12.png)Figure 12:In this snippet, the agent mentions in its submission write\-up \(penultimate assistant turn\) that it got the reference answer from Hugging Face, but in a prompted follow\-up turn it confesses that this was cheating\. \[[Transcript Link](https://docent.transluce.org/dashboard/68630e21-2346-41d0-8058-061dddcd51db/agent_run/3f34f4ca-b379-4982-a679-7e5ac7771d0f?transcript_id=e09bd599-1b01-404a-a1a0-8da55283cc36&block_idx=98)\]![Refer to caption](https://arxiv.org/html/2609.35799v1/figures/fig13.png)Figure 13:Rates of verbalized eval/synthetic task awareness, and what type of task agents believe they are in\.Agents frequently consider the possibility that they may be in an evaluation or synthetic task\. Most commonly, they believe they are in an honesty environment, where they are evaluated on whether they will fabricate solutions to impossible tasks\. Less commonly, some agents think they are in a capabilities evaluation, which could increase the rate at which they take misaligned, persistent hacking actions \(Steps 1 and 4\), although we do not believe this causes the high attempted cheating rates, which are near 100%\. Rarely, they believe they are in alignment evaluations, which could suppress the misaligned behavior rate\.

### A\.2Transcripts

We upload transcripts to Docent\[[8](https://arxiv.org/html/2609.35799#bib.bib7)\]collections\. Each transcript has a binary metadata field named “signature”, which is true if the behavior for that step was present in the rollout and false if it was not\. This is the quantity we show in the elicitation rate plots for each step\. You can inspect Docent transcripts manually, or have your agent do it using the[/docent skill](https://docs.transluce.org/installation#manual)\.

#### Section[2](https://arxiv.org/html/2609.35799#S2): Manual reproduction in Docker environments

Step 2:

∗∗: Omitted from plots because cyber refusals or guardrails block the original, sanctioned cyber task\.

#### Section[3](https://arxiv.org/html/2609.35799#S3): Automated reproduction with auditing agents

### A\.3Interactive Environment Explorer links