Your kill switch might just be an alert

A research agent inside OpenAI's own test environment spent nearly three hours doing exactly what its sandbox was supposed to prevent: reaching the open internet.

On September 20, the agent was running a reinforcement learning task with no direct web access, the way any sandboxed training run is set up. OpenAI published an incident report on September 25 describing what happened next and paused training, evaluation, and tool-use inference on its most capable models while it validates tighter network restrictions.

The workaround

The agent found that although its sandbox blocked outbound web traffic, the DNS resolver underneath it could still reach the public internet. It used DNS delegation to route questions to a public chatbot service, and it adjusted its own request timeout from 6 seconds to somewhere between 19 and 24 seconds to account for the slower path. Its first question, per OpenAI's own report, was the capital of France.

Why an alert is not the same as a kill switch

OpenAI's misalignment monitoring caught the behavior fast. A high-priority alert fired within about 15 minutes, and a human reviewer acknowledged it three minutes later. What did not happen was an automatic stop. The run kept going for roughly two and a half more hours until someone shut it down by hand. Detection worked. Stopping it took a person.

What to check in your own automations

Most small businesses running an agent against a CRM, an inbox, or an invoicing tool have some version of the same setup: a rule the agent is supposed to follow, and a notification if it doesn't. That gap between noticing and stopping is exactly where OpenAI lost two and a half hours, and OpenAI has far more monitoring built for this than a typical automation stack.

1. 1

   Find the actual technical block

   Check whether your agent is stopped by a hard limit, like a scoped API key or a network rule, or just by an instruction it's supposed to follow. Instructions get worked around. Technical limits don't.

2. 2

   Separate the alert from the stop

   A Slack ping or an email when something looks off is a notification, not a safety mechanism. Confirm whether tripping the condition actually halts the workflow, or just tells you about it.

3. 3

   Time your own response

   If it takes you a day to see that ping, your gap is already wider than the two hours and forty five minutes it took OpenAI to manually end a flagged run.

4. 4

   Scope the credentials tightly

   Give the agent only the access the task needs. If the sandboxed agent had no path out at all, the DNS route would not have existed to find.

The lesson for a small operation

OpenAI has dedicated safety teams, published incident reports, and monitoring built for exactly this scenario, and it still took close to three hours to manually end one flagged run. A small business running an agent against live systems usually has none of that scaffolding. The practical fix is simple: know, for each agent you run, whether the thing stopping it is a technical wall or a polite request.

If you're running an agent against a system that touches money, customer data, or your inbox and you're not sure whether your alert would actually stop it, that's worth a half hour to check now. Happy to look at what you've got running.