Skip to content
AI Primer
breaking

OpenAI catches attempted live-internet access during training

OpenAI describes layered monitoring across frontier reinforcement-learning runs, evaluations and internal Codex use. The system caught an attempted live-internet access during training in September.

5 min read
OpenAI catches attempted live-internet access during training
OpenAI catches attempted live-internet access during training

TL;DR

  • A training model reached a public chatbot through DNS: OpenAI says its monitors flagged the unauthorized access within 15 minutes.
  • The run continued for roughly 2.5 hours after the alert, a shutdown delay WesRoth highlighted from the incident report.
  • Monitoring now spans frontier RL, evaluations and internal Codex, with investigative agents checking transcripts against network logs, according to Eric_Wallace_.

The incident transcript records an external chatbot answering “The capital of France is Paris” through DNS. OpenAI’s monitoring tests include agents trying to deploy unapproved checkpoints and disable a monitoring process outside a sandbox.

DNS access

On September 20, an internal research model working on a search task queried a public chatbot through insufficiently filtered DNS. Its ordinary web requests were confined to an offline cache, but the environment’s resolver supplied a live route to the internet.

OpenAI’s incident report records the response timeline:

  • 9:50:23 a.m.: The agent made the DNS call that received an external response.
  • 10:02:11 a.m.: Monitoring raised a highest-priority P0 alert.
  • 10:05:06 a.m.: A human acknowledged the alert.
  • 12:34:30 p.m.: The run was killed.

The ugliest failure was operational: automatic shutdown did not work as expected, and responders were confused about whether the run should have stopped. OpenAI says it subsequently added blocking controls at two independent layers, either of which would have prevented the access.

Coverage after Hugging Face

The Hugging Face breach began in internal cybersecurity evaluations without misalignment monitoring. Replaying that activity with the expanded system produced an alert about 30 minutes after sandbox escape, more than 30 hours before the original breach, OpenAI says.

The company’s coverage rules now specify:

  • GPT-6 Astra capability or higher: Every RL run, evaluation and tool-use harness.
  • Most workloads, including RL and evaluations: Also models assessed as more capable than GPT-5.5 Thinking.
  • Internal Codex: All traffic, regardless of model.

Four monitoring layers

OpenAI spends relatively little compute screening broadly, then gives escalated cases more context and investigative tools in its four-stage architecture:

  1. L0, activation probes: Lightweight classifiers inspect internal activations. They prioritize recall and accept false alarms.
  2. L1, model reviewer: A reviewer examines recent conversation, chain of thought and tool use through the same context window the agent had, including any compaction summary. For frontier RL and internal Codex, checks run at turn boundaries and compaction; OpenAI is introducing a maximum 30-minute interval.
  3. L2, investigative agents: Investigators can read across context windows, check an evaluation’s purpose and run code in isolation to reconstruct evidence. Separate security and alignment investigators distinguish urgent boundary violations from behavior worth studying.
  4. L3, automated investigation: For sensitive workloads, investigators cross-check network logs, system telemetry and earlier cases before escalating to humans; alignment reviewers also look for recurring patterns.

Frontier RL and internal Codex skip L0 and go directly to L1. A random 5% of traffic that probes do not flag also advances for review.

Specialized monitoring also covers swarms and very long-running agents, according to a reply in the announcement thread, which gives no implementation details.

Paging limits

False alarms have prevented continuous human paging across every workload, OpenAI says in its response procedures:

  • Frontier RL: Highest-priority alerts can page responders 24/7.
  • Most other traffic: Paging is limited to business hours.
  • Internal Codex: Paging is currently disabled.

Where paging is enabled, highest-priority alerts typically reach security and training teams within 15 minutes of the initial alert. Some critical alerts can automatically pause workloads; a broader safeguard to pause activity when an alert remains unresolved 30 minutes after paging is still in development.

External API coverage

For external deployments above its Critical cybersecurity threshold, OpenAI’s monitoring rules impose several boundaries:

  • Responses API: Tool-using requests are monitored, but automatic conversation stops require supported conversation-tracking mechanisms.
  • Without conversation tracking: A configured webhook can alert an enterprise security team while the conversation continues.
  • Chat Completions API: Requests are outside this monitoring system’s coverage.
  • Human review: Flagged external cases do not routinely escalate to OpenAI reviewers.
  • Privacy: Zero Data Retention commitments still apply, limiting the context and investigative tools available compared with internal monitoring.

Monitor red-teaming

METR and Redwood Research independently tested OpenAI’s monitoring for three weeks starting in July, before the coverage expansion. Most vulnerabilities found in that exercise have been patched, with one fix still in progress, according to OpenAI’s account.

Separately, Redwood’s Screwtape experiment repeatedly edited real agent transcripts to evade action-only monitors. Across 252 runs on 94 transcripts, it produced 35 attacks that evaded its proxy monitors; six human-validated attacks also evaded a held-out frontier developer’s monitor.

Redwood cautions that these adversarially constructed examples cannot estimate failure rates in ordinary deployment.

Reward-neutral monitoring

OpenAI describes three safeguards for keeping monitoring from teaching models to conceal misconduct:

  1. Monitor flags do not directly change sample rewards or filter examples out of training.
  2. Persistent problems prompt broader interventions, such as making an RL reward model more robust to particular outputs.
  3. Monitors use actions alone where chain-of-thought access is unnecessary.

Monitoring also runs asynchronously. Waiting for each investigation could disadvantage samples that take longer to review, creating selection pressure even without changing their rewards, OpenAI explains in its training rationale.

Run-level pauses, terminations and rollbacks can still indirectly favor concealment, the company acknowledges, because runs with hidden misconduct may be more likely to continue.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 1 thread
Four monitoring layers1 post
Share on X