Meta Muse Exposed for Leaking the Contents of Its Virtual Machine

Meta's personal AI agent Muse is facing a rather embarrassing permission-isolation incident.

According to reports on September 25, developers Peter James and Jonny L. Saunders independently reproduced the issue: with nothing more than relatively simple prompts, users could potentially make Muse package and return a large number of Linux files from its dedicated cloud-based virtual machine. The exported files were not limited to ordinary workspace files. They also included system files, application templates, internal operating documentation, Markdown and JSON configuration files, and agent execution records.

This was not a traditional "breach of Meta's hosts," and the information currently available is insufficient to prove that attackers could cross tenant boundaries and access other users' data. It is nevertheless a serious warning sign: the Agent runtime environment, which should serve as a trusted computing boundary, may actively hand over its internal structure to users through the model's own tool calls.

In other words, the door was not pried open by a hacker. Instead, after hearing a single sentence, the robot inside carried out the cabinets, ledgers, and operating manuals itself.

More Than Just a Few Configuration Files Were Exported

Publicly disclosed information shows that the files obtained by the researchers covered multiple layers of Muse's runtime environment, including internal mechanisms for request handling, memory storage, service connections, and background tasks.

The agents/ directory contained records for 113 sub-agents, along with JSONL-formatted trace files. Approximately 20 Markdown documents covered functions including browsers, connectors, payments, credentials, data processing, voice, goal management, and scheduled tasks.

The researchers also counted approximately 68 skill directories, spanning capabilities such as:

• Productivity services such as Google Workspace and Outlook;
• Meta-owned social applications;
• Travel, shopping, and healthcare services;
• Home-device control and media generation;
• Third-party connectors such as Slack, Dropbox, Polymarket, Canva, and Klaviyo.

These files may not have contained valid keys that could be immediately exploited, but their value should not be underestimated. To an attacker, internal directories, tool names, task orchestration methods, connector inventories, and error-handling logic are themselves a map of the system.

A traditional Web service leaking an internal API document is already enough to give a security team a headache. An Agent platform may leak "API documentation + operating procedures + tool permissions + historical execution traces." The latter is much closer to a complete playbook for taking action.

The Real Problem: The Model Is Both the User Interface and a Privileged Operator

Muse is not a chatbot that merely generates text. It runs in a cloud-based virtual machine, can process files, invoke a browser, connect to external services such as email, and retain some persistent data.

The core value of this architecture is precisely that it upgrades the model from "answering questions" to "doing things on the user's behalf." But the closer its capabilities come to those of a real operating-system user, the less appropriate it is to apply the permission model of an ordinary chat product.

A typical Agent request flow looks roughly like this:

1. The user describes a task in natural language;
2. The model determines the intent and generates an execution plan;
3. The Agent invokes file, browser, or third-party connectors;
4. The tools perform operations inside a virtual machine or container;
5. The model reads the results and decides what to do next;
6. The final content is organized and returned to the user.

The risk lies precisely between the third and fourth steps. User input is inherently untrusted, and the model's plan is not a deterministic program. If the underlying tools only check that "this request came from Muse" without checking whether "the user is authorized to read this specific path," the model becomes an agent for bypassing permissions.

This is why "we put the Agent in a virtual machine" is not an answer. Virtual machines primarily isolate different runtime environments; they do not automatically enforce least-privilege controls inside the virtual machine. Even if the Agent cannot access the host, the model may still mix together and deliver user files, platform templates, internal documentation, execution traces, and connector configurations if they are all present in the same virtual machine.

Based on the information currently available, this incident appears more like a failure of data boundaries inside the runtime environment than a virtual-machine escape. For Agent products, however, that is already dangerous enough, because internal files can help attackers continue looking for higher-value attack surfaces.

Prompts Are Not a Permission System

This issue once again exposes a common misconception in AI Agent products: development teams may tell the model in the system prompt not to read internal directories or disclose credentials, and then treat that constraint as a security boundary.

But following a prompt is probabilistic behavior; access control must be deterministic.

The distinction is straightforward:

• A prompt constraint says, "You should not do this";
• A permission system enforces, "You cannot do this at all."

If the ability to read sensitive directories still exists, attackers can use role-playing, task decomposition, encoding conversions, archive requests, or indirect prompt injection to continually search for wording that the model is willing to execute. Even if one type of prompt is blocked, it is difficult to prove that every semantically equivalent request will also be blocked.

More troublingly, an Agent does not receive only user input. Web pages, email bodies, shared documents, calendar invitations, and even image OCR results can all serve as carriers for indirect prompt injection. A seemingly normal task such as "read my emails and organize the attachments" could expose the model to instructions planted by an attacker, after which it might invoke local file tools or external connectors.

Therefore, a mature Agent security model should at minimum include the following:

