DEV Community

Cover image for Meta Muse and macOS Full Disk Access: Apple's permission plans

Meta Muse and macOS Full Disk Access: Apple's permission plans

Apple says it will add controls around macOS Full Disk Access because increasingly capable AI agents make broad access to personal data riskier. The announcement comes during a dispute about Meta Muse reading a user's private messages. For developers building desktop assistants, the immediate question is what a user understands when they approve access, and which capabilities the application actually receives.

TL;DR

  • Apple's October 2 notice promises additional controls requiring “very explicit user action.” It provides no implementation or rollout date.
  • Full Disk Access exposes protected data across applications, including Mail, Messages and Safari. Accessibility and Automation appear as separate permissions in Apple's documentation.
  • Jason Aten's claim about Muse accessing messages without permission remains disputed. Meta says both Full Disk Access and its Messages connector are required.
  • Historical AgentDojo results demonstrate why tool boundaries matter. They provide no measurement of Apple's proposed controls.
  • My verdict is NEEDS REVIEW: clearer consent makes sense, and the implementation must preserve legitimate backup and automation workflows.

What Apple announced about macOS Full Disk Access

The Apple Developer notice is short. Apple describes Full Disk Access as a mechanism that largely sidesteps other privacy controls so backup applications can function. It says some developers use it in ways that expose files, mail, messages and browsing history without users' full knowledge and understanding.

The proposed change is additional control over the grant itself. Apple wants people who genuinely want to authorize this level of access to do so through “very explicit user action.” It also explicitly connects the problem to AI agents becoming more capable and autonomous.

There is no named vendor in the notice. There is no screenshot of a new dialog, new entitlement, implementation guide or date. Those omissions matter if you maintain an application whose onboarding flow requests broad access. You can review the flow today; a precise migration plan has to wait for a concrete specification.

I would also avoid treating the announcement as a delivered security result. Apple has explained its objective. We still need to see the behavior, the wording presented to users and the consequences for existing grants. Those details will determine whether a user understands the access better or develops another reflexive approval habit.

Meta Muse: the messages-access claim and the response

Sarah Perez's October 2 reporting places Apple's announcement after an incident reported by Inc. columnist Jason Aten. Aten said Muse knew the contents of private messages despite his understanding that he had not granted the relevant permission.

That account is contested. In TechCrunch's September 30 report, Meta communications executive Andy Stone says the Messages integration is entirely opt-in. His response on X says users have to enable both Full Disk Access and the Messages connector.

Meta's David Singleton also describes a sequence of application and macOS permission steps, including manually confirming the change in System Settings and restarting Muse. Aten's account says Full Disk Access was off. The assistant reportedly offered an explanation involving device notifications; Singleton disputed that explanation as well.

An assistant's explanation of its own behavior cannot establish the operating system's permission state. Resolving a dispute like this requires reproducible behavior and evidence about the actual configuration. We do not have that resolution here.

The chronology is useful context. Apple's notice still gives no basis for saying it has identified Muse as the target or established a particular bypass. A developer can take the broader consent problem seriously while keeping those factual boundaries intact. The competing accounts belong in the story together.

What does Full Disk Access let an application read?

The Mac User Guide's Privacy & Security table gives a concrete starting point. Its Full Disk Access entry includes data from other apps such as Mail, Messages, Safari and Home, data from Time Machine backups and certain administrative settings for all users.

The breadth explains the backup use case. A backup application that encounters protected directories everywhere would have a hard time producing a complete backup. Granting broad access can therefore be a legitimate choice.

An agent changes how that access is used. It can read data as input to reasoning and, depending on the tools and privileges it separately has, take actions based on its interpretation. A task described as helping with a project can become an invitation to encounter unrelated personal material if the surrounding application exposes that material.

The same guide has separate entries for Files & Folders, Accessibility and Automation. Accessibility covers controlling the Mac through scripts and system commands. Automation covers accessing and controlling other apps. That separation is useful when reasoning about a desktop agent's capabilities.

Here is the practical distinction I use when reviewing an integration:

Boundary Question to answer
Data access Which protected files or application data can enter the assistant?
Tool availability Which operations can the assistant request?
Action authorization Which consequential operations require another decision?

This is a conceptual review table. It does not describe a new Apple interface. Its purpose is to stop a single broad phrase, such as “computer access,” from hiding several independent decisions.

