dots security and privacy: permissions, data and control

dots safety design rests on four ideas: isolation, least privilege in the background, review before action, and limits that depend on you. Each dot works on its own cloud computer, cannot write to your apps while operating in the background, and needs approval — or is barred outright — for sensitive actions.

1. Isolation by default

Every dot works on its own cloud computer, while your computer and its contents stay separate. Connecting your own devices is an explicit decision: a dot can use your laptop only if you allow it.

Isolation has a second, less obvious effect: it makes the work auditable. You can open the dot’s computer and see what it did, instead of trusting a summary.

2. Least privilege in the background

Proactive research uses connected apps with tools limited to read-only operations. The restrictions are explicit:

• it cannot send messages;
• it cannot modify your apps’ content;
• it cannot control your browser or your computer.

This is a design boundary, not an optional setting, and it is what makes background mode reasonably safe.

3. Credentials outside the model’s context

To sign in to supported websites, the dot pauses and you enter the credentials in a secure login form. That form sends them directly to the browser environment, without the model seeing them. The dot then continues using the signed-in session.

That is a meaningful difference from approaches where the agent must see the credential to use it.

Two limits of that protection, worth knowing:

• It only covers supported sign-in flows. It does not protect passwords you hand over in a chat or a document.
• Nor does it cover what you share through a plugin.

So the protection is real and solid, but not universal. A password pasted into a message is not covered by this mechanism.

4. Automatic review before acting

Before an action that could affect your accounts or share information, auto-review checks that it complies with your instructions, your custom rules and safety requirements. The result is one of three things:

Outcome	What it means
Can continue	The action proceeds without intervention
Needs approval	The dot asks you before executing
You have to do it	The dot cannot perform it

Certain sensitive tasks, like changing a password, always land in the third bucket.

5. Rules: built-in and yours

dots come with built-in rules defining when to act independently and when to ask for approval. Your custom rules let you do three things: allow, require approval, or block specific actions.

Order matters: built-in safety requirements always apply. Your rules sit on top of them; they do not replace them.

6. Monitoring and a stop switch

OpenAI says its built-in measures help protect dots from malicious instructions and detect potentially harmful behaviour. If its monitoring system detects a security problem, it can pause or stop the dot’s work.

7. Data controls

The points people ask about most:

• In Business, Enterprise and Edu workspaces, content is not used to improve models by default.
• On personal plans, you control whether conversations and dot work are used to improve models.
• OpenAI says it does not train models directly on proactive research or on the notes a dot takes for itself. Depending on your settings, information from those sources may be used if it provides context to a conversation or task that is itself usable for training.

That last distinction is the subtle one, and it is worth reading in full in OpenAI’s safety publication before delegating sensitive work.

8. Memory: the control that does not exist

This is the least intuitive limitation of the product, and the one most worth knowing before you use it.

A dot’s memory is shared with ChatGPT in both directions. The dot receives memories and recent context from ChatGPT, and its conversations can contribute to ChatGPT memory. The exchange continues after initial setup.

And here is the problem: you cannot view, delete or modify individual dot memories, nor the details entering its context from plugins. OpenAI states this explicitly. The only levers are deleting the dot — which removes its entire context — or turning off memory in ChatGPT, which stops the exchange but does not delete what the dot already received.

The practical consequence: connecting an app is a near-irreversible decision. If you disconnect the plugin, new access stops, but information the dot already read stays in its context.

What is bounded: the dot’s context does not retain credentials, images or screenshots.

9. Prompt injection and peripheral access

A website, email or document can carry instructions designed to trick your dot into sharing private information. That is prompt injection. The design starts from a sound rule: content the dot encounters does not grant permission on its own. It combines with tool restrictions, pre-action checks and monitoring. It reduces risk; it does not eliminate it.

Camera, microphone and screen require two things: connecting your computer to the dot and granting the ChatGPT app permission in your device settings. Without both, there is no access.

Purchases with saved cards on merchant sites: the dot can make them with your approval, which can be given in advance when it specifically covers that purchase.

And a note on human review. OpenAI states that human review may occur in limited circumstances — including safety-related ones — even when you have model improvement turned off. If that matters for your use case, it is a decision input.

What stays on your side

The design reduces risk; it does not remove it. OpenAI says it plainly: dots can still make mistakes, so always review work with important consequences. In practice:

• Define rules before connecting apps, not after.
• Require approval for anything that leaves your account.
• Check the activity view regularly.
• Treat any irreversible action as something you confirm yourself.