Meta Muse's Sentinel: Separating Execution from Authorization

Meta announced Muse, a personal AI agent, on September 8, 2026.

Muse can send emails, arrange travel, and make purchases on the user’s behalf.

It is a different product from Muse Code, the coding agent Meta announced in August; this one handles everyday personal tasks.

This article examines Meta’s separation of execution and authorization in Muse and the implications for companies designing their own AI agents.

Here, authorization means determining whether an operation is allowed under the permissions granted and the conditions attached to them. That is a different question from the business judgment of whether a purchase is a good choice for the user, and this article is about the former.

Our account is based on Meta’s published announcement and technical write-ups. Reading a published design is not the same as verifying how effectively those controls work in practice, and we have not conducted independent testing.

What Muse separates

According to Meta’s technical write-up, Muse itself runs inside a containerized runtime environment, while a separate agent called Sentinel runs outside that container, on the host side.

Meta explains the reason for this arrangement: the runtime environment is designed on the assumption that it processes untrusted data, so the security functions sit outside it.

Sentinel’s role, as described, is to hold sole authority over network access and over actions sent to external services. For each operation, Sentinel decides whether to allow it, deny it, or ask the user. Sentinel evaluates each request against the policies the user has set for the connected service.

In other words, Muse deciding to perform an operation is not enough for it to reach the outside world. A separate mechanism outside Muse determines whether the request may be sent to an external service.

Authorization is not the same as business judgment

Authorization and business judgment answer different questions.

A purchase made within the permitted range is not necessarily a good choice of product. Conversely, a sound choice should still not be executed if it falls outside the granted permissions.

What Muse’s architecture makes concrete is the latter: the authorization side.

Our principle is that the AI performing an important operation should not also have the authority to approve it. Human approvals and predefined rules should be applied in a form the executing AI cannot rewrite or route around, with the boundary drawn according to how large the impact of an operation is and how easily it can be undone.

This does not mean “add a second AI to handle approvals.” Having two systems is not the goal in itself; the point is to separate who sets the conditions for permission from which mechanism actually stops the operation.

We consider model capability alongside the permissions an agent receives and the controls that enforce their limits.

Approval sits outside the conversation

One detail in Meta’s technical write-up stands out: how a request for confirmation reaches the user.

When Sentinel judges that confirmation is required, execution stops and the request is held as a pending approval. The approval exchange then takes place in a dedicated dialog in the client interface, rather than inside the conversation with Muse.

This puts the approval request itself outside the text the agent generates. If approval is requested within the conversation, the very wording the user is reading can be shaped by the agent’s output.

Meta’s design write-up describes structured approval cards with explicit accept and reject actions, reflecting a judgment that conversation alone is not sufficient in some areas.

The write-up also covers the granularity of authorization. Options described include one-time, session-scoped, task-scoped, time-bounded, and perpetual permission, with subsequent calls checked strictly against the scope that was granted.

The design write-up also addresses a side effect of asking too often. It names the risk that people approve everything simply to make the prompts go away, and describes a default that permits ordinary browsing while stopping at actions that are hard to undo.

The fact that it does not treat “more confirmations” as automatically safer is worth noting for enterprise design as well.

Three distinct safeguards in the payment flow

The payment arrangements are where the permission design becomes concrete. The design combines three distinct safeguards.

The first is not exposing credentials. Meta explains that the agent does not receive the user’s actual card details.

The second is restricting reuse of the payment instrument. For purchases at a new merchant, Meta’s wallet issues a single-use card number for each transaction, and that number, rather than the user’s regular card, is what reaches the merchant.

The third is narrowing the range of transactions that number can be used for. According to the technical write-up, the issued credential is tied to a particular merchant and a particular amount, and is valid only for a limited period. Meta states that these restrictions limit how an attacker could use a single-use card number if it were stolen through prompt injection or another attack.

These three need to be read separately, because conflating them leads to the wrong conclusion about the design.

Binding a card number to a specified amount restricts that transaction; it does not, by itself, cap spending across multiple transactions. A cumulative spending cap would require a separate control covering those transactions. This is not a claim that Muse lacks such a control—only that single-use issuance and per-transaction amounts do not, on their own, establish one.

Meta also describes purchases on sites where card details are already saved: when a payment page is detected, the user is asked to approve each time, with the details of the purchase shown.

