OpenAI dots: always-on AI agents and permission limits

What are OpenAI dots, and when do they need permission?

OpenAI describes dots as always-on AI agents that can work across a cloud computer and connected apps. The practical distinction is between gathering information and taking action: an agent researching a task has different responsibilities from one sending a message or changing a record. This report examines the launch and permission boundaries; it does not establish an independently measured real-world reliability rate.

OpenAI introduced dots on 29 September 2026 as persistent agents powered by GPT-6 Astra, with their own cloud computer and access to connected applications. The company describes ongoing tasks, communication through ChatGPT, Slack and Teams, and a gradual rollout to eligible paid plans. Specialist enterprise agents are being piloted rather than offered as a demonstrated replacement for whole departments.

The geographic restriction matters to readers of this UK-based portal. The dated release notes say the Pro rollout initially excludes the UK, European Economic Area and Switzerland. Enterprise access is a beta controlled by workspace administrators. Product examples in a launch post do not establish that every user can obtain every feature, or that a workflow will finish reliably in their own applications.[1][3]

What permission means in an ongoing task

OpenAI says proactive research uses connected-app tools restricted to reading: it cannot send messages, change app content or operate a browser or computer in that mode. Actions with consequences are subject to rules and review. Users can define permissions, while some sensitive actions remain for them to complete. The provider also describes isolated workspaces, monitoring and protections around sign-ins. These are design claims, not published rates of successful prevention across all real-world situations.

Our analysis is that the distinction between investigating and acting will determine much of the product's value. An assistant researching an overdue invoice is handling a different responsibility from one sending that invoice, altering its amount or contacting a customer. A useful handover should make the proposed action and its destination visible. Otherwise, a user may agree to a broad goal without noticing the concrete commitment being made on their behalf.[1][2]

A practical test for a small organisation

A small team could begin with a reversible task: assemble a weekly account of public competitor announcements, retaining links and dates. Success would mean a correct, complete report delivered within an agreed interval, with uncertainty stated when access fails. The team should also record interruptions and the time spent checking the work. A polished summary is not enough if it leaves out the most consequential development or silently relies on old information.

Moving from research to operations requires a different test. Before an agent can update a customer record, the organisation should specify which fields it may change, how conflicting information is handled and who can undo a mistake. A useful trial includes incomplete requests and contradictory source material, because routine demonstrations tend to make the desired path obvious. These are proposed assessment steps, not findings that OpenAI's product has passed an external trial.

People, accountability and evidence still missing

The potential benefit for workers is less coordination and fewer repetitive follow-ups. The possible cost is an additional stream of approvals that demands attention without making the underlying decisions clearer. Managers should ask whether the tool reduces total effort after checking and correction, rather than counting how many actions it attempts. A system that frequently needs rescue can shift work around without reducing it, especially when only a few staff understand how its permissions operate.

The announcement does not provide a representative denominator of ordinary organisations using the product, nor an independent estimate of errors per completed workflow. Our assessment would improve with external studies reporting successful tasks, failed tasks, unauthorised actions and recovery time on the same basis. Results should distinguish countries and application environments where access differs. Until those data exist, the launch is a material change in the available product category, while its lasting effect on workplace productivity remains to be measured.