Correction — October 3, 2026: The original pre-launch article treated speculative product details as established facts. We removed the 99% background-filter claim, presumed email format, biometric requirement and unsupported architecture claims. This revision uses OpenAI’s Dots announcement and published safety guidance; it does not establish that every earlier “o” rumor described the final product.
OpenAI’s September 29 release notes announce Dots: always-on assistants powered by GPT-6 Astra, with goals, permitted app access and their own cloud computer. This is now the documented product to assess. Pre-launch wording about “o” did not establish the deployed system’s architecture or permissions.
The announcement describes a gradual rollout for eligible adult users on supported plans and markets, with separate workspace availability. An announcement is not proof that a particular account already has access. Check the account’s product controls and current availability guidance before planning a workflow around it.
Access follows the connected services
OpenAI’s privacy and safety FAQ says plugin connections are shared across Dots, ChatGPT, ChatGPT Work and Codex. Dots can use existing connections within the granted permissions. That makes the scope of a connected service more important than the apparent simplicity of a conversational request.
A sensible first goal has a narrow input and an easily checked output. For example, gathering updates from a chosen project and drafting a summary is easier to assess than granting an assistant a broad instruction to manage all correspondence. Decide which sources it should use, what result you expect, and which follow-up actions you have authorised.
Research and action have different controls
The FAQ describes proactive research as reading permitted sources and keeping notes, with restrictions on directly sending messages, modifying plugin content or controlling a browser. Follow-up actions remain subject to the usual action rules. It also describes Auto-review checks and actions that require approval or human takeover.
These distinctions matter because reading a message, drafting a reply and sending it have different consequences. A goal to find a useful update should not be interpreted as permission to contact someone. A recurring action needs a defined recipient, content and condition, so the boundary can be evaluated against an actual request.
Permissions do not erase prompt-injection risk
A connected document or email can contain an instruction written by someone other than the owner. Treating that instruction as authority can redirect an assistant’s work. The original article’s proposed safeguards were presented too confidently as deployed product features. In particular, the sources reviewed here do not establish a universal Face ID or Touch ID requirement.
The published guidance describes several protections and acknowledges remaining mistakes. It does not provide evidence for our former claim that a lightweight filter discards 99% of events, or a sub-10-millisecond sentinel. We have removed those figures from both the text and cover.
Evaluate the result and the permission trail
For a first deployment, keep a record of the goal, connected sources, requested artifact and any approval. Compare the result with the original records and inspect consequential actions before relying on them. Correcting an inaccurate summary is a different task from reversing an external action; the latter may depend on the service involved.
The useful change is that an assistant can work toward a continuing goal with connected context. Whether it saves time depends on useful results, appropriate access and the amount of correction it needs. This article has not independently tested Dots or measured its background compute. The cover is an AI-generated editorial illustration, not a product screenshot.
Cover: AI-generated editorial illustration; not a product screenshot or evidence of a measured result.