The contrast worth carrying into enterprise design is this. Telling an AI not to spend beyond a certain amount is not the same as having the system that accepts the payment refuse anything outside the permitted conditions.

An instruction alone provides no fallback if the agent ignores it. A control enforced by the payment system can provide a separate barrier.

Rather than relying on instructions and settings given to the agent alone, enforce these constraints in the system that receives and carries out the request. The same approach applies well beyond payments, to operations against internal systems.

Activity logs support review but do not prove correctness

According to the design write-up, users can see what the agent is currently working on and open a full activity log from there.

From the materials we reviewed, we could not confirm details relevant to enterprise auditing, such as how long logs are retained, who can access them, and how they are protected against unauthorized changes.

Separately, Meta describes plans for publicly inspectable auditing of Muse Confidential VM. This concerns verification of the system’s privacy protections, rather than the retention or integrity of individual activity logs.

With that said, there is a point about records we emphasize in enterprise design.

Even when records of operations and approvals exist, that alone does not establish that the judgment was appropriate. The records should allow reviewers to compare the user’s request, the applicable rules, and the actual outcome, then assess whether the action was authorized and appropriate.

Records being kept and records being usable for verification are different things.

The same distinction applies to stopping. Being able to stop before execution and being able to restore the prior state afterward are different capabilities, and some operations—sending an email, completing a purchase—cannot be fully reversed once carried out.

What we emphasize is designing three things separately: being able to halt execution when needed, being able to see what happened after execution, and being able to undo or correct within whatever range is possible when something goes wrong.

What to decide before granting an AI agent permissions

Muse is a personal product, and an agent embedded in enterprise systems differs in both the kinds of risk involved and where responsibility sits. It does not transfer directly, but the way the questions are framed carries over.

The following lays out, as a starting point, the structure we use in our own design work.

This is not a set of recommended settings but a starting point for discussion. Work from the laws, contracts, and internal policies that apply to you, and make it specific to the impact and risk of the work involved.

Design consideration	What to define	Implementation examples
Separating execution from authorization	Ensure the executing side cannot change approval state or permission rules on its own	Authorization service, execution gateway, access control at the connected system
Confirmation before significant operations	What requires approval, and which post-approval changes trigger re-approval	Approval screens, approval workflow, execution API
Records of operations and approvals	How requests, approvals, and execution results are linked, and who reviews them	Operation logs, approval history, log management platform
Limiting permissions	How far to restrict operations, targets, amounts, periods, and expiry conditions	Authorization service, connected-system API, payment system

A hypothetical example makes this concrete.

For example, an AI could draft an email to a business contact, while a separate service sends it only to the approved recipient and with the approved body and attachments. Any change to those details after approval would require fresh approval. The AI would not have permission to change the approval status.

Framed this way, what is tied to the execution is not merely the fact that an approval took place, but what the approval was for.

Define operational responsibilities at the same time: who may change permission rules, who reviews logs, and who can suspend or resume execution. When you change a connected system or the scope of work, revisit whether the previous approval conditions and permission limits are still sufficient.

Summary

Meta’s published design places authorization outside the executing agent, handles user approval separately from the conversation, and combines several safeguards in the payment flow.

For enterprise systems, the central principle is that the AI performing an important operation should not also control the rules that authorize it. Approval should be tied to the specific action being executed, with controls enforced outside the agent’s own decision-making.

These technical controls need supporting operational procedures: clear responsibility for approval rules, log review, suspension and resumption, and corrective action after execution. The goal is not simply to add approval steps and logs, but to define who is responsible and how the limits are enforced.

Sources and Verification

This article was prepared using information available as of September 2026. Its primary sources are Meta’s newsroom post “Introducing Muse: The World’s First Personal AI Agent Built for Everyone,” dated September 8, 2026; the Meta AI Research technical write-up presented as “How We Built Safety Into Muse” (“Security and Safety for AI Agents: Our Approach with Muse”); and the design write-up “How We Designed Muse.”

Descriptions of the product’s architecture and features are based on these published materials. MIF LLC has not independently verified their operation or security.

The framing of the enterprise questions, the table, and the hypothetical workflow example are our own analysis and proposals.

Availability and specifications may change. Please check the latest official information and terms of use before adopting or relying on the product.