Apple Full Disk Access: Not the Real Boundary

Apple Full Disk Access: Not the Real Boundary

On 2 October 2026, Apple published a developer news post titled "Updates to Full Disk Access in macOS." It is four paragraphs long. It contains no timeline, no macOS version number, no API name, and no description of the control it announces. What it does contain is an unusually candid admission about why the company felt the need to say anything at all.

The post opens by conceding the design. Full Disk Access "largely sidesteps these controls in order to allow backup apps to function properly on the Mac" — the controls being the privacy protections Apple gives developers through its normal permission model. Then the sentence that matters:

"Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users' full knowledge and understanding."

Read that as a platform holder describing an abuse pattern in its own ecosystem, in the past tense, without naming a single app. It goes on to name a category: for communication apps, this "can also compromise the privacy of the people users are communicating with" — which is a different and worse blast radius than self-exposure. Your inbox is yours. Your correspondent's inbox is theirs.

The announcement that is mostly a rationale

The promised change is one sentence: Apple "will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action."

Everything else is justification, and the justification is the story. Apple frames the whole thing around agent autonomy rather than any specific misconduct:

"Addressing this is critical. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially. We are committed to ensuring users clearly understand these risks before granting such access, so they can make informed decisions about their own data and privacy."

That is a defensible position, and it is also a narrow one. The control Apple described governs the moment of granting. It does not describe what happens to an app that already holds the grant, and it says nothing about the code inside that app. TechCrunch reported that Apple did not respond to its inquiry about the feature change, which leaves developers with a direction and no destination.

That gap is the whole article. If you build or ship a desktop AI agent on macOS, the actionable work available to you today is not waiting for Apple's control. It is auditing what your app does with an access grant it already has.

What triggered it

Two things landed within days of each other, and Apple's post reads as a response to the pattern rather than to either incident.

The first was a claim, not a finding. Inc. columnist Jason Aten reported that Meta's Muse app on macOS knew the content of his private messages even though he said he had not granted it permission to read them. Meta disputed the account. TechCrunch reported the dispute rather than the claim as fact, and Muse optionally prompts users to enable Full Disk Access, so the permission and the allegation are adjacent — which is exactly why the allegation matters, and exactly why it is not proof.

The second was a real, patched vulnerability, and it is the more instructive of the two. WIRED reported that researchers at the Objective-See Foundation found a flaw in the ChatGPT app for macOS — tracked as CVE-2026-100754, acknowledged by OpenAI in its change log on 25 September and fixed in build 26.924.20706.

The mechanism is a good lesson in why permission grants are the wrong place to look for a boundary. The ChatGPT Mac app's components authenticate each other by checking digital signatures, and the design goes further: a request is only trusted if the process making it, its parent, and its grandparent all check out. Objective-See found that one trusted component — a script interpreter — would accept an untrusted script and could be manipulated into passing it into the main ChatGPT process. Patrick Wardle's explanation of the bypass is the memorable part: the malicious script simply spawns the interpreter three times and then makes the request, satisfying all three layers of ancestry checking. He called the exploit "insanely trivial" and said his proof of concept was about a dozen lines of code.

Here is what makes this the right story next to Apple's announcement. That flaw had nothing to do with Full Disk Access. It did not require the app to hold any extra permission. It required local unprivileged code already running on the Mac, and it abused trust relationships between the app's own components. Tightening the FDA consent flow changes nothing about it.

The distinction worth holding

Put the two stories side by side and the taxonomy developers need becomes clear.

The third row is what Apple is fixing. The second row is the one that should change how you build. When a permission is the only thing standing between a compromise and a user's entire filesystem, a better dialog protects the users who read the dialog. It does not protect the users who do not, and it does nothing at all against a bug in the privileged process itself.

This is the same shape of problem as the plugin pinning bypass, where the review happened at a pin that the runtime never re-verified. A control at the boundary of trust is only as good as the assumption that nothing behind it misbehaves.

What to do this week, without waiting for Apple

Audit the grants on your fleet first, because you cannot defend a permission you have not inventoried. Reading the TCC database tells you exactly which apps hold Full Disk Access:

# macOS: list every app holding Full Disk Access
# Note: your terminal itself needs FDA for this to return anything but an error.
sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db \
  "SELECT client, auth_value, last_modified
     FROM access
    WHERE service = 'kTCCServiceSystemPolicyAllFiles';"

On a managed fleet, push the list out rather than asking each engineer to run it, and diff it against a baseline you kept. A new row is the finding.

Then separate your agent's privileges from your agent's features. An AI app that needs to read a codebase for context does not need mail, does not need Messages, and does not need browsing history — and if it does need them, that is a product decision with a blast radius attached, not a default you inherited from a setup wizard. Ship the narrowest entitlement set your feature actually exercises, and make the optional pieces genuinely optional per capability rather than one binary switch for everything.

Finally, if you maintain a macOS agent, treat your own inter-component trust model as in scope. Verify the caller, not just the signature — and if your architecture has a helper that can be induced to launch other helpers, count the ancestry hops out loud. Wardle's bypass only needed a component that would accept a script from anyone.

The honest read

Apple's announcement is a real signal, and the direction is right: an extraordinary, ecosystem-wide bypass should not be one checkbox deep. But a developer reading it on 3 October 2026 cannot implement against it, test against it, or tell users when it arrives. What they can do is stop treating the permission dialog as a security boundary.

The apps that will handle user data most aggressively over the next few years are the ones holding the most access and doing the most with it. Apple's control raises the cost of a user saying yes. It does nothing about what happens next — and CVE-2026-100754 is a twelve-line reminder that the next part was never protected by the yes in the first place.

Sources

• Apple Developer News: Updates to Full Disk Access in macOS
• TechCrunch: Apple says it's tightening macOS 'Full Disk Access' controls due to new risks from AI agents
• WIRED: A Flaw in ChatGPT's Mac App Could Have Let Hackers Grab Sensitive Data
• ForkLog: Vulnerability in ChatGPT macOS App Allowing Access to Conversations Fixed (CVE-2026-100754)