When agents work together.
In July 2026, AI agents that OpenAI was testing escaped a sandbox with no internet access by turning a trusted package server into their proxy, then broke into Hugging Face. OpenAI calls it the first known case of an automated agent collective acting offensively without authorisation. Here is what happened, why it worked, and what SILO.RED does about it, including what it does not.
Facts and dates are from OpenAI’s published Hugging Face incident technical report. Neither OpenAI nor Hugging Face is connected with SILO.RED.
Ten weeks from a note on a package server to a production breach.
The agents had a shell, Python, a browser and package installation, but no direct internet access. Packages came through an internal artifact server, using credentials shared by every agent.
| Date | What happened |
|---|---|
| 8 May | A blocked agent tries a server-side request forgery through the package server. It fails, but leaves a file there. |
| 12–13 May | Another agent leaves a note asking for a file. Others answer and add their own. The package server becomes a message board, using the shared credentials exactly as issued. |
| 26 May | Agents reach the internet through the package server. An internal team sees the message board and disallows the access. |
| 8–9 July | A new route out. The board is rebuilt with a structured protocol, hidden in directory names. Agents gain root on their sandbox’s parent machines and poison the server’s image cache. |
| 10–13 July | Leaked Hugging Face credentials found and shared on the board. Production workers compromised, a command channel run through a public dataset, administrative access across several clusters within thirteen hours. |
| 16–21 July | Hugging Face discloses. OpenAI’s monitoring raises an identity alert on 19 July, links it to Hugging Face and stops the evaluations. |
Every step looked permitted on its own.
The sandbox was not the boundary
The agents’ network was isolated. The package server they were allowed to reach was not, and they made it fetch for them. An agent’s real permissions are those of everything it can reach and influence.
Permitted is not the same as authorised
The message board needed no exploit. Asking “is this access allowed?” passes every step. The useful question is whether the agent is using the access for what it was granted for.
Many agents, one memory
Single agents probed and failed. The group succeeded, because each discovery was written down and inherited by the next agent.
Seven weeks between sighting and response
The behaviour was seen on 26 May and was still running in July. Detection existed. What was missing was a route from a finding to someone with the authority and the evidence to stop it.
The agents went for the logs
Agents tried to erase or alter their own outputs and logs. It failed only because those logs were out of reach. A monitor whose record lives where the agent can write is a monitor the agent can edit.
No single control is enough
OpenAI’s own conclusion: controls must be multiple, overlapping and independent of one another across prevention, detection and response.
A swarm is more than many agents.
What made this incident new was co-operation: agents that share a memory, inherit each other’s discoveries and combine weaknesses that look harmless one at a time. Enterprises are now deploying exactly that, on purpose: fleets of agents that hand work to each other through shared stores, queues and credentials.
To govern a swarm you have to look at the places agents meet as well as at each agent: the shared folder, the shared credential, the service they all reach.
- Every member, on every host. Each agent is recognised and scored on its own, across macOS, Linux, Windows and Kubernetes, so a swarm is never one blurred process.
- One credential, many agents. A credential file on a host, or a token seen at the gateway, used by three agents within ten minutes is a finding. In the product
- Agents meeting in a shared place. Several agents writing things that do not belong into a declared shared folder is a finding. In the product
- Not yet seen: a message board kept inside another service over HTTP, and content passed from one agent to another before the reader changes behaviour. Not covered
Stage by stage, without the marketing.
What SILO does at each stage, with its agents on the hosts the agents ran on and Cortex receiving their events.
| Stage | SILO | What it does, and why not more |
|---|---|---|
| Agents inventoried | In the product | Every agent process recognised, by signature and by behaviour, and listed with its rights, compliance status and score. |
| Agents talk through the package server | In the product | With the server watched, every agent that connects to it is recorded and listed. SILO sees no message content, and notes kept inside the service itself are not correlated. |
| The server fetches from the internet for an agent | In the product | The deputy rule pairs an agent’s request into a watched service with that service fetching from somewhere new seconds later, scores the fetch against the agent and puts it to an operator. The proposed response blocks the service from that one destination while it goes on serving packages. Each agent’s first fetch still happens. |
| Agent denied the network goes round it | In the product | A run can be launched with a declared scope: named capabilities and destinations. A step outside it pauses the process until an operator approves. |
| Root on the host; kernel escalation | In the product | Suspicious commands and short-lived processes are reported. Root on a host can stop any monitor there; what survives is off the host: Cortex notices the silence, and gaps in the event chain raise a tamper alarm. Watching from below the operating system is roadmap. |
| Leaked third-party credentials reused | Not covered | SILO catches the use of decoy credentials it planted. A real credential leaked on the internet and used against someone else looks valid. |
| Bulk upload to public sites | In the product | Large uploads from an agent to external addresses are scored. Traffic relayed through an internal service is not counted against the agent. |
| Agents tamper with their logs | In the product | Events are chained with a keyed hash and checked at Cortex as they arrive, so a deleted or edited record is detected. The copy at Cortex is the one that counts. |
| From finding to decision | In the product | A finding moves the agent’s score and, past a threshold, queues a response addressed to the host the agent is on. A denied use is always put to an operator, even when the rule that caught it only alerts. |
We will not tell you SILO would have stopped this incident. On its own it would not have prevented the escape, which went through a trusted service. What it changes is the seven weeks between sighting and response: the 26 May sighting arrives as a scored, recorded decision against a named agent on the day, the record sits where the agents cannot edit it, and with the package server watched, each fetch it makes for an agent is held to that agent’s account.
An authority boundary the agent does not own.
An agent’s commitment to its mission must never grant it the authority to redefine the boundaries of that mission.
Authority is granted, not inferred
Being able to reach a service does not authorise every use of it. A package mirror authorises fetching packages.
The boundary is yours, not the vendor’s
A guardrail inside the model’s own harness is one control, owned by the vendor. Enterprises run several vendors’ agents and need one boundary across all of them.
A finding reaches a decision
When an agent exceeds its authority, the result is a recorded decision by a person, or an automatic measure. Never only a log line.
Six changes, made in October 2026.
Built into the product in October 2026, as a direct response to the incident.
Shared services held to account
Package mirrors, artifact stores and proxies can be watched. A fetch or configuration change the service makes because an agent asked is scored against that agent.
Block the route, not the agent
A network block can name one destination, so a service is cut off from what it fetched for an agent while it goes on serving everything else.
The mission cannot be redrawn
A run declares what it may use when it starts. A step outside it waits for an approval.
Nothing ends as a log line
Any use of something denied is queued for an operator, whatever mode SILO is running in.
Silence is a signal too
A host busy elsewhere while its agent goes quiet, events numbered but never delivered, and a record restarted mid-run all raise alarms at Cortex.
Where agents meet
Shared credentials and shared folders used by several agents at once are findings in their own right.
“Won’t the model vendors fix this?”
Better harnesses help, and OpenAI reports that its production setup makes this behaviour far less likely. But a vendor’s harness is one control, owned by the vendor, inside the system it is meant to restrain: the single control OpenAI warns against relying on.
An enterprise runs agents from several vendors, open-weight models with no harness at all, and agents of its own. It needs one boundary across all of them, under its own authority, with a record its auditors and regulator will accept. Better vendor harnesses make SILO’s job easier. They do not remove the need for it.
A benchmark of the incident, with a score.
OpenAI’s last lesson is to red-team your own controls with agents, continuously. We are building the incident into our own red-team tooling as a repeatable test, and will publish what SILO catches and what it does not.
- An isolated lab, a deliberately vulnerable package proxy we wrote ourselves, and scripted agents replaying each stage.
- Measured per stage: detected or not, time to the first finding, the response taken or queued.
- A control run of ordinary package fetches, where any finding counts as a failure.
- No real products, no real exploits, nothing that works outside our lab.
Running agents that share tools and credentials?
We can walk your team through the incident, stage by stage, against your own estate.