A helpful AI agent cannot be a private one

Meta’s Muse can browse the web, make purchases, send messages, generate documents and images, set reminders, track goals, and connect to your apps and services through what Meta calls Connectors. It runs these tasks in the background whether the app is open or not. Meta’s own example is a standing instruction to watch the daily weather and warn you about rain, which the agent carries out on its own with no further prompting.

Each of those abilities is a grant of access, and that is the point of the product category. Meta draws the line this way: a chatbot answers one question at a time, an assistant handles longer conversations and generates content, and a personal agent “can take real actions across the web and connected apps, work through multi-step tasks on its own, and keep running in the background even after you close the app.” The step up in usefulness from a chatbot to Muse is a step up in what the agent can see and touch.

The listed features each require their own access. To monitor a price, Muse needs standing read access to whatever it is watching. To send an email on your behalf, it needs your account. To pull information from connected apps, it needs a live connection to those apps and the data inside them. To complete a purchase, it needs payment details and the authority to spend. Agentic operation means Muse decides which of its skills a task needs and chains several steps together, so the access is not scoped to the single action you approved. It is scoped to whatever the agent works out it needs along the way.

Meta’s answer to the privacy problem is consent and review. You set permissions per connection and can allow an action once, always allow it, or deny it. You can review the agent’s activity and change defaults at any time. There is also what Meta describes as “a protective layer to stop your information from being shared without your approval.”

That last control is narrower than it reads. It governs sharing, the outbound step where Muse hands your data to a connected app or service. It does nothing about what the agent itself takes in, because the agent cannot act on data it has not read. The protective layer sits between Muse and third parties, not between you and Muse. For Muse to book a reservation or research a topic across your accounts, it has already ingested the relevant data. Approval decides only whether the result leaves for somewhere else.

The “always allow” option and background operation push the same way. The permission model constrains the agent only at the moments you are asked, and a standing task like weather monitoring or price watching is built to run for days without asking. Grant “always allow” on a connection once and the per-action review that Meta points to as its privacy guarantee stops happening for that connection. The more useful you make Muse, the more of its work happens outside any prompt you see.

If you are evaluating an agent like this, treat the connectors as the real exposure surface. Attach the fewest you can, and prefer allow-once over always-allow for anything that sends, spends, or shares. Read the activity log as a standing habit, not as something you check after a problem, because the background tasks are where access accumulates quietly. Assume every capability you turn on is also a standing read grant on the data behind it, and scope the connected accounts to match. A connector that only needs to read should not share credentials with one that can also send.