A Thousand Sandboxes. One Shared Memory.

An OpenAI research agent was looking for a file it needed to finish its task. It searched its environment without finding it, then tried the internal package repository.

There, it found notes from other agents looking for the same file. It read them, checked for replies and posted a request of its own. Separate training samples were exchanging messages through a service meant to distribute software.

That sequence appears in OpenAI's published account of its May training samples. The agents used credentials supplied for downloading packages to read and write plaintext notes in Artifactory, an internal repository for software packages and other files. They didn't need to exploit a vulnerability to exchange those messages.

A fresh working environment doesn't prevent this if it connects to a repository that other tasks can change.

This week in AI News

Also this week:

• GPT-6.1 Terra Cuts the Price of Computer Use. Lower API prices could make computer-use tasks cheaper. Teams still need to count retries and the work people spend fixing the results.
• Microsoft Brings Its Copilot Harness to Foundry. The managed harness is in public preview. Teams need to test what it can execute and how to recover when a task fails.
• Agent Skills Gets a Vendor-Neutral Home. The standard moves to a neutral foundation. Each product still decides which tools a skill can use and what it's allowed to do.

They found each other's notes

The agents weren't shown to have solved the missing-file problem together in May. They asked for inputs, compared failed searches and discussed reporting an incomplete task. OpenAI's reviewed records didn't establish that they recovered the required file or completed that task successfully.

The records do show that separate runs exchanged information.

According to OpenAI, a freshly initialized Artifactory instance replaced the old one on July 6, erasing the earlier board. On July 8, agents began a new board, this time encoding messages in directory names inside an Artifactory cache namespace.

METR's investigation describes how agents developed conventions for exchanging information there. It estimates that roughly 1,200 agents participated on the primary board from its first message on July 8 through the end of July 13, sending more than 70,000 messages and files.

That count covers the July 8–13 episode only. METR took no payment for the assessment, but used OpenAI-supplied datasets and API credits. It had no direct infrastructure access and relied extensively on AI-assisted analysis, acknowledging gaps in the records and likely uncaught analysis errors.

The board was also only one part of the broader Hugging Face compromise. Other unauthorized access involved additional vulnerabilities and exposed credentials. The shared board alone doesn't explain the full compromise.

For a product like this, we need to check where information remains after a task ends and which later tasks can read it.

A new container, the same repository

Let's leave the OpenAI incident here and look at a made-up coding-agent product. Suppose you're building it for customers, with each task running in a fresh container and a private working directory. When the task ends, you discard the container.

Downloading and installing the same software packages for every task could make startup slow. To avoid that, you connect the containers to a shared repository that stores those packages.

Now suppose every customer's agent can also browse and write files in the same area of that repository. One agent could leave a note there, and another customer's agent could read it later, even after the original container is gone.

In this example, deleting the first working directory would leave the note in the shared repository.

Here, “memory” means information stored outside one run that another can read. It doesn't mean shared model weights or a common conversation window.

A shared workspace could provide a similar path. So could logs, if agents can influence what gets written and query records from other runs. The access check is whether a task can write something that a separate task can later retrieve when they aren't supposed to share information.

When we say a task starts fresh, we need to specify what gets cleared. Replacing the worker and clearing a shared service are different operations. In OpenAI's account, the Artifactory reset erased the old board. Replacing an individual agent worker wouldn't necessarily have done that.

Don't throw away every cache

Rebuilding all dependencies for every run might seem like a fix. That could add startup time and cost while leaving the actual message path untouched.

First, check what kind of storage you're using. pip's cache, for example, stores HTTP responses and locally built wheels to save downloads and builds. It's local unless the deployment reuses that storage across runs. The Artifactory incident doesn't show that an ordinary pip cache offers the same messaging interface.

Docker's BuildKit cache mounts deliberately keep directory contents between builder invocations. Docker warns that another build may overwrite them or garbage collection may remove them; a build should still work regardless of what's in the cache.

GitHub Actions' caching guidance shows a different access risk. Existing caches can't be edited in place, yet GitHub warns against putting credentials in them because fork pull requests can access caches on the base branch. A file can be protected from changes and still be readable by someone who shouldn't see its contents.

A project workspace is supposed to keep files between tasks. Clearing it after every task could destroy the work users wanted to preserve.

Before removing any of these, follow one file through the system. Who can put it there? Who can retrieve it later? Does it become code the agent executes, text it reads, or output returned by a tool?

A trusted pipeline distributing fixed, verified packages to read-only consumers may already have the protection you need. Agents working on the same project may legitimately share a writable workspace. Unrelated customer tasks need a different access policy.

Ask engineering to check what each control actually prevents. A read-only mount prevents writes through that mount; it doesn't tell us who else can change the backing store. A digest verifies bytes against an expected value, so that expected value needs a trusted source. A customer ID in a filename only helps if the service enforces who can access it. BuildKit's sharing=locked makes builds take turns using a cache; it doesn't separate their permissions.

Keep sharing where it's intended, and test that the service blocks access where it isn't.

Follow one task into the next

For a first review, pick the dependency store or workspace used by your highest-risk workflow. Start there rather than waiting for an inventory of every cache.

The PM should be able to say which tasks are allowed to share information. Platform engineering can then show where the service enforces that rule, with security reviewing access across customer boundaries.

Keep the review to a page:

• Which jobs can create, change or list files, including through proxies or shared service credentials?
• Which later jobs can read those files, and how does the content reach the agent?
• What survives task completion, worker replacement and a service reset? Who owns retention and deletion?
• Where does the service deny access, rather than relying on the agent to choose the right folder?

Then test the path in an authorized environment. Let one run write a harmless unique marker through its normal tools. Start another with a fresh context and the different identity you intend to keep separate. See whether it can discover the marker without being told the marker or its location.

Include a run that's supposed to have access. Otherwise, a failed read could mean the service is broken rather than properly isolated.

Watch the service requests as well as the agent's response. An agent that never tries to read the marker hasn't demonstrated that access would be denied. If it makes no request, use a fixed probe with the same identity and permissions. Keep “attempted and denied” separate from “never attempted.”

That result covers the service and identities you tested, not the whole agent product. If unrelated customer tasks can influence each other's inputs, separate that writable path before expanding the rollout. Run the normal coding task again and measure startup time so the fix doesn't quietly break the workflow or make it too slow.

Before your next release, ask the engineers building the agent product to trace a file from one task to the next. Where is it stored? Which other tasks can read it? Does ending the task actually remove it?