At the brief's 01:30 UTC snapshot on October 3, Apple's two-paragraph notice had drawn 120 Hacker News points and 70 comments. That attention does not prove a security failure. It does expose the detail Mac developers still lack: what the replacement permission flow will do. Apple says it will add controls around Full Disk Access because AI agents make the permission substantially riskier, but its October 2 announcement gives no operating-system version, release date, API, or migration instructions.
The change matters because Full Disk Access is unusually broad. Apple says the permission can expose files, mail, messages, browsing history, and data belonging to other people in a user's conversations. Its planned response is to require what it calls very explicit user action before an app receives that access, according to the developer notice. For now, developers have a direction and almost none of the mechanics.
A backup permission became an agent permission
Full Disk Access exists partly so backup software can do its job. A backup utility cannot copy a Mac faithfully if the operating system hides app databases, protected folders, and other users' files from it. Apple acknowledges that the permission largely bypasses its usual privacy controls for that reason in the developer notice.
The current setting reaches much further than a folder picker. Apple's macOS settings guide says an approved app can access every file on the computer, including data from Mail, Messages, Safari, Home, Time Machine backups, and certain administrative settings for every user. A person adds an app from System Settings under Privacy & Security, then leaves an app-level switch enabled.
That model predates the current wave of desktop agents. Apple's platform security guide says full storage access has required an explicit addition in system settings since macOS 10.13. Since macOS 10.15, the system has also enforced user consent for protected locations such as Desktop, Documents, Downloads, iCloud Drive, and network volumes. Those rules were built around applications requesting data, with the person deciding whether the application should receive it.
An agent adds another decision-maker after that grant. It can interpret a request, inspect local material, and choose which information seems relevant to the task. The app may have legitimate permission at the operating-system layer while the person did not anticipate a particular read at the task layer. Apple's notice focuses on that gap: the company says some developers are using Full Disk Access in ways that expose private data without users fully understanding the reach of the grant.
The Muse dispute shows why one switch is hard to explain
Apple did not name an app, but the notice followed a dispute over Meta's Muse agent. A columnist said Muse knew the contents of private messages even though he had not knowingly given it permission to read them. Meta spokesperson Andy Stone disputed that account, saying Messages access is opt-in and requires both Full Disk Access and a Messages connector, according to The Verge's report.
That disagreement does not establish that Muse bypassed macOS controls. It does expose the communication problem Apple now has to solve. A person can enable the two settings described in The Verge's report and still have a different expectation about when an agent will read a message, which conversation it may inspect, and whether that material can influence an unrelated task. Permission screens record consent to a capability. They do not prove that the user understood every later choice an autonomous process might make with it.
The distinction is sharper for communication data because another person's information is involved. Apple says in its developer notice that Full Disk Access for a communications app can compromise the privacy of the people its user talks to. The contact on the other side of a Messages thread never approved the Mac app, yet their words sit inside a database the permission can expose.
This is why a more emphatic version of today's warning may fall short. If the future control still grants one app persistent access to every protected store, the user must predict a long series of agent actions at the moment of approval. Apple's announcement promises more explicit action, but it does not say whether that action will narrow the data, shorten the duration, recur for sensitive reads, or merely add friction to the existing grant.
The missing specification is now the developer story
Apple has described the outcome before describing the interface. The notice contains no name for the new control and does not identify a macOS release. It says nothing about whether existing Full Disk Access grants will survive the change, whether apps can detect the new state, or whether a backup utility and an AI agent will face different rules. The Verge also reported that Apple gave no rollout date.
Those omissions leave several ordinary product flows unresolved. An agent may need access to one Messages conversation rather than the entire Messages database. A search tool may need a user-selected project folder for ten minutes. A backup app may need unattended access every night. The current Full Disk Access setting treats those cases alike at the storage boundary, while Apple's notice implies that at least some uses now deserve a different consent path.
Managed Macs add another unanswered layer. Apple's deployment documentation lets administrators configure privacy preferences through a device-management payload. The payload requires user approval and supervision, and macOS applies the more restrictive result when multiple payloads exist. Apple has not said how the forthcoming controls will interact with those policies or whether administrators will receive new settings.
Developers therefore cannot write a reliable migration yet. Replacing Full Disk Access with the narrower Files & Folders permission may work for an app whose scope is already visible to the user. It does not solve a backup product's need to read protected app data, and Apple's notice does not announce a new entitlement or agent-specific API that would cover either case. Any claim about the final design would be guesswork.
What Mac teams can audit now
The useful work begins with the permission already shipping. Teams can list every feature that stops working when Full Disk Access is disabled, then separate required reads from convenient ones. Apple's settings guide distinguishes the broad grant from Files & Folders access, which covers specific locations. That gives developers a documented narrower path for features that only need user files in known places.
Agent developers also need to inspect the step between permission and execution. A system prompt or setup screen cannot enforce an access boundary by itself. If an agent can call a tool that reads a protected database, the application should know which user action authorizes that call, what path the tool may touch, and how the result is kept out of unrelated tasks. Apple's announcement does not prescribe those controls, but its complaint about users lacking full knowledge makes that review hard to postpone.
Revocation deserves the same attention. Because the present interface exposes a switch for each app, a test plan should cover what happens when a user turns it off during a session, after indexing has begun, or after the app has created its own cache. Removing macOS access cannot erase copies the app already made. Developers need to account for those copies under their own storage and deletion rules.
Product copy should state the exact feature that needs the grant. Apple's published list is concrete enough to avoid euphemisms: Full Disk Access can include Mail, Messages, Safari, Home, backups, and administrative data. If an app asks for all of that to power one search box, the explanation should say so before the user reaches System Settings.
Apple's next useful move is a specification. Watch for an SDK beta, updated privacy payload tables, and guidance on existing grants. Until one of those appears, Mac developers know the permission boundary is moving, but they do not yet know where Apple will draw it.