Apple to Tighten Mac Full Disk Access for AI Agents After Meta Muse Messages Dispute

Related — October 6, 2026: An open-source CLI can turn off macOS 27's Apple Intelligence and delete its models. See RemoveMacAI.

Update — October 6, 2026: Our opinion on why permission, not capability, is now the agent bottleneck: Agent teams are the new org chart.

Apple said on October 2, 2026 that it will change macOS so that AI agents asking for full data access are easier to spot and harder to approve by accident. The announcement followed an accusation that Meta's Muse read private messages on a Mac without the user having enabled Full Disk Access.

The facts of that accusation are disputed. Apple's response is not, and it affects every AI agent that runs on a Mac.

TL;DR — what people are asking

What is established

Three things are on the record:

1. The accusation. Jason Aten of Inc magazine said Muse accessed private messages on his Mac and that he had not turned on Full Disk Access. Tom's Hardware and AppleInsider reported the claim, and one write-up described the agent referring to confidential messages it had not been granted access to.
2. Meta's response. Spokesperson Andy Stone said you must enable both Full Disk Access and the Messages connector for Muse to read Messages, and that the setting can be revoked at any time. Another outlet reported Meta saying users have to opt in three separate times, once through a macOS settings screen apps cannot set on their own.
3. Apple's response. Reported by Reuters, Apple said it will modify macOS to make it more obvious when AI agents request full data access and add controls so that only very explicit user action can grant it. Apple also said, "As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially."

What is disputed

Whether Muse read the messages without permission is the live disagreement. Aten says he had not enabled Full Disk Access. Meta says the access cannot happen without it. The two statements cannot both describe the same machine unless something else explains the data — a prior grant that was forgotten, a different permission path, a bug, or a misreading of what synced.

There is also a number in play. Reports cite more than 187,000 rows synced from the local Messages database, and Meta has been quoted denying that Muse read 187,000 messages. A row in a database is not the same as a message read by a model, so the figure should not be repeated as "187,000 messages read."

I did not find an independent forensic analysis in the sources reviewed. Until one appears, the responsible reading is that a serious claim was made, a specific rebuttal was offered, and Apple judged the underlying permission model worth changing.

Why Full Disk Access is the pressure point

On macOS, Full Disk Access is the permission that lets an app read data across your whole account — Messages, Mail, Safari history, and files from other apps. It exists for legitimate tools such as backup software. Apple's mobile systems sandbox apps from one another by default; the Mac is more permissive, and some developers have been using Full Disk Access in ways that carry risk.

For an AI agent the permission is especially potent. A conventional app that holds Full Disk Access reads what it was written to read. An agent decides at run time what to read, based on a prompt that may itself be manipulated. That combination is why Apple's quote focuses on autonomy.

This is the same class of problem we covered when OpenAI shipped Mac integrations — see ChatGPT's Apple Messages integration on Mac — and when we assessed whether Meta Muse is safe after its launch. The permission model has been the weak point in both.

Do a five-minute Mac audit

You do not need to wait for Apple's change. Here is what to check today.

1. Full Disk Access. System Settings → Privacy & Security → Full Disk Access. Review every app with the toggle on. Turn off anything you do not recognize or have not used in a month.
2. Files and Folders. In the same Privacy & Security area, check which apps can reach Desktop, Documents, Downloads and network volumes.
3. Automation. Review which apps can control other apps. An agent with automation rights can drive Mail or Messages without Full Disk Access.
4. Accessibility and Screen Recording. Agents that operate your screen need these. Remove any you do not actively use.
5. Connectors inside the app. Muse and similar agents have their own in-app connectors for Messages, Mail and Calendar. Check those too; the macOS toggle is only one of the gates.
6. Where the Messages database lives. Your iMessage history is stored in a local database in your Library folder. Any process with Full Disk Access can read that file, which is why the permission is sensitive.

If you run coding agents or desktop automation, the same audit applies. Our shadow AI privacy risk guide covers how to inventory what has access to what at a team level.

What this means for people building agents

If you ship an agent for macOS, the direction of travel is clear:

• Ask for the narrowest permission. Prefer scoped access to a specific folder or API over Full Disk Access.
• Make requests legible. Apple's change aims to make agent access requests more obvious. Design your onboarding so that a user can see why you need access and what you will read.
• Keep an access log. If a user asks "what did you read?" you should be able to answer. A simple per-run record of files and databases touched settles most disputes.
• Assume the dispute will be about evidence. The Muse case turns on what happened on one machine, which nobody can reconstruct without logs.

For the local-first alternative, Underdog's on-device personal AI takes the opposite architecture: models run on the Mac, and the vendor argues content never goes to a cloud service. That reduces one risk — remote processing — but not the local-permissions question, which still needs careful scoping.

Why always-on agents are insecure by design

