In their launch announcements for personal AI agents, both Meta and OpenAI highlighted privacy as a core selling point. However, an analysis published on October 10 by The Verge expressed skepticism about whether Muse and Dots can fulfill these pledges. While there is not yet enough data to fully evaluate technical incidents, it shows that user trust is already the primary battleground.

A closer examination of the technical documentation from both companies reveals that the real issues come down to practical questions: What scope of access and actions is the AI granted, which routes does data travel along, and what mechanisms exist to intercept unintended behaviors? Marketing touting an isolated computing environment is clearly insufficient to address these challenges completely.

Data Can Still Leave the System Despite Dedicated Computers

Documentation from Meta indicates that each Muse user is allocated a dedicated Linux virtual machine in the cloud. For security reasons, the agent runtime environment is fully isolated from other critical services, including authorization mechanisms and credential storage. The agent is not permitted direct access to actual credentials; connection requests must undergo inspection before required data is injected at the network perimeter.

While this is an effective protective measure, it does not guarantee that data remains entirely confined to the private machine. According to Meta, a certain amount of data must still be sent out for model processing and operational monitoring.

Notably, the documentation clearly distinguishes the current Muse Secure VM release from Muse Confidential VM, an experimental version planned for future release along the roadmap. In the current release, preventing employee access relies solely on operational policies rather than technically blocking Meta from intervening when necessary for support, security, or service maintenance. The pledge of ironclad security via encryption applies only to the future version and does not reflect current capabilities.

Separating the Boundary Between Read Access and Execution Permissions

To govern task actions, both Meta and OpenAI deploy independent oversight mechanisms outside the agent’s runtime environment:

  • Sentinel from Meta: This component operates independently of the agent environment and is responsible for reviewing, blocking, or requiring user confirmation for network connections and queries. Approvals are strictly scoped to individual operations rather than granting blanket permissions based on general conversational consent.

  • Auto-review from OpenAI: Dots operates separately from the orchestration system and safety layers. A distinct Auto-review system inspects impactful actions, such as editing files or sending emails. The agent cannot unilaterally disable these mandatory guardrails.

Regarding Dots’ proactive research capabilities, the company states that this feature uses read-only tools exclusively. As a result, this process does not interact with the desktop or browser, does not modify application content, and does not dispatch messages; any subsequent actions must follow the standard review pipeline.

Although these details currently reflect only vendor-disclosed claims that have not undergone independent verification, they raise a crucial question: Are safety restrictions genuinely enforced by independent software, or do they merely exist as model-level system prompts?

The Model Training Dimension in the Security Equation

Using data for model training presents unique privacy challenges across different providers:

  • Meta’s Policy: While committing not to share VM data or conversation logs with advertising systems, Meta may still use task execution histories and interaction data (with identifying information removed) to train AI, unless users actively opt out. Furthermore, an agent’s actions on external websites could still indirectly influence ad targeting.

  • OpenAI’s Policy (Dots): Data from Enterprise, Business, and Edu accounts is excluded from training by default. Conversely, for personal accounts, whether work outputs and conversations are used to improve models depends on user settings. Notably, disconnecting an app does not automatically delete information the agent has accumulated in its private context, although this context does provide a reset mechanism.

Consequently, privacy in AI agents cannot be treated as a monolithic concept; it must be separated into distinct aspects:

  • Protecting passwords from a model does not ensure the model cannot read email content.

  • Isolating the execution environment does not mean entirely blocking access by the service provider.

  • An option to disable model training does not eliminate the risk of data leaks or unintended transmissions.

As agents are entrusted with increasingly broader permissions, the deciding factor does not rest on marketing promises made by developers. Instead, users require empirical verification, the ability to audit permission scopes, and clear procedures to revoke both data and access once trust in the system is lost.