If your agent asks for Full Disk Access on day one, you built it wrong, and Apple is about to make that everyone’s problem.
Apple published a note on its developer site on October 2, 2026, titled “Updates to Full Disk Access in macOS,” saying it will introduce additional controls to ensure that users understand the risks before granting that permission. TechCrunch framed it as a response to new risks from AI agents. AppleInsider described it as Apple moving to protect private Mac data from overreaching AI apps. John Gruber at Daring Fireball put it more bluntly, calling it a response to agentic AI apps running amok. No rollout date has been disclosed.
Apple’s own framing is the part I keep coming back to. The company says Full Disk Access exists to let backup apps function properly on the Mac. Backup apps. That is the use case. A backup tool genuinely needs to read everything, because reading everything is the entire product. Almost nothing else on your machine has that excuse, and yet the permission has quietly become a checkbox that half the tools in my Applications folder ask for during onboarding.
Why agents broke the old bargain
Full Disk Access has always been a blunt instrument, but it survived because the apps requesting it were predictable. A backup client does backup things. A disk cleaner cleans disks. The behavior was bounded by code someone wrote and shipped.
An agent is not bounded that way. The whole point is that it decides what to do next based on what it reads. Hand it the keys to your entire file system and you have granted read access not to a program but to a decision process, one that can be steered by the contents of the files it opens. I have built enough of these to know how fast that gets uncomfortable. A tool-calling loop with filesystem access and a network client is one poorly worded document away from doing something you did not sanction. The document does not even need to be malicious on purpose. It just needs to contain text that looks like an instruction.
That is the gap Apple is reacting to. The consent dialog was designed for a world where users could reasonably predict what an app would do with permission. Agents removed that predictability without changing the dialog.
What this means if you ship agent tooling
Clearer consent prompts mean more users saying no. If your architecture assumes a yes, you have a product problem arriving on an undisclosed timeline. Some practical positions I have landed on:
- Scope access at the directory level. Ask for the folders your agent actually needs and nothing else. A code assistant needs the repo. It does not need Mail, Messages, or Photos.
- Put a filesystem layer between the model and the disk. Do not let tool calls resolve arbitrary paths. Allowlist roots, reject traversal, and log every read. If you cannot produce a list of what your agent touched last session, you cannot answer a user’s security question.
- Treat file contents as untrusted input. Text the model reads is data, not instruction. That boundary has to be enforced in your orchestration code, because the model will not enforce it for you.
- Make permission requests just-in-time. Asking for broad access during onboarding, before the user has any reason to trust you, is the worst possible moment. Ask when the task requires it and explain which task.
- Separate read and write paths. Plenty of agent features need to read a file and propose a change. Fewer need to write silently. Keep the write step gated behind explicit user approval and you reduce blast radius without hurting the experience much.
The uncomfortable part for builders
Narrower permissions make agents less impressive in demos. An assistant that can search your whole machine looks magical. One that asks which folder looks like software. I think the magical version was always borrowing trust it had not earned, and the correction was coming from somewhere. Apple getting there first just means the correction arrives as a platform requirement rather than as an incident report.
We do not know the shape of the new controls yet. Apple said additional controls and clearer consent; it did not publish the API surface or a date. So this is not a migration guide. It is a heads-up that broad disk access is becoming a design smell, and that building around it now is cheaper than retrofitting later.
My own rule for anything I ship from here on out is simple. If That rule costs me some features. It also means I never have to explain to a user why my tool read something it had no business reading.
🕒 Published: