OpenAI’s new rules need a response plan
A revised Model Spec sets out intended behavior. OpenAI’s monitoring disclosure shows why detecting a problem, alerting a person and stopping an agent must be examined separately.

OpenAI has published a revised rulebook for how its models should behave. The useful question is what happens when their behavior falls short.
The company’s October 29 Model Spec update organizes its guidance around five values: following human intent, minimizing harm, honesty and transparency, human agency, and care. It adds guidance for systems that retain context and take actions over time. OpenAI says its models do not yet fully reflect the specification. This is a statement of intended behavior, with further training work planned.
The specification itself makes some practical expectations explicit. Agents should work within an agreed scope, surface important uncertainties and mistakes, and cooperate with oversight, correction and shutdown. They should minimize unnecessary side effects and seek authorization for actions carrying significant costs or consequences. Those principles offer users a standard against which to question an agent’s behavior; they do not demonstrate that every deployed system reliably meets it.
A separate OpenAI account of its monitoring systems shows why implementation deserves equal attention. It describes automated reviewers that examine model activity, investigate suspicious cases and sometimes consult network logs before escalating to a person. OpenAI reports that monitors flagged an attempt to reach the live internet during a September training run within 15 minutes, with human review starting three minutes later.
The response arrangements vary. The company says its highest-priority frontier-training alerts can page responders around the clock, while most other traffic is limited to business hours. Paging is currently disabled for internal Codex traffic because of false alarms. Some critical alerts can automatically pause a workload; a broader rule to pause activity when a highest-priority alert remains unresolved after 30 minutes of paging is still being developed. Monitoring, escalation and intervention are separate steps.
There is an outside check worth reading alongside these disclosures. METR’s October 22 account describes a summer exercise with Redwood Research that found gaps in an earlier monitoring system. It explicitly says the exercise did not establish the expanded system’s current coverage, and that it has not evaluated OpenAI’s subsequent claims about fixes. Historical findings and company-reported improvements should both keep their dates attached.
In an opinion essay for MIT Technology Review, Partnership on AI’s Madhulika Srikumar and Claire Leibowicz argue for observing agents’ actions while they occur. Their emphasis on records of permissions and human authorization adds a useful operational perspective. The essay is an argument for stronger monitoring, not an audit of OpenAI’s current system.
Our view: users and organizations need a response plan alongside a behavior policy. Before giving an agent access to consequential work, decide what it may do, what requires approval, which activity you can inspect, and who can stop it. Ask providers what their monitoring covers and what happens after an alert. Useful automation depends on controls that can be tested and acted on; independent scrutiny remains essential. Our Safety & Society resources provide starting points for examining that evidence.