OpenAI Dots Safety: Auto-Review, Read-Only Research, Kill Switches

An agent that works 24/7 on its own computer, connected to 4,000-plus apps, is a security question before it is a productivity story — and OpenAI shipped its answer alongside dots at DevDay 2026. The architecture stacks several controls: an auto-review system that checks consequential actions before they happen, background 'proactive research' restricted to read-only tools, monitoring that can pause or stop a dot outright, password use that never exposes credentials to the model, and a hard rule that certain sensitive tasks — changing a password among them — always remain human.

This piece walks through each layer of the design, what threat model it implies, where the stated boundaries are, and what anyone delegating real work to a dot should verify. It is written for security-minded engineers evaluating always-on agents — including builders designing equivalent safeguards for their own systems.

The action gate: auto-review, Custom Rules, human-only tasks

Every action that could affect your accounts or share information passes through auto-review, which checks it against three sources of policy: your instructions, your Custom Rules, and OpenAI's built-in safety requirements. The outcome is triage — work that proceeds, work that waits for approval, and work the dot must hand to you. Custom Rules give users the dial: allow a category of action outright, require approval, or block it, with built-in safety requirements applying regardless.

The non-negotiable floor is the notable design commitment: certain sensitive tasks always stay with the human, no matter how rules are configured. Password changes are OpenAI's named example — the class of action where delegation itself is the vulnerability.

Read-only by default: the proactive research boundary

Dots look for ways to help even when you are not working with them — the feature that makes 'always-on' literal. OpenAI's containment is categorical: proactive research runs only on apps you have already connected, through tools restricted to read-only access, meaning a dot in background mode cannot send messages, change app content, or control a browser or computer. Acting on anything it finds requires crossing back into active work, where auto-review governs.

Isolation supports the same boundary. Each dot works on its own cloud computer; your machine and its contents stay separate unless you explicitly connect them. And for authenticated websites, dots use saved passwords through a mechanism that keeps the credential itself invisible to the model — the agent can log in without ever holding the secret.

Oversight: Activity View, monitoring, and the stop button

Transparency is continuous rather than report-based: Activity View shows what a dot is doing, including background work, and the dot's own computer can be opened and inspected at any time. On top sits OpenAI's monitoring: security safeguards watch for malicious instructions — the prompt-injection class of attack that connected agents invite — and for potentially harmful behavior, and the monitoring system can pause or stop a dot's work when it detects a safety concern.

That last mechanism deserves its plain name: a kill switch OpenAI operates, distinct from user controls. Its presence acknowledges the honest premise of the whole architecture, which OpenAI states directly — dots can still make mistakes, and consequential work needs review.

The data boundary

Training exposure has its own rules. Content from Business, Enterprise, and Edu workspaces is not used to improve models by default; personal-plan users get a control governing whether dot conversations and work are used. OpenAI further commits that it does not train directly on proactive research or on a dot's notes to itself — with the caveat, stated in the launch material, that information from them may inform an eligible conversation or task depending on settings.

For enterprises, these defaults compose with the same day's Private Intelligence announcements; for individuals, the setting is worth checking deliberately rather than assuming.

What to verify before trusting it

The architecture is coherent; the diligence questions are about edges. Which action categories does auto-review classify as consequential — and which proceed without it? How is the read-only guarantee enforced against tools whose 'read' operations have side effects? How quickly does monitoring intervene, and what does a paused dot do with in-flight work? OpenAI points to a dots safety blog, Help Center documentation, and the GPT-6 Astra system card change log for the deeper detail — read them before wiring a dot into anything with blast radius.

The practical posture for early adoption mirrors the design itself: start read-only, keep approval requirements on for consequential categories, watch Activity View until behavior earns trust, and treat the first month — while extended launch limits invite heavy experimentation — as a monitored trial rather than a handoff.