Apple built Full Disk Access so backup apps could read everything. AI agents now ask for the same reach, and on a developer's Mac they often get it from the terminal without asking.

On October 2, Apple posted a short note to its developer news page titled Updates to Full Disk Access in macOS. It explains why the setting exists: "Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac." Then it describes what some developers have done with it: "exposing everything on their systems—including files, mail, messages, and even browsing history—without users' full knowledge and understanding."

Apple will add controls so that users who want to grant this access "can only do so with very explicit user action." It also gave a reason for acting now: "As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially."

Apple has given no date, and it hasn't said what happens to grants that already exist. The note does make clear what Apple thinks of Full Disk Access in the hands of an agent.

Two stories in two weeks

Coverage of the note, from TechCrunch onward, tied it to two incidents.

Muse and the Messages database. On September 19, Inc. columnist Jason Aten reported that Meta's Muse agent on his Mac sent him a notification suggesting a column built on a conversation he had just had with his podcast co-host. He says he had declined to give Muse access to Messages, yet found that Muse had synced his Messages database up to row 187,462, while Muse's own settings showed Full Disk Access switched off. Meta disputes the account. David Singleton of Meta Superintelligence Labs said Muse can read Messages only after "three separate steps of application-level permissions and built-in macOS system-level protections" that "can't be circumvented even if the Muse application had a bug." Muse itself told Aten it had been syncing his "device notifications."

Patrick Wardle of the Objective-See Foundation summed up what the permission means once an app has it: "any (non-root file), is readable, browsing history, browser cookies, chats, etc."

ChatGPT's Mac app. The same week, Wired reported a flaw Wardle found in OpenAI's ChatGPT app for macOS, CVE-2026-100754. The app decided which local processes to trust by their code signatures and their process ancestry. A trusted script interpreter could be fed untrusted input, which let ordinary code already running on the Mac slip into an accepted process chain and drive the app's trusted features: chat history and connected integrations such as browser sessions. OpenAI fixed it in build 26.924.20706, in production since September 25. Nobody has reported exploitation in the wild.

Both stories share a premise. An agent on the Mac runs as you, and whatever it can read, any code that takes over the agent can read too.

The terminal already said yes

Muse asked for Full Disk Access through System Settings, the way Apple's model expects. A terminal coding agent asks for nothing and runs under the terminal's grants.

macOS checks privacy permissions against the responsible app, which for a command-line tool is the terminal that launched it. Plenty of developers granted Terminal, iTerm or their editor Full Disk Access years ago to stop the prompts that find, rsync or a backup script would otherwise trigger. Every process started from that window inherits the grant. That covers Claude Code, Codex and Gemini CLI, along with every npm install postinstall script, every MCP server they spawn, and every one-liner a README talked them into.

In that setup, the files Apple listed are in reach of the agent and of anything the agent runs:

~/Library/Messages/chat.db, the Messages history Muse was accused of syncing
~/Library/Mail, every mailbox
Safari's history and cookies under ~/Library/Safari and its container
Notes, Photos libraries and other apps' private containers

The secrets were never behind the prompt

Apple's change is the right one, and it covers the files people think of as private. A developer's working credentials sit somewhere else. These paths are not protected by Full Disk Access or by any other macOS privacy permission:

~/.ssh/id_ed25519
~/.aws/credentials and ~/.aws/sso/cache/
~/.config/gh/hosts.yml, ~/.git-credentials, ~/.npmrc, ~/.docker/config.json, ~/.kube/config
the .env file in every project you've cloned
the agent's own OAuth tokens and session transcripts

Any process running as your user can read them, with or without Full Disk Access. Apple's new controls will make one big permission harder to grant. A coding agent on a laptop didn't need that permission to reach the files that let an attacker push to your repositories or open your AWS account. Infostealers that target coding agents already harvest these files: access and refresh tokens, MCP configurations, prompt histories.

Before you check which apps hold Full Disk Access, look at what the agent's computer contains.

On a laptop, the agent runs as you. A terminal with Full Disk Access passes its grant to the agent and to everything the agent starts, which opens Messages, Mail and Safari data. Developer credentials in dotfiles need no grant at all. In Bromure, the agent runs in a Linux VM that sees only the folders you shared and stand-in credentials; the real ones stay on the Mac, where the proxy uses them.

In Bromure, the agent isn't a Mac process

Bromure Agentic Coding runs each machine's agents inside an Ubuntu VM under Apple's Virtualization.framework. Claude Code, Codex, Grok and the rest are Linux processes on a Linux kernel. macOS privacy permissions don't apply to them because they never open a file on the Mac's filesystem. There is no grant to inherit and no terminal whose permissions leak into the agent, because the terminal you see in Bromure is attached to the VM, not to your Mac's shell.

What the VM can see is a short list:

Its own system disk, a copy-on-write clone of a signed Ubuntu image.
Its own home, /home/ubuntu, on a private disk image.
The folders you shared with that machine, up to eight, each mounted under the home by name. If you share ~/code/payments, the agent sees ~/payments. It does not see ~/code, and it never sees ~/Library.
A small per-boot configuration share, read-only, holding proxy settings and the stand-in credentials.

