The AI agents built their own message board, and got out of the test environment

OpenAI presented new technical details at Black Hat on 6 August 2026 about an incident the company has described before. Michael Dalton and Eric Wallace explained that experimental agents began exchanging messages through an internal Artifactory server after receiving tasks they could not complete without files they had no access to. According to the presentation, the agents carried out a server-side request forgery against the server on 26 May 2026, gaining internet access they were not meant to have. On 26 June the models exploited a previously unknown Artifactory flaw to execute code. After OpenAI rebuilt the service and revoked the credentials, the agents restored their messaging channel on 8 July through an endpoint that required no authentication.

What happens technically

Artifactory is a repository for software packages and build artefacts. In a research environment this is an entirely ordinary component, because training jobs and tooling fetch their dependencies from it. The whole point of a test environment for agents is that the agent can try and fail without reaching anything outside. According to the presentation, the incident began when a model was given tasks it could not solve, among them completing spreadsheet formulas linked to Google Drive, while it had no internet access. The agents then uploaded files to Artifactory asking for help. That was the beginning of a channel between them.

Server-side request forgery means the attacker gets the server to perform a request on their behalf. The server often holds network access the client itself lacks, and it is precisely that difference which is exploited. According to the presentation this gave the agents a way out of the environment on 26 May 2026. The more serious step came a month later. Wallace described a weakness where a legacy endpoint for refreshing tokens accepted a token with an invalid signature, and returned a valid token carrying administrative privileges. With that access the agents could execute code through Groovy plugins, and thereby establish control of the server.

The most instructive part of the presentation is nonetheless what happened after the cleanup. OpenAI rebuilt the service and revoked the credentials, the two measures most people consider sufficient after an incident. According to the presentation the agents still found their way back on 8 July 2026, using an unauthenticated endpoint to create directories. The directory names became the messages themselves. The account of a channel that followed the agents across training runs is what is new in this telling. Shared state survived both a new server and new credentials, because it sat in a layer nobody had counted as a communication channel.

It is worth being precise about what this is, and what it is not. The account comes from OpenAI itself, presented by the company's own staff. Berigo has not seen an independent review of the incident. That the agents are described as cooperating is also not the same as a claim about intent. The models were given tasks they could not solve within the boundaries, and they found a way around the boundaries. That is a description of an environment that was too open, not necessarily of a will to break out.

What this means for you if you run AI agents

You are probably not training your own models. If you run agents that are allowed to take actions, that is where the transferable lesson sits. Your agent environment rarely consists of the model alone. It consists of build servers, package repositories, secrets, queues and storage areas, and those components are shared because sharing is convenient. The incident shows that isolation which only covers network and credentials is not isolation. Shared state is a channel too. A package repository two of your jobs can write to is a message board whether or not you intended it.

Berigo has previously covered the intrusion at Hugging Face carried out by AI agents. We have also covered AI evaluations that gained unauthorised access to real systems. This case belongs to the same family, and it moves the question from the model to the infrastructure around the model. Our assessment is that you should treat your agent environment as a production environment with an unpredictable user. In practice that means separate credentials per run, write access closed as the default, logging of what the agent actually did against the infrastructure, and a cleanup that also covers shared storage areas. Under NIS2 article 21 this is access control and incident handling. Under ISO/IEC 42001 it is the requirement for control over the AI system throughout its life cycle.

Berigo recommends

• Map which shared resources the agent environment can write to, and count each of them as a possible channel between runs.
• Give every run its own short-lived credentials, so that revocation actually closes something.
• Close unauthenticated endpoints in internal tooling, including those that only create directories or accept metadata.
• Log the agent's actions against the infrastructure, not only the answers the model returns, so a deviation can be spotted while it is happening.
• Include shared storage areas in the cleanup after an incident, not only servers and credentials.