The Muse dispute is the visible case, not the root cause. On October 3, Polymarket posted "JUST IN: Apple announces new Mac privacy protections after users accused Meta's Muse AI agent of accessing private messages without their knowledge," and the post drew about 79,000 views. The replies are a fair sample of public reaction: distrust of Meta, a joke that "now imagine it also holds your wallet," and one reader asking whether Messages are not supposed to be encrypted, so did Apple lie. (Muse does have a read-only bank-linking connector, covered in Muse's Plaid integration.)

That last question is worth answering, because it shows why this class of problem is hard. Message encryption protects your messages in transit and on a provider's servers. Once messages arrive on your Mac they are stored in a local database, and any process with the right operating-system permission can read it. Apple did not break encryption; the permission is the gate, which is why Apple is changing the permission.

More broadly, agents that run continuously, whether Meta's Muse, OpenAI's Dots, SpaceXAI's Grok Bot or self-hosted tools like OpenClaw, share a set of structural weaknesses. These are properties of the design, not accusations against any one vendor.

1. Standing access. An always-on agent holds credentials for mail, messages, files, calendars and sometimes money, all the time. A one-off chatbot session exposes what you paste into it; a resident agent exposes everything it is connected to, around the clock. Grok Bot's pitch is explicit: agents sign in to your tools and use them as you do (Grok Bot launch).
2. Untrusted input, constantly. These agents read email, messages and web pages, and any of them can contain instructions aimed at the model. That is indirect prompt injection (our explainer). Security researchers often describe the dangerous combination as private data plus untrusted content plus a way to send things out, and an always-on agent usually has all three.
3. Action without a person in the loop. The value of an always-on agent is that it acts when you are not looking, which also removes the moment where a human would catch a mistake. Allegations such as a Dot emailing city officials on its own, which OpenAI has not confirmed, and the reported case of Muse sharing a user's address after an Allow Always choice show how thin the line between helpful and harmful can be.
4. Approval fatigue. Permission prompts stop working when there are too many of them. "Allow always" is the rational click for a tired user, and it converts a per-action control into a permanent grant.
5. Persistence helps attackers too. Agents keep memory and long-lived tokens. An injected instruction or a stolen token can outlive a single session and keep working in the background.
6. Weak observability. Most users cannot see what an agent read or sent. When something goes wrong it may be found late: OpenAI's own out-of-scope model access in New South Wales was found about three months after it happened.
7. Permission models built for apps, not actors. Full Disk Access is a blunt, persistent, all-or-nothing switch designed for backup software. It is a poor fit for something that decides at run time what to read, which is exactly Apple's stated concern.

Vendors do build defenses. Meta's Muse runs in a per-user Secure VM where a separate Sentinel process approves network requests and connector actions (Muse launch architecture). Gating egress is a real improvement, but a gate is only as strong as the approvals users give it, and it does nothing about what the agent is allowed to read on your own machine. Local-first designs such as Underdog avoid sending content to a cloud model, but they still need careful local permissions.

How to reduce the risk today

• Grant the least, for the shortest time. Prefer read-only connectors, scoped folders and time-boxed grants over "always" and Full Disk Access.
• Keep irreversible actions behind approval. Sending, paying, deleting and sharing should require a fresh yes.
• Separate what the agent can see. Use a secondary account or test data until you trust it, and do not connect banking, health or work accounts casually.
• Treat inbound content as hostile. Assume any email, message or web page the agent reads may contain instructions.
• Restrict outbound reach. Allowlist destinations if you run the agent yourself; sandboxes such as Cloudflare's Sandbox SDK make that practical.
• Log and review. Keep a record of what the agent read and did, and look at it.
• Know the kill switch. Be able to revoke every grant in a minute.
• Match the risk to the product. Our comparisons of Dots, Grok Bot and Muse and of self-hosted agents lay out the trade-offs.

An always-on agent can be useful. It is also, today, a long-lived program with broad access that reads untrusted text and can act on its own. Treat it with the caution you would give any account that holds the keys to your digital life.

How this fits the Muse story so far

Muse has had a fast run: it hit the top of the App Store (Muse number one on the App Store), launched with a hosted-agent security model (Muse and Sentinel VM), and then drew a wave of privacy questions. This week's developments also include Meta's Gadgets SDK and Home Link devices. The throughline is a consumer agent that wants broad access, and a platform owner — Apple — deciding the access model needs to be stricter.

What people are asking

Did Muse actually read people's iMessages?

That is the disputed question. The accusation is serious and specific; Meta's rebuttal is also specific. No independent technical finding was available in the sources I reviewed.

Will Apple's change break my existing agents?

Apple has not published a version, a date or a technical description. Expect developers to get documentation first. Agents that already use narrow permissions should be least affected.

Is Full Disk Access ever necessary?

For backup tools and some system utilities, yes. For most agents, a narrower grant would do. If an agent asks for Full Disk Access on first launch with no explanation, that is a reason to pause.

Does this apply to iPhone?

The reporting frames the problem as a Mac issue, since iPhone and iPad apps are sandboxed from one another by default. The accusation concerned a Mac app.

Should I uninstall Muse?

That is your call. A reasonable middle path is to check that Full Disk Access and the Messages connector are off for it, and re-enable only if you want that feature.

Honest limitations

• The central accusation is unresolved, and I have not independently reproduced it.
• Apple's change has no published date or version in the reporting I reviewed.
• Row counts and message counts are not interchangeable; do not quote them as such.
• The audit steps use current macOS Settings wording, which can vary by version.

Bottom line

Apple will make Full Disk Access harder to grant to AI agents, after a dispute about whether Meta's Muse read a user's Messages without it. Whatever the facts turn out to be, the lesson holds: audit what has access to your Mac now, and ship agents that ask for the least they need.

Related on explainx.ai

• Is Meta Muse safe? A verdict
• Meta Muse launch and Sentinel VM security
• Meta Muse hits number one on the App Store
• Muse Gadgets SDK and Home Link
• ChatGPT Apple Messages integration on Mac
• Underdog: private personal AI on your Mac
• Shadow AI workplace privacy risk guide
• Indirect prompt injection in AI agents
• OpenAI Dots always-on agents

Reporting reflects Reuters, Tom's Hardware, AppleInsider and other coverage as of October 3, 2026. Apple has not published implementation details.