Deep dive 3 of 5 · Trust · Flagship
Muse permissions: set them before you connect anything
Permissions are the whole safety story. Get this page right and most of the horror stories become structurally impossible. Last verified against muse.ai and Meta’s help centre: September 30, 2026.
In short
- Muse has four separate permission layers. People who only check one get surprised by a different one.
- Every write action — send, purchase, share, delete — should be set to ask every time, never “always allow”.
- Start every connector read-only. Writing access is earned per connector, never granted up front.
- The Feed is a real gap: community reports describe it surfacing content from sources the agent was not explicitly told to read. Treat the Feed as untrusted until you have audited it yourself.
- Check the audit trail weekly. An unreviewed agent is an unmonitored one.
The four layers, in the order you will meet them
Layer 1 · Connections
Settings → Connectors. Which systems Muse can reach at all: Gmail, Google Docs, files, calendar, health services, music. Revoke from here. If you did not connect it today, it should not be listed tomorrow.
Layer 2 · Action approvals
Per-action prompts — allow once / always allow / deny. This is the layer that actually decides whether an email leaves your outbox. Almost every incident traces back to a careless “always allow” here.
Layer 3 · The Feed
Ambient context — updates, reminders, things Muse noticed. It draws on connected sources and behaves less like a folder you opened and more like something reading over your shoulder. See the section below.
Layer 4 · Permissions & trail
Settings → Permissions. The overview plus the history of what the agent did. This is your only after-the-fact evidence. If you never open it, you cannot tell a working agent from a misbehaving one.
The failure mode people report — “I told it not to and it did anyway” — is almost always a Layer 2 or Layer 3 problem they had assumed was covered by a Layer 1 setting.
Allow once, always allow, deny — choose deliberately
These three buttons look like a minor speed bump. They are the product’s real security boundary.
Allow once
The correct default for everything that writes. Costs you one tap, buys you a full review of every send. Use this for a month before you even consider “always”.
Always allow
Grant this narrowly — one action, one connector, after you have watched it succeed safely 10+ times. Never for: send email, make purchases, share files, delete anything, post publicly.
Deny
Reach for this more often than feels natural. An agent that cannot do something is not a limited agent — it is a predictable one. You can always re-enable it later.
The Feed blind spot
On launch week, users on Hacker News and Reddit described the Feed surfacing context from connected accounts — including email content — that they had not explicitly asked it to read, while a separate complaint on Hacker News was that Muse ignores permission prompts mid-task rather than respecting a “deny”. Independent testers reported the same shape of behaviour.
Meta’s position is that conversational context is not sold to advertisers and that permissions are user-controlled. Both can be true at once: the Feed reading scope is simply broader than the connector list most people check.
What to do about it
- Open the Feed and inspect every source it claims — remove any you did not connect.
- Disconnect the connector that is feeding it if you cannot trace the source.
- Re-test with one connector only: does the Feed stay silent about the others? If it does not, keep it disconnected.
- Report it via the in-app feedback so it lands with the team rather than in a thread.
These are launch-week reports from the week of September 29, 2026. Product behaviour changes fast in a rollout — re-test yourself rather than assuming this page is current. Last verified: September 30, 2026.
A least-privilege setup you can copy in five minutes
- 1Open Settings → Permissions and write down what is currently listed. Anything you do not recognise: disconnect.
- 2Set every write action to “allow once”. Send, purchase, share, delete, post, invite — all three options, always, every time.
- 3Connect one thing, read-only. Gmail first is a good default. No files, no health data, no music, no docs on day one.
- 4Do one real task and watch every prompt. Note which ones you were asked about and which you were not — that delta is your actual risk surface.
- 5Audit the trail. Confirm the recorded actions match what you saw. Now add the next connector and repeat.
- 6Only then grant narrow “always” on reads, and only where it genuinely improves the task.
Paste into Muse right after connecting
Before every action: list the permission you need, the approval you are triggering, and the exact data you are about to read. Wait for my yes.
Red flags a permission prompt should never show
- A password field. Muse never needs a third-party password — connectors use OAuth handoffs. The credential store story here is Meta’s own 1Password-style storage for the credentials you do hand it.
- “Read all email, forever, silently” asked for at install time rather than when the task needs it.
- A purchase approval you did not initiate. Any spend that arrives without you asking for a spend should be denied and reported.
- Approval dialogs that appear after the action already ran — approval has to be a gate, not a receipt.
- Any prompt asking for your Meta password, a login code, or a screenshot of your Settings. Meta support does not ask for these.
If you see any of these, deny, disconnect, and read troubleshoot. Then come back and finish the setup.
For businesses: the policy to write before rollout
Written down, one page, agreed before anyone installs anything:
- Scope. Which accounts and which connectors a given team may attach. Default answer: none, until requested.
- Write policy. No outbound email, message, purchase, or share on “always allow”. Approval required, every time, logged.
- Data classes. What must never enter a prompt — credentials, health data, customer PII, financial account numbers.
- Privacy defaults. Model-training opt-out set on every account. See privacy settings.
- Review cadence. Someone opens the audit trail weekly and reconciles it. Named owner, not a group.
- Offboarding. Connectors revoked the day someone leaves or changes role.
We write this with you in one session — request a session.
Permissions: questions
- Where do I change Muse permissions?
- Settings → Permissions for the overview and audit trail, and Settings → Connectors to add or revoke individual systems. Per-action approvals appear at the moment Muse needs them.
- Should I pick “always allow” to stop the prompts?
- Only for narrow reads you have already watched succeed repeatedly. Keep every send, purchase, share, delete, and post on “allow once” — that single habit prevents most incidents.
- Muse read something I did not tell it to. Is that normal?
- The Feed draws on connected sources with a broader scope than the connector list, and launch-week users reported exactly this. Inspect the Feed’s sources, disconnect anything untraceable, and re-test with one connector at a time.
- Can I see what Muse did with my data?
- Yes — the activity or audit trail under Permissions. It is your only after-the-fact record, so review it regularly rather than only after something goes wrong.
- Does Muse need my Gmail password?
- No. Connectors go through the provider’s own OAuth screen, so Muse never sees the password. If anything asks you for a third-party password directly, deny it.
- What is the safest way to start?
- One connector, read-only, one real task, and watch every approval prompt. Then audit the trail, then widen. Read our /start/ page for the two-minute version.