Sentinel: The Agent That Approves Muse's Internet Access
Meta gave Muse a second, separate agent whose only job is approving or blocking every network request the first agent tries to make. Here's how Sentinel works, and what it can't see.
Most AI agent products handle permission with a list of rules: things the agent can do without asking, things it must ask about, things it can never do. Meta built something structurally different for Muse — a second, independent agent whose entire function is standing between Muse and the outside world.
That agent is Sentinel, and per Meta's own description, it runs on the same virtual machine as Muse but is "kept apart from Muse at the system level." The line that matters most: "nothing Muse does reaches the internet unless the Sentinel approves it." Every outbound network request, every action against a connected app — Slack, Shopify, whatever the user has authorized — passes through Sentinel first.
Why a second agent instead of a rules engine
The obvious alternative design is a static permission list — a set of rules a human writes once, that the agent checks against before acting. OpenAI's Dots takes a version of that approach with its Custom Rules feature, which lets users specify actions that require approval or are prohibited outright, backed by an Auto-Review system that checks consequential actions before execution (more in Custom Rules and Auto-Review).
Meta's choice to make the gatekeeper itself an AI agent, rather than a fixed rule set, is a bet that a learning, context-aware evaluator can catch more real-world edge cases than a list anyone could write in advance — the classic tradeoff between flexibility and predictability. A static rule set is auditable and its behavior is knowable in advance; a second agent doing judgment calls is more adaptable but harder to fully specify or test exhaustively. Meta hasn't published details on how Sentinel is trained, what its decision criteria actually are, or how often it escalates to the user versus decides autonomously — those specifics matter a great deal for anyone trying to assess how reliable the gate actually is, and they aren't yet public.
What Sentinel explicitly cannot see
The one guarantee Meta has been specific about is a data boundary, not a behavior boundary: "Muse has no visibility into people's passwords or payment methods." Credentials are stored and used without either Muse or, implicitly, Sentinel's oversight layer ever exposing them in a form the agent can read. That's the mechanism behind features like 1Password support, where Muse can use a saved login to act on a site without the raw credential ever passing through the model's context — a design we look at in One Password and Muse.
This is a meaningfully different posture from xAI's Grok Bot, which signs into existing tools using the user's own credentials directly — a deliberate design choice by xAI to support tools with no API or MCP integration at all, but one that necessarily means the credential-handling boundary is drawn in a different place, and a formal safety framework comparable to Sentinel wasn't found in the sources covering that launch. We compare the two models directly in Muse vs Grok Bot.
A gate that can approve or deny actions but can't see the credentials being used is a specific, deliberate design: it limits what a compromised or manipulated Sentinel could leak, even in the worst case, because the thing attackers would want most was never in its field of view to begin with.
The audit trail as the backstop
Meta has also committed to full audit trails for Muse's actions and user-controlled app-access permissions — meaning that even where Sentinel's exact decision logic isn't publicly documented, users are meant to be able to see after the fact what the agent did and what was approved. How granular and legible those audit trails actually are in practice is a question this series returns to directly in Audit Trails: How Much Visibility Does Muse Actually Give You? — a stated commitment and a genuinely usable oversight tool aren't automatically the same thing, and that's worth verifying independently rather than taking on faith.
What's clear today is the shape of the system: isolate the agent (the Secure VM), constrain what it can reach (Sentinel), and hide the most sensitive data from both (credential and payment blindness). It's a coherent three-layer design. Whether it holds up against real adversarial pressure — malicious prompts embedded in web pages, social engineering attempts routed through a connected app — is the kind of claim that only gets tested once millions of people are actually using the product, which, as of this launch, they now are.
The prompt-injection problem Sentinel actually has to solve
The specific threat model worth naming directly is prompt injection — the class of attack where a malicious actor hides instructions inside content an agent is going to read, rather than attacking the agent's own code. If Muse is browsing a webpage on a user's behalf to complete a task, and that page contains hidden text instructing "the agent" to take some unrelated harmful action — forward a payment confirmation somewhere, escalate its own permissions, exfiltrate data from the VM — Sentinel is the layer that's supposed to catch that before it reaches the internet as an actual outbound request. This is, in practice, the hardest open problem in agentic AI security industry-wide, and it's not unique to Meta: OpenAI's Custom Rules and Auto-Review system for Dots (covered in Custom Rules) exists to solve a version of the same problem, and neither company has published data on how effectively their respective systems perform against adversarial prompt-injection testing specifically.
That absence of published red-team results is worth flagging plainly rather than assuming the architecture solves the problem simply because it's well-designed on paper. A second agent watching the first agent's outbound actions is a strong mitigation — it means a single successful injection has to fool two separate evaluation passes rather than one — but "harder to fool" and "unfoolable" are different claims, and Meta's public materials make the more modest one implicitly by describing Sentinel as an approval layer rather than an unbreakable guarantee. Independent security research into how Sentinel performs against real adversarial prompts is the kind of evidence that would move this from an architecturally sound design to a proven one, and that evidence doesn't yet exist in the public record as of this launch.
Part 4 of 30 in the Meta Muse series. Previously: The Muse Secure VM: How Meta Isolates Your Agent's Work. Next: Designing a Voice: What Describe It and Muse Sounds Like That Means. Browse more builder insights or explore AI skills at aiskill.market.