Governing ChatGPT dots agents: permissions and a first pilot

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

ChatGPT dots agents are personal, always-on agents that OpenAI launched at DevDay on 29 September 2026. Each one has its own cloud computer, keeps working when its owner is offline, and acts through the owner's connected apps (OpenAI launch post). A team should adopt them the way it adopts any new person with system access: narrow permissions, one named owner, and a pilot you can inspect.

This is our proposed approach for engineering teams. It does not replace your security or compliance review.

Who are dots agents for, and what do they need?

A dot belongs to one member. It takes on a responsibility, such as keeping a proposal current or following up on bug reports, and returns with results or decisions. It runs on GPT-6 Astra and can split work across background agents. For code, it creates Codex tasks, either on the owner's connected computer or in a Codex cloud environment the team already set up.

On launch day, dots are rolling out worldwide to Business Premium and Enterprise workspaces. Enterprise has dots off by default until an admin enables them. Pro plans get dots outside the EEA, UK, and Switzerland. Edu and Healthcare workspaces can try the beta when an admin turns it on.

Two cost points matter for budgeting. Conversations with a dot do not count toward ChatGPT usage limits. Tasks the dot starts in Work or Codex count toward those products' limits as usual.

Which permissions does an admin control?

The dots admin guide puts access in Workspace settings > Permissions & roles. Each switch is a separate decision:

Granting a permission does not connect anything. Members still connect Slack, apps, and computers themselves. One detail is easy to miss: Enterprise model controls and defaults do not apply to dots. If your policy relies on model restrictions, review dots access directly.

Where should approval rules sit?

Dots have three layers of control, and they are not equal.

Built-in safeguards and auto-review apply to every dot. Before an action affects an account or shares information, an automatic review decides whether the dot may proceed, needs approval, or must hand the step to its owner.

Custom rules come next. A member can mark an action as "Take action without asking", "Take action when you say so", "Ask before taking action", or "Hand off to you". OpenAI describes these as instructions the dot tries to follow, and says it can make mistakes. They do not grant or remove access to an app.

Plugin controls and workspace permissions are the hard boundary. They decide which apps a dot can reach and which actions it can take there.

So the policy is simple to state. Anything that must never happen belongs in plugin controls or permissions. Custom rules handle preferences inside that boundary, such as asking before posting in a shared channel.

What should a team pilot first?

Pick work where the output is already reviewed and a mistake is reversible. Turning Slack bug reports into draft pull requests fits. The dot reads the report, starts a Codex cloud task, and the pull request goes through your normal review. Nothing merges without a person.

Avoid customer-facing sending, shared file deletion, and anything that needs a password change in the first round. The last one stays with the owner by design.

OpenAI is also previewing specialist dots with their own identity for access management and deeper links to systems of record. Those start as focused enterprise pilots, so plan around personal dots for now.

A rollout checklist for the first four weeks

1. Name one owner for the pilot and one reviewer for every change the dot proposes.
2. Create a custom role that grants Use dots to the pilot group only. Leave local computer access off.
3. Allow the GitHub plugin with the smallest set of actions the job needs. If it exposes a merge action, block it.
4. Set up the Codex cloud environment and the repo's AGENTS.md before the dot starts, so each task gets the same rules.
5. Agree what the dot must hand off, and write it down as custom rules and in the repo instructions.
6. Review Activity weekly with the owner. Check the Scheduled list, because pausing a dot does not cancel scheduled runs.
7. Decide at week four to widen, adjust, or stop, and record the reason.

What should you measure?

Measure the path from bug report to accepted change, not the number of tasks the dot started. Useful measures are review minutes per pull request, changes needed after first review, pull requests closed without merge, and approvals requested versus granted. Our guide to measuring an AI workflow before scaling it sets out the method.

For investigation, the admin guide points to the Compliance API for user messages and dots' replies, and the Analytics API for adoption metrics. Confirm record coverage before relying on either for an audit.

Offboarding and memory

A dot keeps its own notes, including information from connected apps. Disconnecting an app does not delete what the dot already saved. Revoking dots access does not disconnect apps or sign out of websites either. Add three steps to offboarding: review the dot's saved memory, disconnect its apps, and end its website sessions.

If you want a second pair of eyes on the pilot design, book a short call and bring your permission table.

Further reading

• Manage dots permissions and capabilities
• Control your dot
• Introducing dots