• Isolate file permissions by path: The workspace, system templates, runtime logs, and internal platform documentation must not all be visible through the same tool handle;
• Issue temporary capabilities per action: Allow a tool to read only specified files for a limited period, rather than granting long-term access to an entire directory;
• Require secondary confirmation for sensitive operations: Before exporting archives, reading credentials, sending messages in bulk, or executing payments, show the user exactly what will be affected;
• Prevent data leakage on output: Do not inspect only inputs; also scan compressed archives, logs, and text returned by the Agent for keys or internal paths;
• Isolate connector credentials: The model may request to "send an email," but it should not directly read the OAuth token;
• Log tool calls in full: Security audits need to know which files the model read and in what context, not merely preserve the final response.

The 113 Sub-Agent Records Expose Another Problem

The presence of numerous sub-agent records in the agents/ directory also suggests that Muse may use a relatively complex task-decomposition mechanism. The primary agent receives a goal and then delegates browsing, retrieval, file processing, or connector operations to different sub-agents. This is a common engineering approach for Agent products today.

Multi-agent architectures can improve task-completion rates, but they also make security audits more difficult.

With a single model, developers can at least trace a relatively continuous context. In a multi-agent system, permissions may be amplified during task delegation: the primary agent may not have direct access to a particular directory, but it can delegate the task to a sub-agent with file-tool access; that sub-agent may then write the results to a shared area, where another agent packages and returns them.

If the platform checks the user's request only at the entry point, rather than reauthorizing every tool call and agent handoff, permissions can quietly spread along the task chain.

This is similar to a situation in a company where one employee lacks access to the financial system but asks an authorized colleague to look something up, then has a third person send out the result. Each person performs only a small step in isolation, but together they bypass the original boundary.

For Developers, the Tool Layer Deserves More Scrutiny Than the Model

Incidents like this can easily steer the discussion toward "Why did the model obey a malicious prompt?" But for teams building Agents, the more practical question is: even if the model could be induced to do anything, can the underlying system limit the damage to an acceptable level?

Model providers, system prompts, and reasoning versions can all change at any time. Relying on the model to be "obedient enough" is not robust. What really needs to be verified are the invariants of the tool layer:

• Does the file-reading interface reject attempts to move outside the workspace root?
• Can symbolic links, mount points, or compressed archives bypass path checks?
• Do logs and trace files contain user content, system prompts, or credentials?
• Can sub-agents inherit permissions beyond what their tasks require?
• Do connectors expose tokens to the model context?
• Are there limits on the number and sensitivity level of files that can be exported in bulk?
• Can users trigger internal platform diagnostics, backups, or debugging functions through natural language?

The phrase "user-dedicated virtual machine" also deserves particular scrutiny. Dedicated does not mean secure. If a platform preloads internal operating materials into every user's instance, a leak in any single-tenant environment could repeatedly expose the same system structure. Attackers might not even need to compete for shared resources; they could simply register their own accounts and conduct ongoing tests inside environments legitimately assigned to them.

The Muse Incident Will Not Be the Last

The information disclosed so far does not prove that Muse experienced a cross-user data leak, nor can it directly establish that Meta's host infrastructure was breached. Until Meta provides a technical explanation, observers still need to distinguish among the risk levels represented by "internal files are readable," "sensitive credentials were leaked," and "cross-tenant access occurred."

This incident nevertheless deserves serious attention because it reveals a structural problem affecting the entire Agent industry, rather than a defect unique to a particular model.

In the past, the biggest concern for large-model products was saying the wrong thing. Now that Agents can read files, send emails, operate browsers, connect to payment systems, and execute scheduled tasks, the risk has become doing the wrong thing and actually delivering data that should never have been delivered.

The approximately 68 skill directories exposed by Muse illustrate this contradiction perfectly: the more connectors an Agent has, the more useful it becomes; the broader the range of callable services, the more complex its permission graph becomes. Product teams want their agents to act like all-purpose assistants, but they must restrict those assistants using an approach much closer to a zero-trust system.

This is not a problem that can be solved by adding another system prompt.

For Meta, the key questions to answer next include: Which files could be exported? Did they contain valid credentials or user data? Were the virtual machines of different users completely isolated? And what remediation measures were taken after the issue was discovered? For other Agent vendors, now is the time to inspect their own sandboxes: Is the file system visible to the model larger than product managers imagine?

The next round of competition among AI Agents will appear to be about who can connect to more services and complete longer tasks. At a deeper level, however, whether these products can enter enterprise and highly sensitive environments will be determined by something less glamorous: when the model is induced to misbehave, can the permission system firmly say "no"?

References

• ITHome: Meta's AI Agent Muse Found Capable of Exporting Large Numbers of Files from Its Virtual Machine — Summarizes the reproduction of the issue, the types of files exported, and information related to Muse's virtual machine and skill directories.