Designing Mac agents without Full Disk Access

Apple said on 2 October 2026 that it plans to introduce additional controls around Full Disk Access on macOS. Its stated concern is that some developers are using the permission in ways that can expose files, mail, messages and browsing history without users fully understanding the consequences, and Apple explicitly connected the growing risk to increasingly capable and autonomous AI agents. Apple did not give a date for the change. My reading of this is fairly practical: if I build a Mac agent whose unattended operation depends on Full Disk Access, I am building around a permission Apple now wants users to grant only through very explicit action.

What Full Disk Access actually gives an app

Apple's macOS User Guide describes Full Disk Access as allowing apps to access all files on the computer, including data from other apps such as Mail, Messages, Safari and Home, Time Machine backup data and certain administrative settings for all users. Apple says the permission largely sidesteps its normal privacy controls so backup apps can function properly.

That is a much broader permission than the nearby Files & Folders setting, which lets apps request access to files and folders in different locations on the Mac. App Management is separate again and allows apps to update or delete other apps. All three controls sit under System Settings > Privacy & Security. In my own agent designs, I treat that separation as useful architecture rather than an obstacle: the agent should get the narrow capability its job requires, not a blanket route around the controls.

The context around Apple's announcement

The timing came after several reports about applications handling sensitive local data. TechCrunch reported that Inc. columnist Jason Aten said Meta's Muse app on Mac had read his private messages, a claim Meta disputed. The same TechCrunch report also pointed to a Wired report about a flaw in ChatGPT's Mac app that could have allowed hackers to access sensitive data. Apple did not respond to TechCrunch's inquiry about the feature change.

The Verge reported Meta spokesperson Andy Stone's response that Messages access in Muse is entirely opt-in and requires a user to enable both Full Disk Access and the Messages connector. The Verge also noted that Apple had not said when the update would roll out. I do not take those reports as evidence that every agent using broad permissions is behaving badly. My reading is narrower: once an agent can autonomously act on data, permission boundaries become part of the agent design, not merely part of installation. For the small-business owner’s side of the same change, the Thind Global Services blog has a plain checklist.

What happened in my own setup this week

One of my own scheduled agent pipelines stalled this week because its working folders were inside a cloud-synced location under ~/Library/CloudStorage. The per-folder grants macOS offered for Desktop, Documents, Downloads and explicitly allowed folders did not cover that path in the way this job needed. The agent's shell could list the filenames, but it could not open a single file.

The quick fix on offer was to give the whole agent Full Disk Access. I did not take it. Instead, I moved the hot working folders to a plain local path the agent is explicitly allowed to read and accepted a day's delay while I changed the pipeline. That is the sort of trade-off I want to make before a client workflow becomes dependent on a permission prompt. It also comes back to who should own your agent loop: if I own the behaviour, I also own the permission model that makes the behaviour possible.

My practical rules for Mac agents

• Inventory the exact paths and apps the agent needs before granting anything, because the principle of least privilege only works when the required surface area is known.
• Give the agent its own working directory and keep every scheduled job inside it, so the agent sandbox has a clear boundary that can be inspected and moved.
• Treat any instruction saying to “just enable Full Disk Access” as a design smell, because a convenience shortcut is not the same thing as a justified permission decision.
• Keep agents away from Mail, Messages and browser profiles unless accessing them is literally the job, and when it is, scope the workflow to one account and explain that scope to the client.
• Log what the agent touched, because I want to be able to defend each permission afterwards with evidence from the job rather than assumptions about what it probably did.
• Assume Apple's future “very explicit user action” could interrupt an unattended process, because a scheduled job that relies on Full Disk Access may eventually meet a human checkpoint it cannot pass.

Unattended jobs should not depend on human prompts

An unattended agent works because its required capabilities are available when the scheduled job starts. A permission flow that deliberately requires explicit human action cuts across that assumption. Apple has not said exactly what the new controls will look like or when they will arrive, so I am not designing around an imagined implementation. I am designing around the direction Apple has stated: granting this level of access should require clearer, more deliberate user involvement.

In my own setup, the response is to remove Full Disk Access from the dependency graph now. Put working data in a dedicated local directory. Request only the Files & Folders access the job genuinely needs. Keep sensitive app data outside the agent sandbox unless the task explicitly requires it. Record file access so the boundary can be reviewed later. If a pipeline cannot operate without blanket disk access, I would rather change the pipeline while I control the timing than discover the weakness when a scheduled job stops at a permission screen.