unbrowseAn account may permit more than the job you delegated. A useful personal agent has to live inside that difference.
Keep it outside every personal account and it can offer plenty of advice about things you still need to do yourself. Give it everything the account can do and “help me with this” can become “act as me.” Neither is a satisfactory handoff.
That is the uncomfortable idea worth defending in Meta's Muse: useful delegation may require access to the places where the work lives.
Access needs a job attached
Imagine giving this assignment: find the confirmation for a particular hotel booking and prepare a summary of its cancellation terms. Do not cancel it. Do not contact the hotel.
The person has named an outcome and bounded the authority needed to reach it. Access to the mailbox may be necessary. The ability to send messages is not part of this assignment, even if the same signed-in account possesses it.
That mismatch is the problem a personal-agent system must solve. Account permissions describe what the service allows. Delegated authority describes what this person has asked this agent to do now. Those boundaries can differ substantially.
The boundary must survive the agent making a mistake, including following a hostile instruction in retrieved material. A prompt saying “please be careful” does not close the gap. Controls outside the model must govern the capabilities it can use. If the system cannot impose the required restriction, it needs to disclose that limitation before the person treats the restriction as real.
We already understand the shape of a handoff. A secretary gets appropriate access, a clear assignment and instructions about when to ask. We do not ask every vendor to implement Secretary Protocol before a person can start working. We also do not confuse a login with permission to do anything behind it.
What Meta says it is building
Meta describes Muse as using a separate virtual machine for each user, with a Sentinel system governing permissions. It says credentials are protected from the agent, sensitive actions require approval, and people can inspect activity and revoke access.
Those are Meta's descriptions of its design. They are useful things to examine, not independent proof that the deployed product is safe.
The distinction matters because each control addresses a different failure. Keeping a password out of model context protects the secret. It does not prevent misuse of the account the secret unlocks. An approval can protect a consequential action, provided the person sees enough detail to understand what they are approving. Revocation helps only if the system actually stops using the withdrawn access.
The defense of the premise should make these questions harder to evade. Once we accept that an agent may enter an account, we owe the customer an intelligible account of what happens there.
Test the boundary, not just the result
For the booking assignment, finding the correct terms proves only the permitted part of the job. It says nothing about whether the agent could cancel the reservation if a page or message persuaded it to try.
In a controlled test account, try the forbidden action and verify that enforcement blocks it outside the model. Then withdraw access and check that the system can no longer use the session. These are proposed acceptance tests, not results we have measured for Muse or Unbrowse. A consent screen establishes what the person agreed to; execution has to establish whether the system respects it.
Approval also needs context. Before an agent asks to change a reservation, the person should see which booking will change and any known consequence. An approval button beside a vague summary does little to improve a bad decision. If the consequences cannot be established, that uncertainty belongs in the handoff.
A maintained integration with narrow permissions can make these boundaries easier to enforce. When no integration covers the job, the invoice problem returns: the customer becomes the operator. An authorized website route may help with access, but it does not weaken the requirement for task limits. Learning how cancellation works grants no permission to cancel.
Permission and convenience must meet
Unbrowse works on the access and reuse part: discover a supported operation, supply authorized website access through the protected sign-in handoff, and reuse a verified route. Saved credentials stay out of ordinary chat and tool arguments.
A saved login retains the powers the website gave it. It does not enforce a narrower assignment, and Unbrowse does not inherit Muse's isolation design. The surrounding system still has to enforce the boundary the customer was promised.
For an evaluation, the Unbrowse documentation supplies the connection and execution paths. Start with the read-only part of a real job and specify what counts as completion. In the booking example, that includes the correct reservation, the relevant terms and a source the person can inspect.
Also specify what must never happen. An accurate summary is no consolation if the agent cancelled the trip on the way to producing it.
A person should be able to say, “You may do this for me,” without either becoming the assistant's operator or handing over the run of their life.
The job and its limits need to travel together.