Last Friday, Apple announced plans to improve how requests to grant Full Disk Access are made. Initially I was a bit wary about how that might affect the CCC installation workflow; I still remember the challenge of coaching users through the initial rollout of privacy controls in macOS Mojave. After having some time to digest Apple's words, I'm now enthusiastic about changes to the procedure of granting Full Disk Access – primarily as a user, but also as a developer. Asking the user to grant Full Disk Access to CCC is a huge responsibility. That's a responsibility that we take very seriously, and it's something that I think some companies have been far too casual about. Apps or businesses that have an economic interest in your private data should never "need" Full Disk Access.

Apple's announcement seems likely to be related to the rise of AI agents, and recent reports of agents gaining access to private user data, and other malfeasances. If you're not familiar with AI agents, these are AI models that go beyond answering questions in a web browser; they live on your Mac and can do real things on your Mac at your behest. For example, you could ask an AI agent to write a script that deletes anything older than one week from your Downloads folder, and do that on a daily basis. I'm not really sure why that's the first example that popped into my head, I can't imagine giving an AI the privilege of deleting stuff in an automated manner! But that's the general idea — going beyond the trivial "proofread this document" or "solve these math problems in my homework", AI agents could harness the power of any command-line utility on your Mac and then do real things. They could potentially even build software.

Once installed on your Mac, the only thing between a precocious AI agent and your private data are the macOS privacy and security controls. When an AI agent (or software that it has built or called upon) tries to access the content of your Desktop folder, for example, macOS will forbid the access and present a dialog, "Do you want to allow XYZ to access your Desktop folder?" I doubt that I need a visual aid here, we're all very familiar with these dialogs. Perhaps too familiar; that potential for dialog fatigue is why Apple imposes different requirements for attaining the broadest privilege, Full Disk Access (FDA). Applications cannot ask macOS for FDA; there's no prompt that you could click that would immediately grant that to an application. This is 100% deliberate. Back in 2018 (at the last WWDC event I went to in person), I recall having a conversation with Apple's Privacy Engineering Manager. I asked whether we might see a dialog to grant Full Disk Access, comparable to the other privileges, and she flatly said (paraphrasing), "No. We want the user to be very deliberate about granting that particular privilege."

When an application does something that requires FDA (e.g. attempt to get a folder listing of an external disk), the request is denied and the application shows up (and the privilege is not granted) in System Settings > Privacy & Security > Full Disk Access. In order for an application to have that privilege the next time it makes a similar request, the user must go to System Settings > Privacy & Security > Full Disk Access, toggle the switch for the affected application to the On position, then authenticate as an administrator. This is presumably where Apple has plans for improved UI, i.e. "we 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".

What can we do right now to raise the bar on security and privacy?

In a somewhat unprecedented manner, Apple's announcement on Friday preempted the introduction of those new controls in a macOS update. In light of that, and the recent AI Agent access concerns, there are a few things that you can do to improve the security of your private data right now.

Audit your Full Disk Access grants

macOS imposes explicit protection for data on removable media and network volumes — only applications that are either explicitly approved for access to those resources, or granted Full Disk Access will have access to the data on your backups. With that in mind, you should carefully consider which applications are given that access (click here to open Privacy & Security > Full Disk Access). Does Google Updater really need Full Disk Access? How about GoogleDrive, or OneDrive? AI Agents? siriactionsd? The Terminal application should definitely not have Full Disk Access if you're not a savvy Terminal user.

Bear in mind that the presence of an application in the Full Disk Access panel doesn't mean that the application requires Full Disk Access, it only means that the application attempted to access a resource that would have required it. If the application handles the denial gracefully and works fine without that resource, then it doesn't need Full Disk Access. If you've granted Full Disk Access to an application that maybe should not have access to your private data, toggle the switch for that application to the Off position, then see how it copes without it (and whether it provides a good argument for re-enabling it).

Enable FileVault encryption on your backup volumes

When encryption is enabled on a volume, the data is encrypted on-the-fly as the filesystem writes files to the destination media. That data can only be decrypted when the volume is unlocked and mounted. If the disk is lost or stolen, files can't be accessed without your encryption password. When you select a destination to a CCC backup task, CCC's Backup Volume Setup Assistant offers to enable encryption. If you passed up that option in the past, simply click on CCC's Destination selector now and choose Backup Volume Setup Assistant… to see the option again. For a more in-depth discussion about FileVault and CCC, see my blog post from May: Make your Mac backups truly private: encrypt your CCC backup drive with FileVault.

Keep your backup volume unmounted (and therefore locked)

When an encrypted volume is not mounted, it's locked and inaccessible (e.g. to AI agents and any other application that shouldn't be nosing around in your backup) — that volume can't be remounted without providing the encryption password. You can achieve this result by detaching the disk from your Mac, but you can also just unmount the volume and leave the device attached – CCC can then automatically remount it when your backup task runs.

You can configure CCC to unmount your backup volume automatically at the end of the backup task:

1. Click Advanced Settings at the bottom of the main CCC window
2. Select the Postflight tab
3. Choose Unmount the destination volume from the Destination volume popup menu
4. Click Done, then save the changes

Consider removing encrypted volume passwords from your login keychain

When you choose to save an encrypted volume's password in your login keychain, macOS will automatically mount and unlock that volume on startup, or whenever the disk is attached to your Mac. While that is convenient if you need to use that volume for non-backup purposes, that behavior also makes the content available to any application to which you've granted Full Disk Access. When CCC saves a password for an encrypted volume, it stores that password in the System keychain with an access control that only allows CCC's privileged helper tool to access the password. That allows CCC to unlock and mount a volume at the beginning of a backup task, without giving that unlocking capability to other applications. Paired with a postflight unmount, your backup volume will generally not be available to other software running on your Mac.

Click the Spotlight button in the toolbar and search for Keychain Access to view the content of your Login keychain. If you decide to remove an encrypted volume's keychain entry, eject the backup volume, detach, then reattach the disk from/to your Mac to verify that macOS prompts for the password — that's the new gate that limits access to that encrypted volume.