The ticket came in at 2 a.m., which is when these tickets always come in. A finance user had installed one of the new always-on assistants — the kind that promises to “remember everything so you don’t have to” — and clicked through the Full Disk Access prompt without reading it, because nobody reads it. By the time our DLP tooling flagged the process, the agent had been quietly indexing ~/Library/Messages/chat.db for six hours. Not the file the user wanted summarised. All of them. Every iMessage since 2019.
Nothing was breached, exactly. The user granted the permission. The app did precisely what the permission allowed. That’s the problem.
The permission that means “everything”
Full Disk Access has always been a lie of omission. The name suggests a file-system toggle; the reality is a single TCC entry — kTCCServiceSystemPolicyAllFiles — that, once flipped to allow, hands an app Mail’s message store, the Messages SQLite database, Safari history, your Photos library metadata, Time Machine backups, and the home directories of other users on the machine. There is no scope. There is no “just this folder.” There is one switch in System Settings → Privacy & Security, and it is either on or it is off.
This model has worked for over a decade because the apps asking for it were backup tools and antivirus engines—software you ran deliberately, that did a job and got out of the way. You could reason about a nightly backup. You cannot reason about a process that sits resident in memory, watches files change, and ships embeddings to a server you don’t control.
Here’s what the grant actually exposes, if you ever want to depress yourself in a terminal:
No root required for that last query. If the agent runs as the user — and these agents all run as the user — it reads chat.db the same way you just did. FDA was the only gate, and the user opened it.
What Apple is actually changing (and what it isn’t saying)
On its developer news site today, Apple said it’s adding “additional controls” for Full Disk Access, citing the risk from always-on agents by name — Meta Muse, OpenAI Dots, the whole resident-assistant category. The framing is scoped delegation: let a user grant an agent access that matches what they actually asked for, instead of signing over the entire disk because the app needed to read one mailbox.
That’s the direction. I’d caution against filling in the rest, because Apple hasn’t. There’s no committed macOS version. There’s no ship date. There’s no published entitlement, no new TCC service string, no sample profile. “Additional controls” is a press post, not a release note. I’ve watched too many announced-at-the-keynote privacy features slip two point releases to start writing mobileconfig against an API that doesn’t have a name yet.
Meta, for its part, pushed back before Apple even shipped anything. Its line is that Full Disk Access “isn’t sufficient” for Muse to read your messages the way the product intends — which is an interesting thing to argue, because it concedes the whole point. If FDA isn’t sufficient, that’s not a bug in FDA. That’s an agent asking for more standing than the permission model was ever meant to confer. Apple’s counterpoint, unstated but obvious from the move: the answer to “the all-or-nothing switch isn’t enough” is not a bigger switch. It’s a smaller, sharper one the user can actually reason about.
The MDM question everyone will ask first
Can you manage this fleet-wide? Today, FDA is managed through a Privacy Preferences Policy Control payload — com.apple.TCC.configuration-profile-policy — delivered by MDM. A PPPC profile can pre-authorise a known, code-signed binary so the user never sees the prompt at all:
Note what that payload can and can’t do: it can allow full access to a specific signed app, but Apple deliberately does not let a profile silently grant the most sensitive services to arbitrary software. If Apple ships a scoped model, the realistic path is that PPPC gains new keys to express the narrower grant — and declarative device management gains a status channel so you can actually see which agents hold which scopes across the fleet, instead of shelling into TCC.db one Mac at a time. That’s my bet, not Apple’s promise. Until there’s a schema, don’t write policy against it.
And the grandfathering question, which is the one that’ll bite you in six months: Apple hasn’t said. Every prior TCC tightening I’ve lived through went one of two ways — silent migration of existing grants, or a forced re-prompt that lights up your help desk for a week. If it’s scoped delegation, logic says existing all-files grants can’t cleanly map to the new narrow ones, which points at re-consent. Plan for the re-prompt. Hope for the migration.
What actually broke, and what to do about it
Pull the lessons out of that 2 a.m. ticket, because they outlast whatever Apple ships:
- The consent dialog broke first. A permission whose true scope is “everything, forever” cannot be communicated in a one-line prompt a tired user dismisses. The failure wasn’t the user’s click; it was asking a human to make an unbounded decision with a bounded sentence. Scoped prompts fix the dialog, not just the disk.
- Visibility broke second. We found the agent via DLP, not via anything Apple gave us. If your only way to audit FDA across a fleet is querying TCC.db over SSH, you don’t have a privacy program, you have a cron job. Demand the DDM status channel before you trust the scoping.
- The threat model broke third — and it’s still broken. FDA assumed deliberate, episodic tools. Always-on agents are neither. Until the new controls actually ship with a version number, treat any resident process requesting full-files access as a data-exfiltration risk and block it with PPPC denials. “Allow” is not the only Authorization value.
Apple is right that the fix is a smaller switch, not a bigger one. Just don’t deploy against a feature that currently exists as a blog post. The agent on that finance Mac is still reading chat.db tonight. Scoped delegation ships when it ships.
