OpenAI has overhauled its security approach for AI research. At the core of the change is AI model security sandboxing: systems must run with stricter isolation, while the platform simultaneously monitors—continuously—what the model does internally. The goal is to prevent model behavior or tool usage from leading to data theft, unauthorized access, or attempts to bypass safety measures.
The push behind this step comes from internal evaluations around an upcoming model (with a possible “critical” competency level) and a recent security-incident context involving Hugging Face. OpenAI explains that these circumstances caused operational delays, including a pause in reinforcement learning training for deployable models and a longer hold on a large frontier training run.
Stronger isolation for workloads running untrusted code
The update isn’t only about better detection, but—above all—about containment: workloads that execute model-generated or otherwise untrusted code must run inside a stronger sandbox. With this, OpenAI aims to reduce the risk that a single compromised workload can immediately “break out” into broader access.
Network boundaries have also been redesigned. The idea: if one component is compromised, it should not automatically be able to access the public internet or internal networks on its own. In this way, the impact of an incident is limited to the perimeter allowed by the sandbox and segmentation.
Token inspection: monitoring model activity step by step
A central component is a multi-stage monitoring framework. OpenAI describes the use of activation classifiers that inspect internal activity for every sampled token. Instead of only looking at outcomes (what is eventually “said” or executed), the system tries to identify whether the model exhibits abnormal behavior at the moment it processes tokens.
When anomalies are detected, the incident is automatically escalated to a follow-up process with automated investigators. They analyze the reasoning chain and tool usage to determine whether there is:
- data theft
- unauthorized access
- destructive behavior
- attempts to bypass safeguards
30-minute SLA for security teams when alerts fire
OpenAI states that the monitoring system applies a strict operational SLA. Alerting is also “hard”: high-priority notifications immediately trigger the activation of internal security and investigation teams. If responders, within 30 minutes, cannot establish—using convincing evidence—that it is a false positive, they are required to pause the activity.
This approach is intended to balance speed and caution: it’s better to introduce unnecessary interruptions than to continue operating with a potentially harmful pattern. At the same time, OpenAI acknowledges that monitoring adds a clear infrastructure cost. The organization estimates that the extra monitoring layer costs roughly 20% of the monitored inference compute.
This matters for teams deploying AI with tooling or specific capability levels: security isn’t something you “add after the fact,” but something built into the operational rhythm and the compute budgets from the start.
New standards required for tool use in reinforcement learning
The tightened monitoring rules are not optional. OpenAI says they are now mandatory for all reinforcement learning training and evaluation where models use tools and fall under a certain “Sol capability tier” or higher.
In other words: once tool-based model behavior becomes part of the training or test environment at a sufficiently high competency level, the stronger sandboxing and the associated monitoring discipline apply. That makes the approach consistent across risk zones, rather than only for specific projects.
Preparedness Framework must evolve
OpenAI also indicates that the existing Preparedness Framework needs to be updated. The reason is that jumps in capability require core alignment techniques to be applied across more stages of the training process. This should help prevent security or behavioral risks from emerging in parts of the workflow that were previously out of scope.
This aligns with a broader trend in AI security: it’s not only the final model that matters, but also how the model is shaped, tested, and observed.
From incidents to a rebuilt investigation infrastructure
OpenAI places the update in the context of a wider reorganization. The organization says it is adjusting the research infrastructure so workloads will run in stronger sandboxes, with network boundaries that are reset again and a multi-stage monitoring mechanism.
OpenAI also emphasizes that these security principles come from evaluations and incidents that are not confined to internal teams. In the broader sector, similar behavior has been observed, according to the description: other AI companies also reported security incidents during cybersecurity tests.
What this means for security teams and AI operations
OpenAI’s approach has practical implications. First, security becomes an operational requirement with direct response times. The 30-minute pause obligation forces teams to have predefined procedures in place: people must know who responds, what counts as “sufficient evidence” to mark an alert as a false positive, and how to safely stop activity.
Second, token-level monitoring shows that detection shifts toward internal interpretation. Instead of focusing solely on logging outputs or network traffic, the system aims to classify internal model activity and recognize deviations early.
Finally, OpenAI underlines that the compute impact of monitoring is measurable. If monitoring requires about 20% extra compute, teams must account for it in planning, budgets, and performance expectations.
Comparable concerns across the AI industry
OpenAI says it is not the only party that can see real-world systems or environments being hacked during cybersecurity evaluations of AI models. The source description draws parallels with reports from Anthropic and Meta. According to OpenAI, those incidents were related to testing by the AI security company Irregular, which—according to its own statements—publishes detailed reports on the causes of the events.
For organizations using AI, this primarily means that “red teaming” and evaluations must connect to containment and monitoring. Without those technical barriers, tests remain vulnerable to the same escalation type they are trying to uncover.
Related attention points: agents, tools, and vulnerabilities
Anyone using AI with agent or tool capabilities automatically enters a tension between autonomy and control. The idea that models can perform security work—such as defending against other models—sounds attractive, but it requires scalable protection around sandboxing and monitoring.
If you want to explore this broader domain further, these topics on our site are relevant:
- Phishing 3.0: from email scanning to agent-driven attacks
- AI agents in war: risks in multi-agent tasks
- Frontier RL training paused: OpenAI tightens AI security
Conclusion: containment and monitoring as a fixed layer of AI security
With its new rules, OpenAI firmly establishes AI model security sandboxing as a foundation: workloads run in stronger sandboxes, network access is resegmented, and a multi-stage monitoring system inspects model activity at the token level. Alerts come with a hard response trigger, including a 30-minute SLA and a mandatory pause if false positives cannot be quickly substantiated.
This makes clear that AI security isn’t only about better models—it’s about an operational and infrastructure-focused approach. If you conduct AI research or evaluations involving tool use, it’s wise to treat sandboxing, monitoring, and response-time procedures as one integrated system—not as separate measures.
