Meta Muse’s dedicated per-user VM does not prevent provider access
Meta documents a dedicated per-user VM for Muse, while provider-access prevention remains a planned confidential-computing capability.
Meta describes Muse’s launch architecture as a dedicated cloud virtual machine for each user. Operational policies restrict personnel access, but the current design does not prevent Meta from accessing data when needed to support, secure, or operate the service. Meta presents a planned Confidential VM as the capability intended to add cryptographically verifiable prevention of provider access. It describes model-training opt-out controls separately. Meta AI Research
Axios reports the same central distinction: Muse launched with a dedicated virtual machine, while a confidential version remains under development. It also reports that users can disable the use of their queries for model training. Axios
The supplied evidence documents vendor statements and a secondary report about the launch. It does not demonstrate how these controls operate in a buyer’s environment. That limit should shape the procurement decision: a dedicated workspace, a restriction on personnel access, a training opt-out, and technical prevention of provider access do not establish the same property.
Start with the selection criterion
If provider inaccessibility is required now, the supplied material does not establish that Muse meets the criterion. Meta says access remains technically possible for stated operational purposes and describes provider-access prevention as a planned Confidential VM capability. Meta AI Research
If the immediate requirement is a dedicated per-user compute boundary, Meta’s architecture description addresses that narrower question. It does not establish provider inaccessibility or observed isolation in a buyer deployment.
The training decision is narrower again. Meta describes an opt-out control, and Axios reports that users can disable use of their queries for model training. Neither statement changes the documented provider-access capability. Meta AI Research Axios
Record the claims without a privacy label
A procurement record can preserve the distinctions without assigning Muse a single privacy grade:
| Procurement question | State supported by the supplied evidence | Evidence class |
|---|---|---|
| What compute boundary is described? | Dedicated per-user cloud VM | Vendor architecture description |
| Can the provider technically access data? | Yes, for stated support, security, or operational purposes; personnel access is restricted by policy | Vendor description |
| Can users disable training use? | An opt-out control is described | Vendor description and secondary report |
| Is provider-access prevention available now? | Not established; a Confidential VM is planned | Vendor roadmap description |
This is an SGL-derived recording format. The boundary unit and evidence class are review fields, not properties independently verified by the supplied sources. “Current” in the record means currently documented, not observed in a buyer’s deployment.
Define what would change the decision
The record should change only when stronger evidence changes a specific answer. A future Confidential VM announcement would update roadmap status, but availability would still need to be established. Deployment evidence could support a claim about a configured environment, while an operational test could support an observed result. Those evidence states should not be inferred from the launch description.
Teams carrying the procurement decision into the build can turn each required property into an architecture requirement and acceptance criterion. For Muse today, the bounded conclusion is direct: Meta documents dedicated per-user compute and a training opt-out, but the supplied material places technical prevention of provider access in a planned confidential-computing state.