An Agent Is Not Its Own Permission Authority
On September 8, 2026, Meta launched Muse — a personal agent that reads your inbox, drives a browser, runs a shell, and keeps working after you close the app — and published, in unusual detail, the architecture that decides what it may actually do. The agent proposes. A separate component, which the agent cannot override, grants or refuses. The design answers one question about execution with unusual structural clarity. The question it leaves open is worth stating precisely.
What happens
On September 8, 2026, Meta launched Muse, a personal agent that lives in a dedicated cloud machine per user, connects to email, calendars, cars, and homes, drives a real browser, writes and runs its own tools, and continues working unattended. The same day, Meta Superintelligence Labs published a long account of how the system is built to be safe — not a policy statement, but the runtime architecture.
The center of that architecture is a component called Sentinel. Meta’s own words: Sentinel is “the sole permission authority for connector actions and network egress.” Muse proposes actions; only Sentinel can grant permission to perform one. When the agent wants to act through a connector, a request goes to Sentinel describing the connector, the method, the class of action, its scope, and what the user asked for. Sentinel evaluates the policy the user has set and decides: allow, deny, or ask. Every concrete network request is governed the same way at egress — hostname, resolved address, port, protocol, method, path, decoded request. The agent never holds a real credential; it sees surrogate tokens, and Sentinel swaps in the real one at the network boundary only after the request is authorized.
When the decision is ask, Sentinel creates a pending approval and execution stops. The approval dialog is routed to the client directly, not through the agent’s conversation. And what the user grants is not a conversational yes. Meta describes approvals as “strict capabilities, not conversational suggestions,” bound to a particular connector, destination, and use case, with a scope the user selects — one-time, session, task, time-bounded, or perpetual — and Sentinel “ensures that subsequent invocations match the granted scope exactly.” Purchases go further, along two paths. Where a site already holds the user’s payment method, Muse detects the checkout page and requires a human approval showing the exact purchase, every time. Where it does not, Muse’s own wallet issues a single-use card number — tied to that merchant, that amount, and a limited window — and that, too, requires a human approval for each event.
Meta states the design intent plainly: the system assumes the agent may be under attack, and “deterministic boundaries apply even if Muse is persuaded to behave badly.”
The usual reading
The natural reading is a security story: a serious answer to prompt injection, defense in depth, least privilege, credentials the model never sees. That reading is correct and the architecture earns it.
But the same design says something about execution that a security reading skips over — and it says it structurally, not in prose.
The permission authority is not the agent
Pull out the one decision that matters and look at where it lives. The component that reasons, plans, and wants to act is not the component that decides whether it may. Muse is capable; Sentinel holds the authority. The agent’s intent is an input to the decision, never the decision itself. Meta’s three-way split makes the point in a single sentence: privsep decides where credential-capable code runs, authd decides which credential a caller may receive, and Sentinel decides whether the requested action may be taken.
This series has argued for that separation at payment batches, vendor-risk desks, and payment protocols. Muse implements it in a consumer product, in the runtime. The agent can submit a request to Sentinel — that is the interface — but, as Meta describes the design, it cannot alter Sentinel’s approval state or route around it. That is the property that makes an execution boundary independent: the thing being governed can ask, but cannot change the answer.
Two further design choices make that separation concrete. The first is that consent is an object, not a sentence. A grant is bound to connector, destination, and use case, and every later invocation is checked for exact match against that scope. “You said yes earlier” cannot be stretched to cover a different action. The second is that, on the wallet path, the execution-time credential is itself scoped to the act: a card number valid for one merchant, one amount, one window is an authority object that expires with the action it was created for. That binds authority to the act. It does not, by itself, re-check whether the purchase is still wanted or whether the task it belongs to still exists — and it is worth keeping those two things apart, because the rest of this case turns on the difference.
Where scope currency ends
Now the refinement, stated carefully, because the design deserves precision rather than a complaint.
The public account shows two kinds of check at the moment of action. One is scope currency: this request is inside what the user permitted — the connector, destination, and use case of a grant, matched exactly. The other is request-level security inspection: the decoded request, the actual resolved destination, and, through kernel-level taint tracking, whether the requesting process has touched user data. Both are evaluated at the moment of action. Neither is, on its face, a check of the operational conditions the action depends on.
That third category is where an execution boundary asks its question. Consider three conditions such a boundary would state explicitly — a hypothetical, not an observed failure: if the task an invitation belongs to has been cancelled, do not send; if an external attendee’s access has been revoked, do not send an invitation that carries materials; if a required state cannot be verified, hold rather than send. Each is a fact about the world at the moment the action opens, held in some system of record. Whether a task-scoped grant is invalidated when the task is cancelled is an implementation choice the public account does not settle. The point does not depend on it: a scope match, however exact, establishes that the request falls within the granted scope — it does not by itself establish that a separate condition on the world is satisfied.
The public account describes the separation of proposal from permission in detail. It does not describe a general mechanism that, before each execution, requires confirmation of conditions like these against an authoritative source and stops when confirmation fails. Nothing here licenses the conclusion that Muse lacks such checks — the account is about safety architecture, and it does not enumerate every evaluation Sentinel performs. What it licenses is the next question, and the question is precise: which current state is the permission authority required to consult before it opens an action, whose system attests that state, and does execution hold when the state cannot be established?
That question does not divide cleanly along personal versus organisational lines. A personal agent also depends on conditions its user does not control — a counterparty’s permission, a service’s status, a booking that was cancelled. The difference is in who sets the conditions and which system is trusted to attest the current state. Muse shows where the decision point is and puts a component there that stops execution when the decision is not yet made. The evaluation that remains to be shown is what that component is obliged to look at.
Where this is heading
Muse is a consumer agent launched for US users, and its architecture puts a permission authority outside the agent, at the point of action, with execution stopping when a decision is pending. Once that exists, the questions that follow are specific rather than philosophical, and they are the ones worth asking of any system built this way: alongside the scope match, which operational conditions is the authority required to confirm before an action opens? Which system of record is trusted to attest each of them? And when a required condition cannot be established, does the action hold? Muse’s single-use payment credential binds authority tightly to one act; the next thing to look for is the state check that sits beside it.
The proposition
An agent that can reason about an action, plan it, and want it has produced an input to a permission decision. It has not become the authority that makes it. Muse builds that separation into the runtime: proposal in one component, permission in another, and the agent unable to override the second. The design also brings the next question into focus — a permission that still matches its scope is not the same object as a consequence that is still eligible now, and eligibility turns on which conditions the authority must confirm, from which source, and what happens when it cannot.
The agent can decide what it wants to do. Something else decides whether it may — and that something must be looking at now.
Sources: Meta AI Research — How We Built Safety Into Muse (Sept. 8, 2026); Meta Newsroom — Introducing Muse (Sept. 8, 2026). The architecture described here is taken from Meta’s published account of the system at launch; it is not the result of independent verification of the implementation.