Prompt injection and the cost of broad agent access

An assistant encounters text from emails, documents and websites while doing normal work. Some of that text can try to redirect the assistant toward a different task. The danger grows when the assistant has tools capable of carrying out the redirection.

AgentDojo, developed by researchers at ETH Zurich and Invariant Labs, provides an independent way to examine that boundary. The 2024 paper describes 97 realistic tasks and 629 security test cases involving agents using tools over untrusted data.

The framework measures both task usefulness and adversarial behavior. That is an important combination: a defense that prevents every action by making an assistant unusable gives a developer an obvious product problem. The paper also reports failures on legitimate tasks without attacks, so ordinary task performance belongs in the evaluation.

The published results table provides a particularly clear historical example. For GPT-4o's May 2024 model snapshot, one instruction-injection attack configuration had a targeted attack success rate of 47.69 percent with no defense. The corresponding tool-filter configuration had a rate of 6.84 percent. In that experiment, limiting the available tools changed what the attack could achieve.

Those rows come from June 2024. They are not measurements of current Muse, current frontier models or Apple's future permission controls. The results page also cautions that coverage differs across models and configurations, so it cannot support a fair general ranking.

The lesson worth carrying into a product review is narrower and useful. Available actions are part of an agent's security boundary. Evaluating the model's refusal behavior alone leaves that part of the system unexplained. Check what the complete application exposes, then test the complete application against the tasks it is supposed to perform.

A developer review you can perform before the rollout

Start with the task the user actually requested. Determine which data sources the application provides to the assistant for that task. A selected project directory is a smaller input surface than an entire account, though its contents can still be sensitive.

Then inspect how the application's interfaces explain the request. Can the person see which sources are involved? Can they understand whether granting access affects only the task in front of them or future sessions too? Does the product distinguish reading a source from sending information or deleting something?

These are design questions, rather than claims about Apple's unpublished implementation. They can guide an audit of an existing permission flow without inventing new operating-system behavior.

Legitimate broad-access applications need consideration as well. Terminals, search tools and backup utilities can have real reasons for accessing protected material. Taking useful workflows away would impose its own cost. My preference is an understandable grant and a task-sized input surface wherever the product can provide one.

Apple's notice adds another person to this review: the correspondent whose messages sit on the user's machine. Apple expressly says communication-app access can compromise the privacy of the people the user communicates with. A conversation contains their information too. The person approving the app on a Mac is making a decision that reaches beyond their own data.

That is the point I would put near the permission request. Explain what enters the assistant in terms a person can connect to their actual files and conversations. An abstract warning about a powerful AI system is much harder to act on.

Also today: Pass Designer and Utah's VPN-location rules

Apple's Pass Designer beta helps build Wallet passes from templates and images. Apple says its live preview uses the same rendering as iOS and watchOS. It validates fields and can generate a backward-compatible pass structure from semantic data. The beta requires macOS 27 or later; Apple lists free registration for the download. Distribution remains a separate part of the pass workflow.

The Electronic Frontier Foundation reports a preliminary injunction against challenged VPN provisions of Utah SB 73. EFF quotes the court saying “geolocation perfection is not presently possible.” A destination website sees a VPN exit address, which cannot guarantee the visitor's physical location. The court's reasoning, as quoted by EFF, describes a burden reaching 28 million Aylo users. This is a preliminary order; the separate restriction on sharing VPN information was not challenged.

Verdict: NEEDS REVIEW

I want clearer consent for broad agent access, with legitimate workflows preserved. Apple's direction makes sense. Its implementation will determine how well the change works, and that implementation is still pending.

The question for an app developer is concrete: which data and tools does this task need, and does the person granting access understand the answer?

FAQ

Has Apple already shipped the new Full Disk Access controls?

The October 2 notice says Apple will introduce additional controls. It gives no implementation or rollout date.

Did Apple say Muse bypassed macOS permissions?

Apple's notice names no application. Aten's messages-access claim and Meta's response remain disputed accounts in the reporting cited above.

Does Full Disk Access authorize every agent action?

Apple documents Accessibility and Automation separately. Review data access, available tools and consequential actions as distinct parts of the application.

Should I use the AgentDojo percentages to judge a current assistant?

Those percentages describe a specific historical model and attack configuration. A current product needs its own evaluation of the whole agent system.

Sources


This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Top comments (0)