Meta Muse Hands Every User an Ubuntu Machine; Permissions Stay With the Buyer── A provider only walls off the environment; the line between permitted and forbidden, and the record of it, stay with the using organisation

On 25 September 2026 it was reported that Meta's AI agent Muse hands every user a machine running Ubuntu Linux and can send terminal commands to it. When every user is handed a machine an agent can run commands on, who decides what the AI must not do? The provider decides only how the environment is walled off. The line between permitted and forbidden is settled by the using organisation, and kept in its records.

01When an AI gets a terminal, the permission line is not part of the product

Meta gave every Muse user a free machine in the cloud. It runs Ubuntu Linux, and the AI agent can send terminal commands to it. Each environment runs on two AMD EPYC Turin cores with 8GB of memory.

The provider built the isolation. The judgement about which operations are allowed is not inside that isolation; it sits with settings and approvals.

Unless the using organisation draws the line and records it, what the AI must not do is left to the provider's default settings. Work proceeds on those defaults all the same. Whatever proceeds without a line of the organisation's own becomes work for which nobody can later establish who permitted what.

02Muse's isolation reaches as far as keeping credentials outside the cell

The isolation has been described publicly. Work happens inside a Runtime Cell, a compartment with its own root filesystem, separate from the host. A second mechanism called Sentinel watches over sensitive operations. Passwords and credentials are stored outside the cell.

Meta's own documentation describes Muse Code as a coding agent for the terminal and for CI, with approvals and an OS sandbox enabled from the first run. Having approvals on by default is a strong starting point.

All of this walls off the environment. Separating the compartment does not settle which commands are permitted inside it. The strength of the isolation and the existence of a line are two different questions. Note that the account of the isolation comes from Meta itself; no third-party verification has been found.

03In medicines records, granting and revoking access must itself be recorded

What is permitted inside the compartment stays with settings and approvals. Is there any field that writes the recording of approvals into an obligation? Computerised systems used in medicines manufacture have exactly that requirement.

EU GMP Annex 11 requires that the creation, change and cancellation of access authorisations be recorded. Systems managing data and documents must be designed to record the identity of anyone entering, changing, confirming or deleting data, together with date and time. An organisation drafting promotional material with generative AI does not step outside that recording requirement.

Annex 11 governs computerised systems in medicines manufacture, not the material review process itself, and it does not transfer wholesale to practice in Japan. The one readable point is that a field exists where recording approvals is written as a duty.

04The moment approvals are switched off, isolation becomes a settings problem

Some fields write access records into duties. The next question is whether there is a route by which the approvals themselves come off. Muse Code offers two ways of working: approving each step through the terminal, or handing one instruction to muse exec and letting it run to the end.

The second is built for automation and assumes nobody is watching continuously. That is not a defect. It is an operating choice.

There are defects too. CVE-2026-82533, published on 8 September, let an agent inside the sandbox disable its own approval prompts with a single command and elevate to full access. It was scored at CVSS 9.4, and a fixed version had been released on 27 August. This was a flaw in DeepSeek's harness, not in Muse. The general point is what carries over: approval settings can be undone from the inside.

Once approvals are gone, the strength of the isolation no longer limits what can be done inside the compartment; what bites there is how the user configured it. However firmly the compartment is separated, an agent holding full access inside it can do everything that compartment allows.

05Even across 380,000 concurrent environments, the ways out were found first

Approvals can be undone by configuration. So how far has the isolation itself been tested? A 31-page paper DeepSeek published on 19 September gives the scale: a system supporting around 380,000 concurrent environments and handling some three million sandboxes a day.

The second of the three shows the order of play. The first route was closed, and then the second was found. An agent in training is searching for whatever reaches its reward. If a second path runs beside the blocked one, it takes that path.

The paper describes events in a training environment, not a report of the same thing happening in production. The figures still stand. Whoever provisioned 380,000 environments learned about the ways out afterwards.

06Permissions, autonomy and records together settle the line

With the measurements showing that those closing gaps move second, what has to be settled in advance narrows to three things.

The first is permissions. The judgement to keep granted functions and rights minimal belongs to the adopting organisation, not the provider. Muse hands the same environment to everyone. What that environment is allowed to touch is decided by whoever receives it.

The second is the degree of autonomy. Unless a company fixes the points at which a person approves, the automation settings fix the line instead. The moment a team decides to run something through muse exec, the intermediate approvals are gone. The decision to skip them is the line.

The third is records. Without them nobody can later establish who permitted what. Annex 11 requires grants and revocations to be recorded precisely so that this check remains possible. In an organisation keeping no approval history, it cannot even be shown that a permission line existed.

These three are settled together, not in sequence. Keep permissions minimal without fixing the approval points, and automation simply runs inside the minimal permissions. Fix the approval points without recording them, and no trace of the decision survives.

07For high-risk uses, a way to stop the system becomes a legal requirement

Who settles permissions, autonomy and records? In one area the law has already answered. Article 14 of the EU AI Act requires that high-risk AI systems can be effectively overseen by people while in use. Awareness of over-reliance on the output, the decision not to use the system, and procedures for intervening and stopping it sit in the same article.

Article 14 reaches only high-risk uses. Whether an agent with a terminal falls inside that category is decided use by use, and at this stage it has not been established. Nothing supports writing that Muse falls within that scope.

The three questions can still be put to yourself without waiting for the article to apply. If who permitted something cannot be traced, keep business data out until it can. If there is no stop, run only as far as a stop reaches. Neither is done because Article 14 has been established to reach your own use. Both are operating choices available today.

When an AI is handed a machine it can run commands on, the provider does not decide what it must not do. What Muse hands over is an environment, and the compartment that separates it is part of the product.

The line exists only once the using organisation writes down the uses, the permissions and the approval points, and keeps the record of what it allowed. Run without writing any of that, and the approval settings become the organisation's rule.