Deep Dive into OpenAI Dots: Why Always-On Agents Need a Control Plane

From Conversational Tool to Always-On Work Agent

The arrival of OpenAI Dots marks a fundamental shift in ChatGPT's role: from a reactive conversational tool to a work agent capable of running continuously and executing tasks over the long term. This is a profound repositioning. In the past, we asked ChatGPT a question, it gave an answer, and the interaction ended. Now, an "always-on" agent runs persistently in the background, tracking tasks and carrying out multi-step operations.

For developers and enterprise users, the real question isn't whether this feature looks novel — it's a far more serious engineering and security challenge: when an AI agent can run indefinitely and take actions on your behalf, where exactly do approvals, permissions, and sandboxes sit?

The Core Challenges of Always-On Agents

Where Do Permission Boundaries Get Drawn?

A model that only answers questions has a blast radius of nearly zero — the worst case is a wrong answer. But an agent that runs continuously, calls tools, and accesses external systems operates under an entirely different risk model. It can read sensitive data, modify files, make API calls, and even make decisions with real-world consequences on behalf of the user.

This demands a clear permission framework: what the agent can and cannot access must be explicitly defined at the architectural level, rather than relying on the model to "behave itself." The original post cuts straight to the point — the critical question is where approvals, permissions, and sandboxes sit. The answers to that question determine the entire security foundation of the system.

"Blast radius" is a concept from security engineering used to quantify the scope of impact from a failure or attack — originally borrowed from explosive engineering, then adopted into cloud-native and zero-trust security. In IAM (Identity and Access Management) design, the Principle of Least Privilege is fundamentally aimed at minimizing the blast radius of any single entity. A service account restricted to reading a specific S3 bucket, even if compromised, limits the attacker strictly to what that account is authorized to do. For AI agents, calculating blast radius is even more complex, because agents often need to collaborate across systems and tools. Their potential "operation chains" can combine multiple low-privilege actions into high-risk outcomes — for example, reading calendar data, querying contacts, and then automatically sending an email. Each step is harmless in isolation, but the chain could result in a privacy breach. This is why relying solely on after-the-fact access control lists (ACLs) is insufficient for agentic scenarios — you need runtime approval and intent verification inserted into the execution chain.

Approval Checkpoints Cannot Be Skipped

The value of always-on agents lies in automation, but fully unsupervised automation is precisely where risk originates. Sound design should insert approval mechanisms at critical action points: which operations can execute automatically, and which must be confirmed by a human. At its core, this is about finding the balance between efficiency and control — too loose and you lose control; too restrictive and the agent loses its purpose.

Why You Need a "Control Plane"

The title of the original post makes the central argument clear: always-on agents need a control plane. This concept is borrowed from networking and cloud computing architecture — the data plane handles actual execution traffic, while the control plane is responsible for policy, routing, permissions, and management.

Mapped onto AI agents, this means we can't only focus on how capable the model is. We must also build a governance layer that sits independently above the model's execution logic. This layer is responsible for:

• Unified permission policy management: defining the agent's access scope across different contexts;
• Enforcing approval workflows: intercepting high-risk operations and routing them to a human or rules engine for decision;
• Sandbox isolation: constraining the agent's behavior to a controlled environment, preventing irreversible impact on production systems;
• Auditing and observability: logging every action the agent takes, enabling traceability and accountability.

Without such a control plane, an "always-on" agent is like an unsupervised employee with a set of keys — the more capable they are, the greater the potential risk.

"Control plane" as a term originates in network engineering, used to distinguish two fundamentally different types of work inside routers and switches: the data plane handles high-speed packet forwarding according to established rules, while the control plane computes routing policies, maintains topology state, and distributes forwarding tables. The physical or logical separation of the two is a foundational design principle of modern Software-Defined Networking (SDN). In cloud computing, this thinking was extended further: Kubernetes components like the API Server and etcd form the control plane, responsible for cluster state management and scheduling decisions, while the actual container workloads running on nodes belong to the data plane. The core value of the control plane is separation of concerns — execution logic doesn't need to understand where policies come from, and the policy layer doesn't need to care about the details of underlying execution. The two are decoupled through standard interfaces. Bringing this architectural pattern into the AI agent domain means that a model's reasoning and tool-calling capabilities (data plane) should be strictly layered apart from permission management, approval workflows, and audit logging (control plane) — enabling the system to be independently evolved and independently audited without sacrificing the model's capability ceiling.

What This Means for Developers in Practice

For developers evaluating or integrating these kinds of agentic capabilities, the questions raised by OpenAI Dots are worth thinking through upfront. Rather than being drawn in by the novelty of the features, put your engineering focus on governance architecture:

First, establish clear responsibility separation. Decouple the agent's "execution capability" from "authorization decisions" — don't let the model itself become the final arbiter of permissions.

Second, default to least privilege. Any always-on agent should start from the minimum viable permissions and be granted more only as needed, rather than being open by default.

Third, treat sandboxes as first-class citizens. Design an isolated operating environment for the agent from the very beginning, rather than patching it in after the fact.

These principles aren't unique to AI — they're the fundamentals of software security engineering. What Dots does is surface these old problems with a new sense of urgency.

Conclusion

OpenAI Dots represents one direction in the evolution of AI assistants: from passive responder to active, long-running participant in real work. But a leap in capability inevitably brings a rise in governance complexity. The success or failure of always-on agents depends less on how much the model can do, and more on whether we can build a reliable control plane around it — with approvals, permissions, and sandboxes each in their proper place. Those who build a solid governance layer first are the ones who earn the right to talk about AI agent applications at scale.