The sandbox held. The data left anyway.
An agent that can read its own runtime will hand that runtime to any destination you connected, and a rule written into a system prompt is not an access control.
On 22 September, Peter James published what came back when he asked Meta's Muse assistant to archive the files it could see and send them to his Google Drive. Muse built the archive and delivered it.
The download was just under 3 GB compressed and 6.8 GB unpacked, and it carried the root filesystem of his session: system files, Muse internal documentation, integration code, app templates, memory files, agent logs, and SSH key files.
His writeup of the Muse runtime export counts roughly 68 skill directories, 113 subagent records with their traces, and the scripts that assemble and launch the session's Linux environment.
Those skills cover a wide tool surface. Google Workspace, Meta's own apps, Outlook, travel, shopping, health services, home devices, and media generation all sit behind an instruction file and a command line tool.
The environment was ordinary Linux fundamentals work, a root filesystem with mounts and a service manager, and that part held. James probed the boundary, found no escape, and stopped early because he was poking at a live system.
Nothing in the exchange was an attack. A user asked his own assistant for files from his own session, and the assistant complied through a connector it was built to use.
Sandboxing was not absent from the product either. Muse ships a bundled copy of bubblewrap, the Linux sandboxing tool, and uses it to run video tooling as the nobody user with no network access.
That is a real control, applied where somebody thought about it. The export path is the place nobody did.
AI agent data exfiltration goes through the front door
Most agent designs spend their effort where an attacker breaks in, so sandbox escape research gets the attention and export design gets a paragraph in the documentation.
What people get wrong is treating the headline as a vulnerability class. The export needed no bug, no memory corruption, and no clever prompt, only an integration that worked exactly as designed.
Meta's bug bounty triage marked the report Not Applicable, and the reply listed several possible grounds without saying which one applied. He also wrote to employees directly and got responses, and he has not published the archive, the keys, or the session logs.
Read that as a comment on how the impact was framed. The argument was made at the container boundary, where nothing had broken.
Meanwhile every connector is an egress channel. File builders, document generators, drives, mail, and chat all move data outward, and each was added for a good reason.
Agents built in house have the same shape and less of the review. A chat bot with a drive scope and a shell is a data path with a product name, and nobody signs off on it as one.
What makes the channel hard to close is that the policy is usually enforced with the agent's cooperation, inside the same conversation an attacker can talk to.
Ars Technica reported that a ClickFix style attack is one way to hijack the assistant outright. That is the version of the story people expect, and it needed no unusual privileges to matter.
Memory is where the export gets uncomfortable. Muse keeps it in plain Markdown files backed by Postgres tables with 384 dimensional vectors, plus background jobs that rewrite the agent's guidance for future sessions.
So the archive held a record of the user as well as the product, and an accurate profile of someone's commitments is the raw material social engineering wants most.
Configuration files in the same export hinted at connectors that have not shipped yet, with names like Slack, Dropbox, and Canva. Each one is another destination to review now, before it becomes another destination to block later.
None of this is specific to one vendor. Any assistant with a filesystem, a set of connectors, and a user who can ask it for things has the same shape.
Three controls that hold better than a sandbox
The work is small compared with the incident response that follows a quiet export, and three changes cover most of the gap.
Move the decision to the destination. Allowlist where an agent may write, inspect what leaves, and give each connector its own policy and its own limits on archive creation, which is normal practice for LLM agents and tooling that a team reviews before shipping.
Split the runtime from the workspace. Keys, internal documents, and logs should not sit in the filesystem that answers a user request, so run the tool executor as a separate user with a narrower mount and keep credentials in a broker the agent can call but never read, the lesson that leaked keys in developer environments taught first.
Test the export before you test the escape. Ask the agent to list everything it can read, then ask it to archive that list and watch where the request appears in your logs, which is how this finding surfaced rather than through a fuzzer.
What to assume from here
The old assumption is that sandboxing an agent keeps your data inside the sandbox.
The new reality is that an approved integration plus an ordinary conversation is a complete path out, and none of it looks like an intrusion to anything you monitor.
Classify what the agent can read before you argue about how well it is isolated, because a private key and a memory file are not the same kind of asset as a template.
The habit worth building is to ask the agent what it can see, then reconcile that answer with what the platform says it should see, because those two answers disagree more often than either team expects.
If your agent could archive everything it can read and drop it in a connected drive overnight, would your logs tell you before the download finished?