Mac AI agents: Full Disk Access is not a shortcut

A warning that belongs in product design

On 2 October 2026, Apple issued an unusually direct warning about a convenient pattern: apps requesting Full Disk Access when their actual job is much smaller. That permission largely sidesteps macOS privacy controls. An app may gain access not only to project files but potentially to mail, messages and browsing history. Apple therefore plans additional controls that will require very explicit user action.

The important line in the announcement concerns AI agents. As they become more capable and autonomous, Apple says, the risks of this level of access will grow substantially. This is not abstract platform policy. It concerns every Mac app that can find, summarise, sort, rename, move or send files to a model.

Teams building agents should not treat Full Disk Access as a shortcut around difficult file selection. Permission is part of the product interface. It determines how far a bug, an ambiguous instruction or a malicious document can reach.

Broad access expands more than convenience

A conventional tool runs a defined command. An agent decomposes a goal into steps, selects tools and reacts to new information. That strength changes the risk model.

“Clean up my Downloads folder” may mean reading files, classifying content, detecting duplicates, renaming items and moving documents. If the agent encounters a crafted file containing misleading instructions, its contents must not decide which other folders are opened or which data is uploaded. A wrong classification must not delete an archive merely because the app can write everywhere.

The blast radius has four dimensions:

• Reach: Which folders and data types can the app see at all?
• Capability: Can it only read, or also write, move and delete?
• Duration: Does access last for one action, one session or indefinitely?
• Transfer: Does data stay local, or do content and metadata leave the device?

One system permission does not answer these questions. The product needs to turn them into an understandable sequence.

Let the user choose the workspace

For sandboxed Mac apps, Apple's standard file panels already provide a strong pattern. A person selects a file or folder, and the sandbox extends access specifically to that selection. The app does not need to guess where it may work and does not need to request the whole disk.

For an agent, we call that selection a workspace. Before the first action, the product shows:

1. which folder the agent wants to use;
2. why it needs that folder;
3. whether reading is enough or changes are planned;
4. whether processing is local or data goes to a service;
5. how access can be revoked later.

Selection should happen in the system panel, not a deceptive custom imitation. That preserves the signal that the user is opening an operating-system boundary. A preselected “share entire home folder” may technically collect consent, but it does not create meaningful consent.

Read first, then change deliberately

Many tasks need read access at the start and nothing more. An agent can inspect a folder, propose a structure and produce a preview without touching a file. Write access becomes relevant only when the plan is approved.

A useful flow looks like this:

Scan: Read names, types and necessary metadata. Open content only when the task requires it.

Plan: Show proposed operations as a plain list: rename 18 files, move 6, delete none.

Confirm: Ask separately for risky or hard-to-reverse actions.

Execute: Permit only the approved operations and destinations.

Report: Make results, errors and skipped items visible.

This separation adds a few states to the interface. In return, it prevents “analyse” from quietly meaning “modify”. It also creates a natural place for undo, trash instead of permanent deletion and an exportable action history.

Persistent access needs a persistent reminder

Some products need to return to the same folder after a restart. Apple documents security-scoped bookmarks for this: the app stores the user's selection and can restore that limited access later. A bookmark can also be created as read-only.

The technical lifecycle matters. The app starts access with startAccessingSecurityScopedResource and releases it as soon as possible with stopAccessingSecurityScopedResource. Restorable access is not a reason to leave a resource open for the entire process lifetime.

The product should expose that lifecycle too. A “Workspaces” page can show:

• the authorised folder;
• read-only or read and write;
• local or external processing;
• last use;
• controls to pause or remove access.

A small, persistent indicator during an active agent run is more useful than a one-off onboarding explanation. Permissions are not legal footnotes. They are operating state.

Make tools narrower than the file permission

Even inside an authorised folder, the model should not be free to compose arbitrary shell commands. Give the agent small typed tools instead: listFiles, readFile, createDraft, moveFileToApprovedFolder or trashFileAfterConfirmation.

Each tool checks in trusted application code:

• Are source and destination inside the workspace?
• Is this operation allowed in the current phase?
• Would it overwrite an existing file?
• Does it exceed a size or quantity limit?
• Does it require renewed confirmation?

This turns a vague permission into a set of testable contracts. The model proposes an action; trusted application code decides whether it may run. Text inside a document cannot invent a new tool or move the destination beyond the selected folder.

External models create a separate data decision

File access and data transfer are different forms of consent. A user can permit an app to organise a folder locally without agreeing to upload every document.

Every architecture therefore needs a clear data route:

• Which steps run fully on-device?
• Which excerpts go to which model?
• Is content retained or only processed?
• Can sensitive types and hidden files be excluded?
• What enters diagnostic logs and error reports?

We prefer data minimisation before the model call. Grouping files may require only a name, type, size and a short locally produced excerpt. Credential files, keychain exports, mail archives and configuration files belong on default deny-lists. A preview should say that “12 text excerpts” will be sent, not merely “some data”.

Three practical product patterns

The research assistant: The user selects one project folder. The agent reads PDF and text files, creates citations with source paths and writes its draft only into a newly created output folder. Originals remain unchanged.

The Downloads organiser: The agent analyses only the selected Downloads folder. It previews rules and quantities, moves confirmed files into subfolders and sends deletion candidates to Trash. Archives, hidden files and executables are excluded by default.

The media workflow: The user chooses source and destination separately. The product processes images locally, shows the expected item count and output size, and may only create new files in the destination. A later cloud sync requires its own clearly named approval.

All three patterns provide useful automation without declaring the entire Mac a workspace.

Migrating away from Full Disk Access

If an existing app already depends on Full Disk Access, begin with telemetry that excludes file content: which paths and operations are actually used? Turn those observations into explicit workflows and the smallest necessary capabilities.

Then migrate in stages:

1. Add file selection and clearly named workspaces.
2. Model reading, writing and deletion as separate capabilities.
3. Limit existing automations to authorised folders.
4. Introduce previews, confirmation, undo and history.
5. Keep Full Disk Access only for specialised cases that genuinely cannot avoid it.
6. Make the constrained mode the default and actively retire the broad permission.

Apple has not yet described the exact mechanics of its additional controls. Product strategy should therefore not depend on a particular future dialog. Teams that already model user intent, minimum privilege and bounded duration will adapt more easily to new platform rules.

Security can be the better experience

A good agent does not feel powerful because it can see everything. It feels trustworthy because its reach is understandable, its proposals are reviewable and an error cannot affect the whole computer.

The best interface keeps three things clear at all times: Where is the agent working? What will it do next? How can I stop or reverse it?

Full Disk Access answers none of those questions. A deliberately chosen workspace, narrow tools and visible confirmation do. That is more than a response to Apple's coming controls. It is the product model that makes autonomous software fit for everyday work.

Sources

• Apple Developer News: Updates to Full Disk Access in macOS
• Apple Developer Documentation: Configuring the macOS App Sandbox
• Apple Developer Documentation: Accessing files from the macOS App Sandbox
• Apple Developer Documentation: App Sandbox