chat.db isn't on that list, and neither is Mail or Safari's history. A Muse-style sync job, or a prompt-injected agent told to "summarize my recent messages for context," finds that ~/Library/Messages doesn't exist. The VM has no path that leads there.

The developer secrets are stand-ins

That covers Apple's list. Bromure also covers the list Apple's note leaves out, the dotfiles.

Real credentials stay encrypted on the Mac. The VM gets stand-ins with the right shape: GH_TOKEN is ghp_ plus 36 characters GitHub would reject, ANTHROPIC_API_KEY is sk-ant-api03-brm-…, and ~/.git-credentials, ~/.docker/config.json and ~/.kube/config hold fakes. The proxy on the Mac puts the real value onto a request after it has left the VM, and only when the request is going to the host that credential belongs to. In the manual's words: "No file, environment variable, or process inside the VM ever contains a real API key, OAuth token, AWS secret, or SSH private key."

Two details answer Apple's concern about broad grants:

AWS import asks for one folder, on the Mac. To import your AWS profiles, Bromure asks for a security-scoped grant to ~/.aws alone. The folder is read on the Mac and never mounted into the VM. That is the narrow, explicit grant Apple's note asks for, and it goes to the host app, never to the agent.
SSH keys stay on the Mac. The VM's SSH_AUTH_SOCK is a bridge to an agent on the Mac. The guest can ask for signatures, and the private key bytes never enter the VM. Your macOS login ssh-agent is never exposed to it.

When Claude Code signs in through Bromure, the OAuth flow runs in your Mac's browser and the tokens are stored on the Mac. The VM's ~/.claude holds no real token. That is the file infostealers aimed at coding agents go looking for.

The browser has its own disk too

Apple listed browsing history, and Wardle listed cookies. The agent in Bromure has a browser, a full Chromium the agent drives through the built-in browser MCP server. It runs in a second, disposable VM, separate from the agent's machine and from your Mac. By default its disk is a temporary clone deleted when the browser closes, so cookies, logins and history vanish with it. It has no access to Safari's history or your desktop Chrome profile, since those live on the Mac.

Whatever leaves crosses the Mac

Suppose an agent does gather something worth stealing from the project folder you shared. It has one way out. The VM's virtual switch diverts every web connection into the proxy on the Mac, and the guest can't turn that off.

At the default tracing level, every request is written to an encrypted trace on the Mac, with the model exchanges parsed into the tool calls and shell commands the agent issued. The Trace Inspector shows a POST to an unfamiliar host at the moment it happened.
The machine's egress firewall, enforced on the Mac, can allow only the hosts the project needs and drop everything else.
If the payload carries one of the stand-in credentials, the proxy sees a credential headed for a host it wasn't issued for. It answers with HTTP 451, pauses the VM, and opens an alert on the Mac: This environment may have been compromised.

The local IPC trick needs a Mac process

CVE-2026-100754 depended on "unprivileged code already running on a Mac" reaching the ChatGPT app's local trust channel. On a laptop, the most active source of code running as you is often the coding agent: dependencies it installs, scripts it runs, tools it downloads. In Bromure that code runs in the Linux guest. The Mac's XPC services and Unix sockets, and the desktop apps behind them, live in a different kernel. A malicious postinstall script in the VM can't join a process chain on the Mac.

One machine per job

Shared folders are where you decide how much the agent sees. Each Bromure machine has its own folder list, its own credentials and its own home, so the habit is easy:

Give each project its own machine, and share only that project's folder.
Give a machine only the credentials its project uses. The scratch machine where you try new MCP servers and agent plugins gets none.
Leave Prompt before write on, the default on new machines for GitHub, cloud providers, registries, Kubernetes and databases. Pushes and deletes then pause for a macOS dialog that shows the exact operation.
Never share your home folder. The agent doesn't need it.

Each boot of a machine also takes a copy-on-write checkpoint of its home, so Rewind home… can put back what an agent deleted there.

No macOS permission to inherit

The agent is a Linux process in a VM. It never runs under your terminal's Full Disk Access, and Messages, Mail and Safari data are not on its disk.

Only the folders you picked

Each machine sees its own home and up to eight folders you shared by name. The rest of your Mac, ~/Library included, isn't there.

Dotfiles hold fakes

Git, cloud, registry and model credentials are stand-ins. SSH private keys never enter the VM. The proxy on the Mac adds the real values on the wire.

Every exit is recorded

Web traffic crosses the host proxy: traced, filtered by the egress firewall, and stopped with a paused VM if a stand-in heads to the wrong host.

Give the agent a computer of its own

Apple's note is an operating-system vendor telling developers that a permission designed for backup software doesn't belong with autonomous agents. Apple is right. Its fix is a clearer prompt, and the user still has to make the right choice for every app, on a Mac that holds everything they own.

Bromure gives the agent a computer of its own. It holds the project you shared and keys that work only when the proxy on your Mac swaps in the real ones. When Apple's new dialog ships, your coding agent won't be one of the apps asking.