Why did Meta choose architecture over training for agent safety?

On September 8, Meta launched Muse, a personal agent that can send email, book travel, fill out forms, negotiate bills, and complete purchases on a user's behalf. Writing on Medium, jamilxt argues that what matters about the launch is not the agent but "the cage" Meta built around it. Meta's architecture rests on two pieces: Muse Secure VM, a per-user isolated virtual machine where "untrusted data from the web lives in one compartment" while the acting part of the agent "never sees your raw credentials," and Sentinel, a separate process that inspects every outbound action against approved policies and escalates sensitive steps — sending mail, spending money — to a human. Meta states these approval prompts "bypass the model entirely, meaning a hijacked model cannot forge its own permission." Meta backs the claim with a bug bounty of up to $300,000 for a valid security hole, including up to $130,000 for a reproducible prompt injection that compromises a single user, which jamilxt reads as a signal of what the company fears.

jamilxt contrasts this with OpenAI's ChatGPT agent (superseded by ChatGPT Work, launched July 9 on GPT-5.6), whose safety model is mostly a trained, monitored model: user confirmations before consequential actions, a Watch mode that pauses when the agent touches sensitive contexts, a browser-takeover mode for passwords the agent never sees, GET-only terminal access, and memory disabled during tasks. Citing OpenAI's system card, the author reports the agent disregarded irrelevant instructions and exfiltration attempts 99.5% of the time in a text browser and 95% in a visual browser, "but on active data exfiltration attacks in the visual browser, where an adversary actively engineers the attack, the success rate drops to 67%" — "one in three active attacks got through the model's training defenses in testing." jamilxt's own inference is explicit and speculative ("I suspect"): that this gap between passive and active-attack performance is the number that "pushed Meta toward architecture instead of training," putting the enforcement checkpoint outside the model so a successfully manipulated model still cannot act without a separate, non-model gate approving it.

The separation-of-concerns logic matches Can memory poisoning compromise decision-making even with authorization layers?, where a signed-token authorization layer keeps an action contained even though the judgment layer that is supposed to catch it is fully compromised — Sentinel plays the same structural role for Muse. It sits awkwardly next to Does Meta's Muse Wonder actually withhold private data reliably?, which frames Meta's own safety story for the same product as training-based (teaching the model to withhold data, pause before high-stakes actions); jamilxt's account credits the architecture instead, and the excerpt does not say whether these are two complementary layers of one system or two different framings of the same features. It also contrasts with Can agent safety rules stop destructive API calls in real time?, where safety rules lived only in the model with no independent gate to stop the action before it executed.

The essay is one outside author's comparative reading of two companies' own disclosures — Meta's launch materials and bug-bounty terms, OpenAI's system card — not an independent audit of either product, and its own numbers are not fully consistent: the 67% figure is introduced as how often the agent resisted active attacks (consistent with one in three got through), then redescribed two paragraphs later as "a 67% defense failure rate." Neither architecture has been tested here by a third party under the same conditions, so the piece establishes that Meta and OpenAI made different design bets, and a plausible reason for Meta's bet, but not which bet actually holds up under adversarial use.