OpenAI chief scientist Jakub Pachocki has called for voluntary slowdowns in AI development until shared safety standards are established. His warning, published on 6 September after GPT-6 Astra’s 3 September announcement, raises a question beyond the launch benchmarks: can oversight keep pace with what increasingly capable agents can do?
In his essay An Alien Mind, Pachocki says he is concerned that “no one is prepared for the consequences of a continued rapid rise in machine intelligence”. He argues for enforceable safety requirements, potentially overseen by independent auditors, governments or international bodies.
For developers and businesses considering Astra, the useful response is to examine the controls around it. OpenAI’s documentation exposes several practical limits, including differences between API interfaces, that deserve more attention than another debate over whether the model qualifies as artificial general intelligence.
A slowdown proposal does not announce an Astra shutdown
Pachocki advocates slowing future scaling where necessary while continuing safety research. He also wants people to retain influence as AI increasingly contributes to developing more capable AI systems. The essay does not announce the withdrawal of Astra or a blanket halt to research.
Our reading is that users should separate two decisions: whether to test an available model, and whether to expand the authority given to it. A warning about future development does not automatically settle either question. Each proposed deployment still needs an answer about what the agent can access, change and send.
That is the operational consequence of moving from generative AI to agentic AI. Reviewing a suggested action before carrying it out gives the user a decision point. An agent that executes the action needs that decision point built into its permissions or approval process.
Better behaviour and harder monitoring can coexist
OpenAI reports that Astra is better at respecting security restrictions than GPT-5.6 Sol, while also being harder to assess through its written reasoning. These findings measure different things. A model can behave appropriately more often while providing less useful evidence for detecting the occasions when it does not.
The Astra system card reports reduced chain-of-thought monitorability in both ordinary evaluation conditions and adversarial tests. OpenAI says its broader concerns are largely based on adversarial evaluations, including tests that encourage the model to evade monitoring. Those results should not be presented as a measured rate of deception in normal customer sessions.
OpenAI has also assigned Astra the Critical cybersecurity capability level under its own Preparedness Framework. Its assessment concerns what the model can accomplish with suitable tools and access. It is not a statement that every deployed session has those permissions, nor evidence that every customer faces an active compromise.
The practical implication is to keep separate records of permission decisions and actual changes. A reassuring explanation from the agent cannot, by itself, establish that a file was left untouched or that a message was never sent. Check the system that would contain the evidence.
The API route changes which monitoring controls apply
A particularly useful detail appears in the system card: OpenAI does not apply the specific Astra misalignment monitoring system described there to the Chat Completions API. That does not mean all other safeguards are absent.
Responses API requests using neither persistent chain of thought nor WebSockets are still monitored and can generate webhook alerts. However, OpenAI says these stateless requests cannot be connected into a complete trajectory or automatically paused by that system. It also warns that harmful actions can occur before its monitoring intervenes.
For an application developer, blocking a tool call, receiving an alert and stopping an ongoing workflow are different capabilities. A purchase already submitted or an external email already delivered cannot be made harmless merely by ending the model’s next response.
Our recommendation is to document the entire stop mechanism before enabling consequential actions: which component detects the problem, which component can refuse execution, and what happens to work already completed. Treat an alert as a signal to investigate, not proof that nothing happened.
Automated approval still needs a narrowly defined boundary
OpenAI’s Auto-review research describes a separate agent that approves or denies proposed actions crossing the Codex sandbox boundary. It also explicitly warns that Auto-review is not a security guarantee and does not inspect every action performed inside that boundary.
That creates a deployment choice which the model’s intelligence cannot make for you: how much should be permitted before any additional review is needed? For an initial trial, we would divide permissions by the consequence of the action, rather than give one account unrestricted access to an entire workflow.
| Trial task | Suggested starting boundary | Separate approval point |
|---|---|---|
| Prepare a software fix | Edit a disposable branch and run isolated tests | Merge changes or deploy to production |
| Handle customer correspondence | Read selected messages and prepare drafts | Send a message to an external recipient |
| Analyse customer records | Use a minimised test export | Modify live records or export additional data |
For repository integrations, our Codex CLI MCP setup and permissions guide covers the configuration side. The acceptance test should include a task the agent cannot finish within its permissions. Stopping, explaining the limit or requesting approval should count as correct behaviour, not a failure to be worked around.
The trust test is what outsiders can verify
A recurring reaction in public discussions of Pachocki’s warning is distrust of companies presenting their own products as both exceptionally capable and potentially dangerous. Other readers argue that dismissing every warning as promotion risks overlooking genuine problems. Neither reaction establishes whether a particular deployment is safe.
A more useful test is to ask what could disprove the vendor’s safety claim. Which failed evaluation would delay deployment? Who can inspect the evidence? Does an external reviewer have enough access to challenge the company’s interpretation? Can customers see which controls apply to their integration?
DIY AI’s view is that those questions turn a broad warning into an accountable decision. An impressive demonstration and a cautionary essay are both easier to publish than a clear commitment to withhold a capability when a specified safety check fails.
Budget for supervision, not just model access
OpenAI’s launch documentation describes phased access through paid ChatGPT plans and the API, with Microsoft Azure and Amazon Bedrock also listed. It gives standard OpenAI API pricing of $10 per million input tokens and $50 per million output tokens. These are launch terms, not a guarantee of availability in every account or region.
For a bounded trial, include the cost of reviewing actions, investigating alerts and recovering interrupted work. Compare workflows only when they have equivalent permissions and approval requirements. Removing oversight from one trial may make it look faster while changing the risk being measured.
Our recommendation: test Astra on useful, reversible work, but require evidence before expanding its authority. Verify the monitoring available in the actual interface, retain control of consequential actions and test how the workflow stops. A more capable agent should earn broader permissions through observed behaviour, rather than inherit them from its launch claims.
