OpenAI announced dots on September 29, 2026: always-on agents with a cloud computer, connected apps, and work that continues between conversations. That puts dots in the same buying conversation as Meta's Muse and Grok Bot. The useful comparison is what each agent can access, what it can do without asking, and what remains after you disconnect it.
This is a comparison of published controls at launch, not a hands-on security test. OpenAI's dots announcement, Meta's Muse announcement, and SpaceXAI's Grok Bot announcement describe three agents that can work on a separate computer. Their permission boundaries differ.
Short answer: Muse puts Sentinel between its agent and connector or network actions. Dots separates supported sign-ins from the model and confines proactive research to read-only tools. Grok Bot lets multiple Bots collaborate, but they share one computer and connector access per user. The details below show what each boundary covers.
Checked September 29, 2026. Grok Bot here means the separate always-on product, not the Grok chat assistant. For the earlier Muse, Grok Bot, and Instinct comparison, see our original agent access review.
Dots vs Muse vs Grok Bot at a glance
| Control | OpenAI dots | Meta Muse | Grok Bot |
|---|---|---|---|
| Who can start | Gradual rollout to eligible Pro and Business Premium users; Enterprise beta needs admin enablement. | Consumer rollout in the US, with free and paid plans. | Beta for eligible SuperGrok and Cursor subscribers; Enterprise rollout is admin controlled. |
| Work environment | A cloud computer for the primary dot. Local computer access is optional and off by default. | A dedicated Muse Secure VM with a separate Sentinel permission service. | One cloud computer per user, shared by all that user's Bots. |
| App and action controls | Shared ChatGPT app permissions, Custom Rules, and Auto-review. Proactive research uses read-only tools. | Per-connector permissions, action approvals, and Sentinel checks; some actions can be narrowed beyond OAuth scope. | Member and team connector grants plus Auto Review. Enterprise can enforce team rules; connectors are available across a user's Bots. |
| After disconnection | New app sharing stops; already learned information remains in dot context until the dot is reset. | Disconnecting an app does not itself erase information already used in memories or history. | Remove connectors and sign out of the shared computer separately; deleting a Bot can leave files and sessions. |
| Visible record | Activity View shows ongoing and delegated work. The launch material does not describe a request-level export. | User-facing activity and audit trail; a request-level admin export is not described in the cited launch material. | Enterprise audit events and optional Action Recording; the latter is off by default. |
Sources: OpenAI and its Help Center; Meta's safety write-up; Grok Bot security FAQ and access guidance.
Credentials and computers
For supported sign-ins, dots pause the model while you log in. A separate encrypted credential service supplies saved passwords without putting them in model context. OpenAI is explicit about the limit: a secret pasted into a readable message or document can still be seen by the model. The primary dot has its own cloud computer, and access to your laptop requires a separate opt-in. See OpenAI's safety design and setup guidance.
Muse also separates credentials from the agent. Its credential service stores tokens outside the agent runtime, while Sentinel decides whether connector actions and network requests may proceed. Meta says Muse can narrow some connector actions below the provider's OAuth scope. That is a meaningful architectural control, although the published material is not a per-connector, per-record permission matrix. See Meta's technical account.
Grok Bot keeps connector tokens on Cursor's backend and asks members to perform sensitive sign-ins themselves. Its important boundary is different: all Bots owned by one user share files, browser sessions, and command-line credentials on one computer. A separate Bot name does not create a separate security compartment. See the Grok Bot access guide and security FAQ.
Keeping a password or token out of model context reduces one kind of exposure. A signed-in browser or connected app can still let an agent act with that account's authority, so the account and connector permissions set the reach of a mistaken action.
Permissions and approvals
Dots inherit the app connections you manage in ChatGPT. Custom Rules can allow an action, require approval, or hand it back to you; a separate Auto-review checks consequential actions against those rules and built-in safety requirements. OpenAI says autonomous proactive research uses restricted read-only tools, so that background process cannot directly send messages, edit app content, or operate a browser. An ordinary dot task can still use broader tools within its permissions. OpenAI documents the distinction.
Muse's Sentinel is the final authority for connector actions and network egress. Its approvals can be set by action, and Meta describes finer control than an OAuth grant alone. Grok Bot has personal Auto Review rules; Enterprise administrators can enforce team Auto-review and network policies. Grok Bot's connector access is shared across a member's Bots, so separate accounts or scoped service accounts matter when two workflows need different reach. See Meta and SpaceXAI's enterprise guide.
OpenAI also describes specialist dots with their own identities and credentials, but those are focused enterprise pilots. The generally rolling out product starts with one primary dot. It would be premature to treat the specialist identity model as a control that every dots customer can configure today. See the launch announcement.
Approval rules govern what the agent may do next. The data it can already read depends on the app grant and the account behind it. Review read access as carefully as send, edit, and delete access.
Disconnecting is not the same as forgetting
OpenAI says disconnecting an app stops new sharing through that connection, while information already obtained remains in the dot's context. Its Help Center says resetting the dot deletes its conversations, saved memories, and scheduled tasks. Those are distinct actions. See the dots Help Center.
Muse likewise can retain information in memory or conversation history after an app is disconnected, as covered in our earlier review. Grok Bot's docs prescribe several cleanup steps: pause routines, sign out of sites, revoke connectors at the source, and remove files on its shared computer. Deleting a Bot does not necessarily clear those shared files or browser sessions. See Grok Bot's removal guidance.
Model-improvement settings are another part of the data decision. OpenAI says Business, Enterprise, and Edu workspace content is not used to train models by default; personal ChatGPT plans have a setting that governs eligible dots conversations and work. Meta says it uses sanitized Muse interaction data for training by default and offers an opt-out. Grok Bot follows the applicable Cursor privacy and training settings. Check those settings before connecting sensitive accounts. See OpenAI, Meta, and SpaceXAI.
Activity is not automatically audit evidence
Dots' Activity View lets a user follow and redirect tasks, including delegated work. Muse describes a user-facing audit trail. Neither cited launch package specifies the request-level export format, fields, or retention an administrator would need to reconstruct every call to a connected service. That is a documentation limit, not proof that no other logging exists. See OpenAI and Meta.
Grok Bot has more documented enterprise telemetry: audit logs cover control-plane events, while Action Recording can record Bot actions if an Enterprise admin enables it. OpenTelemetry export is separate, and hosted MCP arguments and results require an additional conversation content export opt-in. Those distinctions matter when comparing an activity screen with an investigation-ready record. See the Grok Bot security FAQ.
How their controls compare with PortEden
PortEden serves a different role. Dots, Muse, and Grok Bot decide what their agents may do in their own apps and computers. PortEden applies policy to a data request only when that request goes through a PortEden API or MCP connection. Its published product pages describe the following controls.
| Control | Dots | Muse | Grok Bot | PortEden, when in the path |
|---|---|---|---|---|
| Scope | App grants and action rules; no per-resource connector filter described at launch. | Connector and action controls can be narrower than OAuth. | Member/team connector grants; Bots on one user share access. | Policy by user, action, account, time, and contact or resource for supported tools; per-client policy on Enterprise. |
| Action gate | Custom Rules and Auto-review for consequential actions. | Sentinel and user approval settings. | Auto Review; Enterprise team enforcement available. | Allows or denies covered tool calls under the configured data policy. |
| Data returned | No configurable field-level response filter documented in launch sources. | Built-in email filters remove one-time codes and reset links; no general user-configurable field policy described. | No field-level response filter described in cited Bot docs. | Can reduce or redact sensitive fields in responses from supported integrations. |
| Evidence | Activity View; request-level export not specified in launch sources. | User audit trail; request-level export not specified in launch sources. | Enterprise audit events; action and MCP content export need separate settings. | Logs policy decisions and access events for calls crossing its integration boundary. |
The PortEden entries reflect its published access control, redaction, and audit trail descriptions. Meta also documents the built-in Muse email filter above in its safety write-up. A PortEden policy does not inspect a vendor's native browser session, local computer, or another direct connector. Keep each agent's own permissions and approval rules in place.
Where PortEden can fit with each agent
- Grok Bot: Its plugin and MCP policy provides a documented route for a PortEden remote MCP connection, subject to the member's and team's settings. Calls made through that connection get PortEden's policies; Grok Bot's browser and other connectors do not. See SpaceXAI's plugin controls.
- Muse: Meta says Muse can build custom connectors for services with an API or CLI. That offers a possible PortEden route, but this article does not claim a tested, first-party Muse-to-PortEden setup. See Meta's connector design.
- Dots: OpenAI says dots use ChatGPT's shared app connections and its plugin ecosystem. We have not verified a direct PortEden connection for dots at launch. Until one is configured and tested, assume dots' native app and browser access follows OpenAI's controls alone. See OpenAI's announcement.
What to check before connecting an account
Start with the task and the smallest account that can complete it. For dots, review shared ChatGPT app grants, Custom Rules, proactive research, and how reset handles retained context. For Muse, inspect connector actions and approvals. For Grok Bot, remember that a second Bot shares the first Bot's computer and check whether your plan includes enforced team rules and action recording. Then decide which data calls should run through a narrower integration policy rather than a native full-account connection.
A vendor's agent controls and PortEden's data controls answer different questions. Use both where a workflow justifies both, and verify the actual connection path before treating a policy as protection for everything the agent can see.